Nee, dat moet juist niet gebruikt worden voor CBS wijken & buurten, zoals beschreven in de OP.
Wanneer de CBS wijken en buurten in OSM opgenomen worden moet hier goed over nagedacht worden, het is een vorm van import. Tooling is vrijwel essentieel om de OSM data te genereren, automatische import is bijzonder onwenselijk.
Voor waterschappen was er voorheen een admin_level gereserveerd, maar ze waren nooit daadwerkelijk toegevoegd in OSM, zoals beschreven in de OP.
Dat of iets anders dan boundary=administrative.
Er is geen automatische import van administratieve grenzen in Nederland.
De woonplaats, gemeente en provincie grenzen worden onderhouden op basis van de BAG woonplaatsgrenzen.
Voor de BAG is de inspireadressen dataset beschikbaar op PDOK. Deze GML data wordt in een PostGIS database geimporteerd met NLExtract. Met behulp van ogr2osm en wat custom tooling wordt OSM data (per provincie by default) gegenereerd uit deze database. osmosis wordt gebruikt om een tweede database bij te houden met de OSM data voor Nederland. Deze database wordt gebruikt door een script om OSM files te genereren (per provincie by default) met alle administrieve grenzen en daaraan verbonden objecten. Deze OSM data files worden in JOSM geladen samen met de OSM files voor de BAG woonplaatsgrenzen en grenzen die in BAG nieuwer zijn dan in OSM worden vervolgens handmatig aangepast.
Nu we het toch een beetje over het taggen van woonplaatsen en grenzen hebben…
Ik heb in Limburg enkele woonplaats nodes als label aan de grenzen toegevoegd.
Het vreemde is, wanneer ik nu een town opzoek wordt dit mooi als 1 geheel weergegeven,
Bij een village zie ik nogsteeds de node en de stadsgrens als 2 verschillende resultaten.
Dank sebastic voor je uitleg. Die komt vast nog eens van pas.
Niet een procedure die je zo even uitvoert.
Ik noem het automatische import omdat er scripts aan te pas komen. Maar ik zie dat de laatste stap handmatig is.
Laten we zeggen semiautomatisch.
Een paar punten van aandacht:
de waterschapsgrenzen admin_level=5 lopen niet mee in de hierarchie; in de OP staat er niets over.
Er staat wel iets over op de wiki over boundary=administrative (waar naar OP verwezen wordt).
Ik vind sowieso dat adminstrative + admin_level niet passend zijn voor de waterschapsgrenzen.
Zonder tegenbericht zal ik het uit de wiki halen.
Je noemt consequent CBS wijken & buurten.
Maar deze data wordt aangeleverd door de gemeentes en gebundeld door CBS. Het is dus niks statistisch, per se.
De grenzen van de wijken & buurten zouden moeten passen in de gemeente grenzen van admin_level 10 en lager.
Zoals jij al aangeeft, in een reactie, is dat niet altijd zo.
Er zal hier en daar een handmatige aanpassing nodig zijn - zoals ook opgemerkt door JeroenHoek betreffende Leeuwarden.
de wijk/buurt grenzen zijn conceptueel passend in dit schema.
Met een zelfde soort, semiautomatische, methode zou je wijken & buurten kunnen invoeren.
Stel dat er een import gedaan kan worden op verzoek, zoals bij BAG-import.
En stel dat jouw import de grenzen van admin_level > 10 (die vastzitten aan die van <= 10) kan wijzigen (zonder verder overleg).
Wat maakt dan nog dat jij vindt dat het in een ander schema moet? Iets technisch misschien?
Wijken en buurten hebben geen officiele bestuurslaag, dat is een vereiste voor boundary=administrative in Nederland. Woonplaatsen zijn hierop de uitzondering omdat het de officiele verdeling van de gemeentes is. Dit alles is beschreven in de OP.
Ik hanteer de naam CBS Wijken & Buurten omdat dit de naam van de dataset is die in principe gebruikt wordt voor de betreffende geometrieen.
Ik vind 414 relaties met deze combinatie in Nederland. Zo zeldzaam is het dus niet. Het is ook een tag die logisch weergeeft wat voor grens het is, namelijk de grens van een plaats (bijv. wijk of buurt).
Boundary=statistical impliceert dat deze grenzen voor statistische doeleinden worden gebruikt. Dat is alleen het geval bij een CBS-wijk/buurt, niet bij een wijk/buurt die alleen gebruikt wordt door lokaal bekenden of het gemeentebeleid.
Daarom moet je ook een place-node toevoegen. Als je de grenzen daarna als relatie invoert i.p.v. als vlak, dan kun je m.b.v. de rol label de place-node aan de plaatsgrenzen koppelen.
In principe is een waterschap een bestuursniveau net als provincies en gemeenten, dus boundary=administrative. Het zou wel raar zijn deze grenzen op de kaart door de provincie- en gemeentegrenzen te zien lopen, maar feitelijk klopt het wel.
Wijken & buurten worden gedefinieerd door de overheid en vallen dus ook onder boundary=administrative.
Bovendien hebben wijken en buurten een logische, hierarchische relatie met gemeentes.
Daarom moeten wijken en buurten ook een admin_level hebben.
Dat het nodig is om een bestuurslaag te hebbben voor boundary=administrative haal ik alleen uit de OP.
Verder zie ik dat nergens. Wat vinden anderen hiervan?
De waterschapsgrenzen zijn inderdaad onafhankelijk van de andere grenzen. Daarom moet daar ook zeker geen admin_level bij.
Tot op zekere hoogte zijn ze administratief gedefinieerd, Maar ze zijn ook geografisch bepaald, door rivieren etc.
Vandaar dat ik boundary=administrative voor de waterschapsgrenzen ook al enigszins ter discussie stelde.
Ik snap de naamgeving maar de data komt van de gemeentes af. Het CBS verzamelt die.
In theorie kan je die ook bij de afzonderlijke gemeentes ophalen. @A67-A67 boundary=statistical voor deze wijk & buurt grenzen is dus niet van toepassing.
Kan het niet nagaan - die overpass query geeft een timeout. Maar ok.
Ik keek naar de taginfo values voor boundary.
1194 x wordt boundary=place wereldwijd gebruikt.
Sowieso is er geen eens een wiki voor boundary=place. Dus waarom wordt dit aangeraden?
Dit geldt toch voor alle grenzen? Veel grenzen worden bepaald door geografische elementen, zoals rivieren en bergen. Dat is ook het geval bij waterschappen. Daar zijn de grenzen vaak waterscheidingen, rivieren en landscheidingen.
Daarmee is het de 18e meest voorkomende waarde van boundary en geen van de nummers 1 t/m 17 lijkt toepasbaar voor wijk- en buurtgrenzen.
Het wordt aangeraden omdat het:
a) De meest correct beschrijvende tag is. Het zegt letterlijk dat het de grens van een plaats is. In OSM gelden wijken en buurten als plaatsen.
b) Het de meest gebruikte tag is om wijkgrenzen te taggen. Wijkgrenzen taggen gebeurt relatief weinig, waardoor totaal aantal weinig lijkt.
Voor documentatie lijkt het me inderdaad handig om een wiki-pagina van boundary=place aan te maken.
Hoe kom je erbij dat het het meest beschrijvend is? Uit het OP?
Ik raad het zelfs stellig af
Het zal het meest gebruikt zijn in NL omdat boundary=administrative al is weggehaald voor wijken en buurten. Zie OP.
Wereldwijd is het nog maar de vraag.
Logisch gezien vallen wijken onder gemeentes en buurten onder wijken.
Ze zijn ‘administrative’ gedefinieerd dus waarom zou je ze buiten de admin_level hierarchy houden?
Het is het meest beschrijvend, omdat er bij ‘boundary=place’ letterlijk ‘grens van een plaats’ staat.
Wijk- en buurtgrenzen zijn juist geen bestuurlijke grenzen, zoals provincie- en gemeentegrenzen, maar slechts grenzen van een plaats. Dat ze door een bestuur worden gedefinieerd, maakt ze nog niet bestuurlijk (administrative), aangezien dat voor alle grenzen geldt, ook die van een beschermd gebied, postcode-gebied etc.
Jij komt aan met een tegenargument dat het niet gedocumenteerd is. Als een nieuwe tag nog niet gedocumenteerd is, dan documenteren wie die. Zo werken nieuwe tags.
Kennelijk wordt er niet gedocumenteerd.
Het gebruik van boundary=place ipv administrative wordt eerst in OP gesteld als wenselijk en door jou als vaststaand gegeven.
Zonder enig overleg en vastlegging.
Verder lijkt het mij onzinnig als wij hierover in discussie blijven.
Ik heb hierover gezegd wat ik wilde zeggen.
Ik vraag me wel af waarom er zo weinig reactie op is.
Is iedereen het dan eens met het gestelde in OP?
Ik zie dat ene garmin-user alle wijkrelaties in Amersfoort van boundary=place naar boundary=multipolygon heeft gewijzigd. Dit lijkt mij onjuist. Kan ik ze allemaal weer aanpassen naar boundary=place?
Garmin-user schijnt te werken vanuit indicaties door tools. Hij doet dingen vooral om foutmeldingen te laten verdwijnen. Soms werkt hij heel erg snel - terwijl ik een changeset nog open heb, past hij een tijdelijke situatie aan, en als ik één minuut later die fout in Potlatch adresseer, krijg ik een foutmelding. Ik kan me niet voorstellen dat hij echte kennis heeft van alle zaken die hij aanpast. Soms gokt hij juist, en soms niet. Opletten dus!
In dit geval, vermoed ik dat er een of andere tool is die boundary=place niet leuk vind, of iets anders in de tagging. Het is misschien handig om te begrijpen waar de “klachten” vandaan komen.
