Na een eerdere changeset melding.
En validatie van editors ligt het gebruik onder vuur.
Nu zie ik de laatste tijd dat paving_stones:30 wordt omgetagd naar alleen paving_stones.
Wat verkeerd is, hiermee verliest het detail.
Negeer de validatie meldingen .
paving_stones:30 zijn tegels en heeft een eigen wikipagina sinds 2009
paving_stones:30 is de verkorte / makkelijker te zette versie van:
Men heeft een schema ontwikkeld voor paving_stones
Om via deze manier tegels uit drukken moet men het volgende zetten:
surface=paving_stones
paving_stones:shape=square
paving_stones:length=0.3 of paving_stones:length=30 cm
Met de vermelding:
Dat enkele het gebruik van paving_stones:30 betwisten.
Dat is schijnbaar een reden om de validatie al te veranderen.
Wil je van surface wisselen dan is paving_stones:30 makkelijker om te zetten/wisselen.
En moet je niet de twee extra tag regels zetten/verwijderen.
Blijven we het gebruik van paving_stones:30 stimuleren?
of het met drie regels tegels uitbeelden eventueel met material=*
Ik kom het vaak tegen en laat het gewoon staan. Ik negeer het gemekker van de validators.
wel vind ik het ontbreken van de eenheid cm een probleempje. De default eenheid is m en alleen in deze key is het cm. Dus ik zou liever paving_stones:0.4 zien.
Er zijn ook steeds vaker rechthoekige tegels, dus dan zou het bijvoorbeeld paving_stones:0.3x0.5 worden.
In formule is het dan paving_stones:N[xM]
Maar goed, het belangrijkste vind ik dat het als verhard wordt geteld en weergegeven, en ik weet niet of dat bij de belangrijke renderers wel gebeurt als het op onze manier is getagd.
Ik zou er geen probleem mee hebben om het anders te gaan doen, in dat geval lijkt het me het beste om het omtaggen in één keer goed te doen.
Was een heel verhaal aan het typen wat gewoon overeen kwam met het antwoord van Peter. @Peter_Elderson dus +1
Zolang de eenheden maar kloppen. Ik zie paving_stones:30 gewoon als een ondertype van paving_stones Maar waarom dan wel een paving_stones:30 en geen paving_stones:10x20 of paving_stones:40x60?
Perspective of outsider and user of OSM data and mapper: surface=paving_stones:30 is extremely annoying.
It is similar to theoretical shop=alchohol_open_24/7_except_holidays
or tourism=museum_with_free_entrance
This kind of detail really should be represented with separate tags, not stuffed into main tags.
Though retagging it to just surface=paving_stones is losing data.
But maybe consider retagging it to more standard, clear and useful schema? (with paving_stones:shape=squarepaving_stones:length=0.3 or paving_stones:length=30 cm or whatever this value means)
Imagine dealing with surface=compacted:gray surface=paving_stones:concrete surface=paving_stones:15
or (to take sadly real values) surface=concrete:paving_stones:30 surface=cobblestone:10 surface=paving_stones:50 surface=paving_stones:20 surface=cobblestone:20 surface=paving_stones:40
Stuff like that is extremely annoying when working with OSM data.
– sincerely, person who wrote most of code for surface overlay in StreetComplete and worked on displaying surface in OSM Carto (for paths and footways)
In most cases it will not be. I added special support for it in StreetComplete to alias it to surface=paving_stones to prevent data damage but it was quite annoying to discover this tag.
Het taggen van het formaat van de paving_stones overstijgt mijn gewenste detailniveau. Ik zal het niet verwijderen maar ook zeker niet zelf toevoegen. Als iemand het toch wil taggen dan inderdaad graag als een losse k/v pair. Tegelijkertijd vraag ik mij af welke data consumer iets doet met het formaat en of er voldoende mappers zijn die het formaat van de tegels actueel willen/kunnen houden.
Dat gevoel krijg ik hier ook een beetje bij ja (niveautje te diep). Mogelijk is deze kennis handig voor bedrijven die graafwerkzaamheden doen maar vermoedelijk hebben die wel hun eigen datasets / kaarten daarvoor?
Ik ben het helemaal met je eens. De vraag is niet welke detaildata ik in de OSM-database kan brengen maar de gedachte welke dataconsumer daar iets mee zou kunnen en willen doen. Dit niveau van detail vind ik, persoonlijk, zinloos. Of een weg verhard is, tegels stenen of asfalt is nuttige informatie (naast de smoothness tags) voor gebruikers. Het formaat van de tegels, de kleur, de dikte, het materiaal (beton, baksteen), een afgeschuind randje of niet, de fabrikant en weet ik niet meer is vervuiling van de database. Niemand doet er iets mee, het wordt niet onderhouden.
Andere mappers vonden het blijkbaar wel waardevol om deze informatie op de kaart te zetten. Het zou tegen de richtlijnen van OSM in gaan om die moeite teniet te doen omdat “niemand er wat mee doet en het niet wordt onderhouden.”
Volgens die redenering zouden we anders heel veel verouderde en niche data van de kaart af moeten halen, en daar zullen we weinig voorstanders voor vinden.
De informatie staat in de database en niet op de kaart (gelukkig); ik heb slechts gezegd dat ik het, letterlijk, waardeloos vind. Dat anderen het blijven toevoegen is hun goed recht. Wie er wat mee doet is voor mij geen vraag.
Daar gaat het dus om, het niveau van detail.
paving_stones:30 is destijds ontstaan, omdat er behoefte aan is om tegels uit te drukken. Niet verder uitgewerkt in detail. Dat moeten we respecteren. Dit niveau van detail.
Anderzijds is er de behoefte om makkelijk te werken, één tag regel.
Men dwingt ons er toe om drie regels te gebruiken, dit geeft weerstand om het te taggen, mee te werken, dat niveau van detail aangegeven door:
surface=paving_stones
paving_stones:shape=square
paving_stones:length=0.3 of 30 cm
square behoeft alleen length, geen width, dat scheelt weer één regel.
Deze combinatie is slechts 1 keer in Nederland gebruikt op een way. overpass
De verhouding aangegevend:
Wereldwijd count 0.3: 6overpass
Wereldwijd count 30 cm: 4overpass
Ondertussen, niet echt ingeburgerd in de OSM community.
Waar zal dat aan liggen?
Wereldwijd count paving_stones:30: 11684overpass
Daar ligt het spanningsveld van detailniveau. 1 of meerdere regels.
concrete heeft ook een onderverdeling, concrete:lanes concrete:plates is dat dan wel acceptabel?
Nieuwe alleenstaande value ? Dit in verband met 1 regel gebruik tagging, waar behoefte aan is, de detaildrempel. surface=paving_stones:square:30
De tussenvorm:
Dan zitten we op 2 regels te mappen voor tegels, met nieuwe :suffix, gewenst? Hoe zal dat inburgeren, of het nu 2 of 3 zijn is dat het probleem? Gelden daar ook dezelfde argumenten als bij surface=paving_stones:30? surface=paving_stones:square:30x30? 1 regel, zal dat wel inburgeren? Het gaat er om, op het ene moment wordt een argument gebruikt, op een ander moment niet, voor het bekritiseren van een value.
Om snel te zetten, dan wordt het gebruik van een preset in JOSM handig, ook bij het verwijderen, omzetten naar een andere surface. Het gaat er uiteindelijk om hoe vaak het word gebruikt, meer data maakt beter gebruik mogelijk. De keuzes in andere, ID, streetcomplete, etc. zijn mede bepalend, hoe vaak het wordt gezet. Zou de tegels versie in het lijstje komen als mogelijkheid in Nederland als een vraag wordt gesteld over wegdek?
Gebruik data:
Gebruik bij routering berekening, wel/niet routeren over dat stuk weg, zal het punt niet zijn, bij de fiets of anderszins, van A naar B. Wellicht een indicatie bij rolstoel gebruik. Over tegels rijdt je toch veel fijner.
Meer om te bekijken in een staatje, het wegprofiel, welke wegdekken je hebt gereden/gelopen. Inzicht krijgen in het verschil tussen klinkers en tegels. Rekening houdend dat paving_stones verder gaat dan alleen klinkers.
Omzetting:
De gevolgen, er zullen ook andere zijn die hun style/preset of andere visualisaties moeten verbouwen.
Als we van vandaag op morgen alles omtaggen.
met legenda: Hoe simpel deze tags visualiseren.
Annoying?
Het omgekeerde:
samenbrengen van tags onder één noemer: paving_stones:30 onder paving_stones.
dat zal ook zo zijn als men er tegels van wil maken 3 regels samenvoegen tot 1 categorie.
Overwegingen:
Ik ben met een andere preset bezig, een gedeeltelijke One Click, wat ga je dan gebruiken, vandaar deze topic start. Al bezig zijnde komen er vragen/tegenstellingen naar voren.
Je gebruikt het woord ‘behoefte’, maar dat is wellicht een selffulfilling prophecy of is dit een wens van een of meer mappers of heeft een OSM-gebruiker er wat aan? Ik waag te betwijfelen of een rolstoelgebruiker zijn keuze laat afhangen van de maat of het vierkant of rechthoekig zijn van straattegels. Surface en smoothnesstags zijn dan toereikend en voldoende.
