Iets waar ik een tijd terug al tegenaan liep was dat eigenlijk ons hele land vol zit met boundary relaties én place nodes welke dezelfde informatie bevatten.
Nu ben ik al hier en daar aan het zorgen dat die nodes als labels van deze boundaries worden geassocieerd.
Wat ik mij dus af vraag (het internationale deel van het forum geeft ook niet echt een eenduidig antwoord):
Wordt nu niet onnodig informatie dubbel opgeslagen en wordt het bijhouden van data dus onduidelijker? (b.v. inwonersaantallen)
Dat data zoals plaatsnaam en place:* wél dubbel er in staat snap ik nog aangezien dit de node en de grensrelatie duidelijker maakt.
Maar de wiki-verwijzing en inwonersaantallen horen naar mijn idee op slechts een van de 2.
Als jullie het er mee eens zijn dat de informatie slechts op een van de 2 getagged moet zijn volgt mijn volgende vraag:
Moet de informatie op de place-node of op de grensrelatie (wanneer aanwezig) worden ingevuld?
Mijn idee is om alles op de place-node te taggen aangezien deze, in tegenstelling tot de grensrelatie, wél altijd aanwezig is. (of zeg ik nu iets geks?)
Dat ze beide andere functies dienen ben ik met je eens,
Ik zie echter vaak (neem bijvoorbeeld Stein in Limburg) dat onder andere de inwonersaantallen dubbel getagged zijn terwijl het toch écht om dezelfde data gaat.
Wat ik uit [https://wiki.openstreetmap.org/wiki/Relation:boundary] haal is dat hier eigenlijk alleen de grenzen worden aangegeven en dat hier dus geen wikidata-link, populatie, etc in getagged zijn.
Naar mijn idee kunnen hier dus wél de naam admin-level en bijvoorbeeld de woonplaatscode worden getagged.
Als ik kijk naar Sittard of Geleen ben ik van mening dat deze juist getagged zijn.
Dus voordat ik overal die wiki-tags en populatie informatie ga weg halen wil ik wel eerst goed overlegd hebben of dit het juiste is om te doen
Inwonertallen zijn een paar jaar geleden door mij volgens een eenduidige methode door heel Nederland toegevoegd en bijgewerkt voor officiële woonplaatsen en gemeenten.
De tagging voor Stein enerzijds en Sittard en Geleen anderzijds is gelijk.
Place nodes: info inwonertal woonplaats.
Boundary-relatie admin_level 10 (omtrek woonplaats): geen info inwonertal.
Boundary-relatie admin_level 8 (omtrek gemeente): info inwonertal gemeente.
Het is bij zulke relaties dus goed opletten met welk admin_level je te maken hebt.
En let op: soms bestaat een gemeente uit één woonplaats (bijv. Brunssum). De inwonertallen zijn dan dus gelijk zonder dat het exact dezelfde informatie is. Dat gemeente en woonplaats samenvallen is immers niet direct af te lezen.
Dat lijkt me wel een verbetering. Wel goed opletten dat je de juiste koppelingen maakt.
Zo’n twee maanden geleden heb je aanpassingen gedaan aan Echt(-Susteren).
Aan de gemeente-relatie (admin_level 8) is nu geen hoofdplaats gekoppeld.
Ik weet niet of dat door jouw wijzigingen komt of dat het al zo was.
In elk geval: de place node van de hoofdplaats van een gemeente hoort of mag óók gekoppeld aan de gemeente-relatie (admin_level 8) als admin_centre.
Dus nadat je place nodes aan woonplaats-relatie (admin_level 10) hebt toegevoegd krijg je bijv. zoals het nu is voor Sittard:
Relatie Sittard (1421972) (als label)
Relatie Sittard-Geleen (405681) (als admin_centre)
Voor Stein wordt het dan:
Relatie Stein (1422695) (als label) ← deze toevoegen
Relatie Stein (2078288) (als admin_centre) ← deze behouden
wikidata moest juist wel op boundary relaties blijven. De wikidata linked veelal ook terug naar de betreffende relatie(s).
De admin_centre member van een gemeente relatie is de plaats waar het gemeentehuis staat, niet elke gemeente heeft dat, en sommige gemeentes hebben er meer dan een. Dit laatste kan niet goed gerepresenteerd worden in een boundary relaties die ook overal correct valideerd.
Toevallig zag ik de population tag gister voor het eerst - ik ben er niet zo voor om dat soort niet-cartografische gegevens gegevens op OSM op te nemen. Dient dat een mapping doel dat niet met wikidata opgelost kan worden?
Bijzonder dat je de population-tag pas net hebt ontdekt.
Het kan o.a. worden gebruikt bij de rendering van plaatsnamen (hiërarchie, lettergrootte) als aanvulling op de place-tag.
Zie ook dit bericht van mboeringa in het topic over de place- en populations-tag.
De meeste plaatsen hadden toen al een population-tag met een heel algemeen afgerond en dus nietszeggend getal (door AND-import).
Voor bijna alle plaatsen in Nederland geldt in de huidige tijd dat het inwonertal behoorlijk stabiel is. De getallen (meestal van 1-1-2017) blijven zonder actualisatie nog vele jaren of decennia zeer indicatief. Eventuele uitschieters zoals groeikernen kunnen tussendoor wel eens bijgewerkt worden.
Wanneer edits issues als deze introduceren zullen ze zichtbaar worden in diverse QA tools, en zodoende door andere mappers gecorrigeerd worden. Het risico van afwijken van de geaccepteerde standaard.
@Sebastic
Ik begrijp je punt. Toch vind ik het geen goede zaak om informatie achterwege te laten omdat andere mappers kunnen denken dat het in sommige gevallen niet klopt.
Bij afwijkingen van wat je normaal zou verwachten is het zomaar toevoegen of verwijderen van een admin_centre zonder kennis of degelijk onderzoek gewoon ongewenste mapping waarop men mag worden aangesproken.