Ga het nog even rustig doorlezen maar alvast bedankt voor de zeer uitgebreide reactie en voorbeelden! Snap wel dat het een lastige situatie is in elk geval.
Nee, dat is alleen ondersteund voor veel gebruikte tags maar daar heb ik osmium tags-filter en een python scriptje gehaald. De values van paving_stones:length= in combinatie met paving_stones:shape=square.
| Value | Count |
|---|---|
| 0.5 | 12 |
| 0.3 | 6 |
| 30 | 4 |
| 30 cm | 4 |
| 0.4 | 2 |
| 50 cm | 1 |
| 0.15 | 1 |
| 52 cm | 1 |
| 50.3 cm | 1 |
| 0.2 | 1 |
| 20.5 cm | 1 |
Voel je vrij om de tags te negeren, maar als de data er is volgen gebruikers vaak vanzelf. In 2009 vroeg op de Talk mailing list iemand zich af of het überhaupt zin had om gebouwen te mappen, en nu hebben we er ruim een half miljard. Nog steeds vragen sommigen zich af of smoothness taggen zin heeft, maar elke respectabele routing engine gebruikt de tag heel graag. Je mag dit soort tags die je nutteloos vindt daarom ook niet zomaar verwijderen zonder discussie: ook voor alle niche data zijn gebruikers te vinden, als wij die data aanbieden.
3 Likes
Wie heeft het hier over zomaar verwijderen?
I ontken niet dat ik dat, mogelijk, incidenteel tijdens andere mappingactiviteiten, omdat de JOSM validator het fout vond, ooit eens gedaan kan hebben, maar verder niet. Wat anderen mappen: prima, tenzij het evident fout is.
Jouw vergelijking (uit 2009!) met buildings vind ik wat zwak; in die zin zou Open STREET Map alleen wegen mogen bevatten.
En juist pleit ik, terecht, voor het gebruik van de smoothness tag (als je dat goed gelezen had in mijn eerdere antwoorden), daar heeft een routing engine wat aan, maar geen routing engine heeft iets aan de maat van een tegel en of die vierkant of rechthoekig is, en ik kan me niet voorstellen hoe die daar ooit iets aan zal hebben. Met andere woorden: ik begrijp je betoog niet zo.
Wederom: persoonlijk vind ik het vullen van een database (wat geld en energie kost) met tegelmaten vervuiling en het is mijn goed recht dat te vinden. Een discussie over de semantiek en de grammatica hoe de tegelmaten in die database moeten, tja…
En het is inderdaad een niche; welke toekomstige datagebruiker ik daarbij kan verzinnen: geen enkel idee, we zullen het zien in 2037, dan zal ik deemoedig mijn excuses aanbieden, mocht ik dat bewust meemaken.
En net als ieder de vrijheid heeft om nieuwe tags te verzinnen en toe te passen, neem ik de vrijheid de tagging waar we het hier over hebben zinloos te vinden, of op zijn minst niet enthousiast over te zijn.
Excuses voor de lange tekst, maar het is in elk geval interessant leesvoer (bedoel niet mijn eigen lap tekst maar deze (meta-)discussie) … In de praktijk wordt het verder uitspecificeren van de surface=paving_stones dus (nog) maar weinig gedaan begrijp ik, naast de ‘ongewenste’ surface=paving_stones:30?
Je zou haast gaan zeggen: Specificeer de soort bestrating nauwkeurig in Wikidata zodat je twee tags nodig hebt voor de beschreven gevallen. surface=paving_stones en paving_stones:type_wikidata=Q*. Je zou dan een entry kunnen maken voor de klassieke Hollandsche 30x30 met daarbij dat het gaat om 30 cm, de vorm vierkant en eventueel meer info zoals vanaf welk jaar in gebruik in Nederland (ga helemaal los). Zelfde kun je doen voor de rode klinkers en andere. Wikidata kent in elk geval het concept Paver al: paver - Wikidata.
Meta: Eventjes leek het me serieus een goed idee maar er zitten natuurlijk veel te veel nadelen aan. Waarde van de tag zegt mensen niets. Als je wil renderen op basis van de geometrische eigenschappen kun je die ook niet uit de tagwaardes afleiden. Dat moet dan in Wikidata zelf opgezocht gaan worden. Patroon kun je ook niet bij het type straatsteen plaatsen dus moet je die er alnog bij specificeren en verlies je de databesparing (goed punt van Martin) door naar Wikidata te verwijzen. Ander groot nadeel is dat je dan afhankelijk bent van een extern systeem en Wikidata kan ook gevandaliseerd worden. Toch zie ik wel een rol voor Wikidata om een brug te slaan tussen de twee werelden. Wikidata is bij uitstek geschikt om een taxonomie vast te leggen met praktisch oneindige ‘diepte’ en OSM wordt daar soms misschien te veel voor ge-/misbruikt.
Weer on-topic! Ben ook wel benieuwd in hoeverre die subtags echt (allemaal samen) worden gebruikt. Er wordt wel werk van gemaakt door sommigen, zie bijvoorbeeld:
Way: De Langheplein (30081634) | OpenStreetMap (halve centimers!)
en
Way: 609898243 | OpenStreetMap (meerdere kleuren)
Heb ook niet echt een pasklaar antwoord op de vraag van uit de OP. Misschien even proberen de opties samen te vatten om te kijken of ik het een beetje snap:
-
surface=paving_stones:30 blijven gebruiken voor stoeptegels.
Voor: Simpel, geen extra data toegevoegd.
Tegen: Er is (internationaal) bezwaar tegen deze manier van tag vullen en je kunt niet meer alleen opsurface=paving_stonesfilteren. -
Alle geometrische data in de subtag
paving_stones:shapeplaatsen (bijv. square_30x30cm).
Voor: Maar 1 extra subtag nodig.
Tegen: Moeilijk parseerbare tag, veel kans op inconsistentie bij handmatig invullen (opmaak van de tekst, wel of niet de eenheid erbij, lengte en breedte doorelkaar). -
Alle eigenschappen, inclusief de geometrische, in losse subtags.
Voor: Individuele subtags zijn eenvoudiger van een waarde te voorzien qua opmaak en te valideren. De Wiki-pagina voor de subtags is best duidelijk i.m.o.
Tegen: Maakt veel extra subtags bij (extra data) en alsnog ambiguiteit mogelijk m.b.t. de eenheden en precieze opmaak (50cm of 50 cm of 0.5).
Denk dat ik dan toch naar 3 neig ondanks de hoeveelheid extra data. Hoop zelf dat de subtags spaarzaam gebruikt gaan worden en bijvoorbeeld een StreetComplete er niet los mee gaat door ook nog subvragen over de tegelsoorten te gaan stellen bij keuze paving_stones. Maar wie wel heel specifiek wil zijn heeft er dan het gereedschap voor qua tags (zoals in de aangehaalde voorbeelden).
1 Like
Do not worry, this will not happen.
Thanks for the quick reply! Also apologies for somewhat ignoring you by posting in Dutch but your translation tool did a good job on that sentence.
[offtopic] Really like using StreetComplete btw but it already offers a lot of options that make me doubt sometimes what the right answer is. Although paving_stones is usually an easy one to pick as answer. Much easier than finding the correct value for some unpaved paths. Having studied the Wiki a bit more for this discussion I see StreetComplete is following that pretty closely in terms of possible value? [/offtopic]
Maybe an optional thing in SCEE for the exceptional mappers who enjoy this sort of niche micromapping.
Let me begin with stating that I’m in favour of Mateusz’ proposal to break the shape and size out of the surface tag, for the same reasons as he has stated.
However, when discussing alternatives, I can’t find anyone mentioning the redundancy in putting paving_stones:shape=square in addition to both length and width tags. If the shape is square (or hexagonal, for that matter), only length is needed for obvious reasons. On the other hand, omitting the shape tag and solely relying on length and width only works for rectangular tiles.
I would therefore propose to clearly define what other tags could be used in combination with shape, to avoid redundancy in tags. The shape could even be inferred to be rectangular, if both length and width are present (and different) without any other specifying properties, if you really want as few tags as possible.
Yes
In some cases where OSM Wiki seemed wrong/mistaken a tagging discussion was started, then wiki was amended (see say Talk:Tag:building=office - OpenStreetMap Wiki? or https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:surface&diff=2400015&oldid=2385791 ), in several cases better image for StreetComplete was found / taken and applied also to OSM Wiki (File:Paved mosaic.png - OpenStreetMap Wiki File:Bypass road made of big concrete plates.jpg - OpenStreetMap Wiki File:Mix of paving stones IMG 20200910 163455.jpg - OpenStreetMap Wiki )
Gisteren liep ik de Urban Walk Rotterdam. Vanwege deze diskussie lette ik onwillekeurig beter op de tegels van de voetpaden en pleinen. Ik heb een enorme variatie aan tegels gezien, naast elkaar en door elkaar. Vierkant met verschillende formaten, maar ook heel veel rechthoekige, zeskantige, en zelfs golvende tegels, en met veel verschillende oppervlakken, wb kleur, ruw/glad, mat/glimmend.
Voor mezelf sprekend, ik zie er werkelijk niets in om dit in kaart te brengen. Zelfs een onderscheid sierbestrating / functionele bestrating zie ik niet als nuttig, want bestrating kombineert meestal functie met sier. Functie in de zin van aangeven van het doel van dat vlak of die baan. Daarbij is het type tegels niet vast aan een bepaad doel gebonden; zelfs de klassieke stoeptegels kunnen een rijbaan zijn en klinkers kunnen de stoep zijn.
Dit gezegd zijnde, als iemand het toch wil doen dan prima, maar inderdaad bij voorkeur in een extra tag, die een eigenschap van de eigenschap “surface” weergeeft. Ik moet er even niet aan denken dat je ook nog segregated=yes paden hebt met verschillende surfaces, die ook nog links en rechts van de weg kunnen verschillen…
Zo bekeken is paving_stones:30 een eenvoudig geval, te vertalen naar
surface=paving_stones
paving_stones:shape=square
paving_stones:length=0.3
Geautomatiseerd alles omzetten vind ik prima. Als onderbouwing zou ik dan de uitkomst in een samenvattende post in deze draad zetten, en indien nodig een wikipagina aanpassen.
PS Ik denk even niet door over andere vormen en hoe je daar de afmetingen moet opgeven… bijvoorbeeld de zeskantige tegel, wat is daar lengte en breedte? De doorsnede, een zijde? En bij een golvende tegel? O ja, ik zou niet doordenken! Gewoon alleen praktisch het huidige geval oplossen, wetend dat de methodiek zonodig ook andere (maar niet alle) gevallen aankan.
Bij concrete:lanes en concrete:plates in de waarde is hetzelfde argrument geldig.
Dat lijkt heel erg op de roof:shape discussies. Een roof:shape tag op een rechthoekig dak werkt prima, maar als je die tag zet op een gebouw met een rare vorm, dan gaat alles fout.
Dat vind ik niet helemaal een eerlijke vergelijking. Bij die twee waardes wordt de afmeting niet gespecificeerd. Bij paving_stones:30 wel.
Veder valt het mij op dat paving_stones:30 ook veel gebruikt wordt op fietspaden. En hoewel daar ook wel 30x30 tegels gebruikt worden is 20x20 ook een veel gebruikt formaat. Ik vraag mij dan ook af of alle huidige getagde fietspaden met paving_stones:30 wel correct zijn.
Waar het uiteindelijk om gaat is dat extra specificaties prima zijn. Alleen moet dat naar mijn mening niet ten koste gaan aan de hoofdtag.
Het zou hetzelfde zijn als we op rode fietspaden surface=asphalt:red zouden taggen. Specificaties moeten losgetrokken zijn om ze goed te kunnen interpreteren en goed samen te kunnen gebruiken.
Mijn voorkeur zou uitgaan om alles (behalve fietspaden) om te zetten naar het bovengenoemde schema.
Dat vraag ik me bij de voetpaden ook geregeld af. Van enkele gevallen in mijn buurt wist ik zeker dat ze nu andere tegels hebben, dus daar heb ik de :30 verwijderd. Maar fout kunnen zijn is geen reden om het omtaggen achterwege te laten; er gaat immers geen informatie verloren en er wordt geen informatie gewijzigd.
Ja kan altijd een query maken op “verdachte” fietspadsurfacesubtagvalues.
Ik wil dit graag tegenspreken: smoothness is erg subjectief. Voor een 29’’ fiets maakt het nauwelijks verschil of de paving_stones een afmeting hebben van 10x15 cm, 30x30 cm of 52x52 cm, zolang ze maar gelijkmatig worden gelegd. Voor inlineskates is het veel aangenamer om over zo groot mogelijke paving_stones te rijden. En wie weet: misschien zijn er in 2037 wel speciale frezen voor inline skaters?
(translate with deepl)
1 Like
Tijd voor een nieuwe tag!
paving_stones:slope=30
Discussie verstomt, tijd voor een poll.
Als eerste, moet er überhaupt iets aangepast worden:
- surface=paving_stones:30 is prima, houden zo
- Omtaggen naar surface=paving_stones + paving_stones:shape=square + paving_stones:length=0.3
- Omtaggen naar surface=paving_stones + één andere tag bijv. paving_stones:shape=square_30x30
0
voters
De derde keuze laat nog een beetje in het midden wat die ene andere tag dan moet zijn, als die keuze als meest favoriet boven komt dan kan daar nog een andere poll over gehouden worden.
Vervolgens de vraag of dat maar “gewoon over tijd moet gebeuren” of dat het grootschalig/automatisch mag gebeuren. Natuurlijk niet van toepassing voor de eerste keuze hierboven.
- Geen grootschalig/automatisch wijziging, validators kunnen suggereren de keuze die hierboven is gemaakt
- Grootschalig/automatisch surface=paving_stones:30 omtaggen
0
voters
De polls zijn zo ingesteld dat ze donderdag 12 Oktober 00:00 automatisch sluiten.
2 Likes
Ik mis de keuze of deze zinloze details wel of niet getagd moeten worden.
Waarbij mijn voorkeur is om dit soort onzinnige dingen niet te taggen.
2 Likes