Volgens de CBS worden ook de wijk- en buurtgrenzen bepaald door de gemeente. Naast statistiek hebben ze volgens mij ook een functie bij wijkraden, buurtcommissies e.d.
https://www.cbs.nl/nl-nl/faq/specifiek/waar-vind-ik-een-kaart-van-de-wijk-en-buurtindeling-/
Ah, nou, duidelijk! Het was van mijn kant inderdaad een totale aanname, aangezien ik wijk- en buurtindelingen gezien heb die totaal niet passen bij de dagelijkse werkelijkheid. Waardevolle correctie!
Met alle respect voor jouw werk maar dit druist tegen alle afspraken in. Ik snap totaal niet waarom je de wijkindelingen zomaar heb afgeschaft zonder enig overleg met de cummunity.
Woonplaatsgrenzen zijn de uitzondering op de regel van een eigen bestuur. Woonplaatsen zijn de officiële verdeling van en door gemeenten, en essentieel voor adres bepaling in OpenStreetMap. Ze staan daarom onderaan de hiërarchie.
Ik vermoed dat je bent getriggered door de verwijdering van de wijken in Amersfoort. Als je veel waarde hecht aan het aanwezig zijn van de Amersfoortse wijken in OSM ben ik bereid deze terug te plaatsen met aangepaste tagging. Als je slechts bezwaar hebt tegen het gebrek aan overleg vooraf, is dat bezwaar genoteerd.
Dat klopt, ben niet blij met het zonder overleg verwijderen van de wijkgrenzen van Amersfoort. Deze zijn door de gemeente vastgesteld en beschikbaar gesteld tbv OSM. Dus als je ze terug wilt plaatsen met aangepaste tagging zou ik dat zeer op prijs stellen.
Ik heb de wijken en buurten van Leeuwarden toegevoegd, maar het zijn niet klakkeloze kopieën van de CBS-brondata. De CBS-wijken en -buurten komen meestal overeen met hoe een wijk of buurt lokaal bekend is, maar lang niet altijd. In Leeuwarden zijn er een aantal voorbeelden van naamgeving die niet lokaal (wijkverenigingen, lokale media, bewoners) gehanteerd wordt, en soms ontbreken er nuances bij de grenzen (dit geldt vooral voor kleine buurtjes die statistisch gezien te klein zijn voor het CBS).
Boundary=statistical zou bij deze wijken en buurten absoluut niet kloppen. Dit zijn voor zover mij bekend de grenzen van de wijken en buurten zoals de Leeuwarders ze kennen en benoemen, niet de statistische grenzen van het CBS. Ik heb de CBS-data als basis gebruikt, omdat hun grenzen voor 95% overeen komen met wat reëel gezien ook de grens van een wijk/buurt is.
Aan de changeset te zien heb je alleen de administrative-tags weggehaald, klopt dat?
Ik heb daar op zich geen bezwaar tegen, omdat boundary=place, place=neighbourhood/quarter dezelfde wijk/buurt-nuance heeft.
Ik zou andere mappers die met de CBS-data aan de gang willen gaan ook willen stimuleren om dezelfde aanpak te hanteren: gebruik de CBS-grenzen als basis, maar vel je eigen oordeel. Het gaat dus met name nog wel eens mis bij naamgeving en kleine buurten bij de CBS-data.
Je ziet het bij sites zoals Funda ook: huizen in wijk ‘X’ (CBS-naam) terwijl geen enkele daadwerkelijke bewoner van die wijk de wijk zo noemt.
De Händelstraat in Leeuwarden ligt bijvoorbeeld in de Componistenbuurt, en veel Leeuwarders noemen die buurt ook wel de Muziekwijk, beide namen staan erin op OSM — het CBS (en dus ook Funda en wie weet wat meer) noemt hem doodleuk Sonnenborgh (een naam die de gemeente zelf ook niet hanteert), maar je gaat hier geen Leeuwarder vinden die weet waar dat ligt, behalve mensen die nog weten dat dat een verzorgingshuis was en dat het een historische naam is van (volgens mij) een boerderij of buitenplaats, en de naam van een plaatselijke kaatsclub.
Done: https://www.openstreetmap.org/changeset/67018832
De admin_level tags zijn verwijderd, zie: https://www.openstreetmap.org/changeset/66974128
En daarvan bijvoorbeeld: https://www.openstreetmap.org/way/625930112/history
Ook de geometrie van de CBS data laat te wensen over, en komt vaak niet overeen met woonplaats en gemeentegrenzen.
Daarom zou ik de wijken en buurten liever geen boundary ways laten delen met de officiële administratieve grenzen zodat de geometrieën volledig gescheiden zijn. Dit is momenteel niet het geval in Leeuwarden en Amersfoort.
De geometrieën sluiten in werkelijkheid ook exact op elkaar aan. Een wijk aan de rand van een gemeente loopt doorgaans tot aan de gemeentegrens en volgt die daar exact.
Ik gebruik in Leeuwarden alleen de binnengrenzen van het CBS, en soms zelf ingetekend waar het CBS niet volstaat of achterloopt. De buitengrenzen (stad en gemeente) hergebruik ik uiteraard; dat is voor grenzen logisch, want zo wordt dat ook bij plaats-, gemeente- en landsgrenzen gedaan. Anders krijg je overlappende ways die exact op dezelfde plek liggen, en exact hetzelfde segment ‘grens’ markeren.
Bijvoorbeeld deze wijk, die als onderdeel van zijn grens dit stuk gemeentegrens gebruikt.
En hier een voorbeeld waarbij een gemeentegrens een landsgrens hergebruikt.
Daarbij volg ik de gangbare OSM-wijze waarop de hoogste hiërarchie leidend is voor de tagging van het stuk grens. In bovenstaand geval is dat de gemeentegrens.
Uiteraard is het niet de bedoeling dat de CBS-grenzen bestaande gemeente- en plaatsgrenzen vervangen. Die worden immers prima bijgehouden op OSM.
Niet alle metropoolregio’s zijn verdwenen. In ieder geval bestaan de Metropoolregio Rotterdam-Den Haag (https://mrdh.nl/) en de Metropoolregio Eindhoven (https://metropoolregioeindhoven.nl/) nog, alhoewel met minder bevoegdheden dan ze als plusregio hadden. Ik zie wel dat ook de nog bestaande metropoolregio’s uit OSM zijn verwijderd.
Nog even een vraagje, Nijmegen is formeel door de gemeente ingedeeld in stadsdelen, wijken en buurten, zoals ook opgenomen in de BAG. Als we voor deze indeling niet meer de administratieve grenzen kunnen gebruiken, hoe moet deze indeling dan wel gemapt worden? Ik neem aan dat we daar dan respectievelijk place=suburb, place=quarter en place=neigbourhood voor gaan gebruiken.
Als dat zo is dan vraag ik me wel af waarom sebastic alle grenzen heeft verwijderd en niet omgetagged heeft naar deze nieuwe indeling.
Dat weet ik niet. Ik heb in Venlo de wijken die ik belangrijk vind als node ingetekend met
place=quarter
name=Xxxx
Je kunt Sebastic met een persoonlijk bericht vragen wat er gebeurd is?
Nijmegen heeft zo te zien (taggen voor de renderaar, fout he 
) geen wijken en ziet er een beetje kaal uit 
Nou gewoon zoals jij dat wil want jij bent een van de plaatselijke mappers.
Er is m.i. geen toegevoegde waarde voor grenzen die niet voor adressering of bestuur gebruikt worden.
De wijk/buurt grenzen die in OSM stonden waren veelal eenmalig geimporteerd en sindsdien nooit meer geupdate, en verliezen zodoende ook aan waarde.
Als men grenzen onder woonplaatsniveau in OSM wilt hebben voor hun stad, moet dit net als de BAG import actief onderhouden worden.
Dat is een persoonlijke mening. De gemeente stelt deze grenzen echter niet voor niets vast. Zo worden onder andere inrichting en onderhoud van de openbare ruimte, ontwikkelingsthema’s, stadsgetallen en wijkbeschrijvingen gebaseerd op deze grenzen.
Is dat niet het hele principe van OSM? Natuurlijk heeft een kaart in een veranderende omgeving actief onderhoud nodig, maar dat is toch waar wij met z’n allen continue mee bezig zijn?
Je geeft aan dat de grenzen veelal na de import niet meer geupdate waren. Ik vraag me af waarop dat gebaseerd is. Dit soort grenzen veranderen gelukkig niet regelmatig. Voor Nijmegen kan ik garanderen dat ze up-to-date waren voordat ze verwijderd werden.
In het geval van de wijk/buurt grenzen is dat niet waar de lokale community mee bezig is.
Historie van de objecten, en vergelijking met recente CBS data.
Grenzen veranderen vaker dan je zou denken. Nieuwbouw en wegomleggingen zijn hier vaak de oorzaak van.
De wijk/buurt grenzen zullen actief gemonitored moeten worden om dit soort wijzigingen te detecteren en gebruiken als trigger voor een update in OSM.
Mooi dat dit automatisch bijgehouden kan worden.
En fijn dat je dat doet sebastic.
Wat ik nu wel zie in Amsterdam/Diemen/Duivendrecht is dat er wel wijk- en buurtgrenzen worden getrokken.
Deze maken dan gebruik van landuse=residential, name=… (en evt. place=neighbourhood).
Die grenzen lopen vervolgens door allerlei andere gebieden heen (b.v. landuse=grass/comercial).
Wat weer aanleiding is voor warnings in josm (Overlapping Areas).
Persoonlijk vind ik dat er geen warnings en errors mogen zijn. Ben ook bezig om die op te lossen.
Maar met al die overlappende landuse grenzen is het wel lastig.
Wat foutmeldingen betreft, zou boundary=administrative beter uitkomen.
Daar wordt, volgens mij, niet geklaagd over overlappende grenzen. In ieder geval niet bij overlap boundary/landuse.
Wat is het idee om hiermee om te gaan?
PS.
De aanleiding.
Verschillende foutmeldingen over overlappende gebieden:
https://www.openstreetmap.org/way/45463132
Voor gebieden in Amsterdam, in dit geval Frankendael: https://gebiedinbeeld.amsterdam.nl/#/dashboard?gebied=DX15&wijk=M55&buurt&thema=Gebied%20in%20het%20kort
Dit komt dus sowieso niet goed overeen met osm.
Met name dan het stukje bij de Amstel (Van der Kunbuurt).
Maar ik weet vooralsnog niet hoe dit te automatiseren.
PPS.
Dit schema is wel mooi orthogonaal (een provincie in het ene land ligt niet ook in een ander).
Maar het heeft wat inflexibels:
landuse=* is voor de geometrie van CBS wijken & buurten niet juist, boundary=administrative is dat ook niet.
Zie het voorbeeld van Leeuwarden in de OP voor een acceptabel alternatief.
Daarnaast zorgt het taggen van de naam op de residentials dat de wijkgrenzen totaal niet kloppen. De naam wordt getagd op het woongedeelte van Frankendael, waardoor het lijkt alsof de andere delen, zoals het park en verschillende grasvelden aan de rand, niet tot Frankendael behoren.
Samenvattend:
boundary=administrative + admin_level=* (admin_level <= 11)
wordt alleen gebruikt voor addressering; automatisch import
boundary=statistical + border_type=district/neighborhood
voor een CBS wijk/buurt
boundary=place + place=quarter/place=neighbourhood
wordt gebruikt in Leeuwarden
Ik heb daar een aantal dingen bijgezocht:
boundary=statistical[list=*]
heeft geen wiki
is niet vaak gebruikt: taginfo
inconsistent gebruik
wordt niet gebruikt door Nomatim (geocoding, naam → coordinaat)
border_type=district wordt zelfs expliciet afgeraden
heeft geen wiki
laag gebruik taginfo
boundary=place + place=[list=]
komt (vrijwel) niet voor in combinatie met boundary=place
place=* is problematisch als het op een area staat (wordt niet goed weergegeven)
er wordt gesteld dat admin_level=* moet worden toegevoegd voor door de overheid bepaalde plaatsen
Wat sebastic, volgens mij, zegt is dat de boundary=administrative + admin_level=* gebruikt kan worden voor wijken/buurten.
Maar dan moeten de grenzen wel hiërarchisch kloppen met de automatisch geïmporteerde grenzen (1…10 voor zover gebruikt).
Bovendien moeten de grenzen gedefinieerd zijn door de overheid.
En de grenzen moeten ook onderhoudbaar zijn (dit impliceert automatische import - of niet?).
Het gebruik van landuse=residential + name=* is niet gewenst voor grenzen.
Het gebruik van border_type is problematisch.
Mijns inziens, zouden grenzen die niet precies in de hierarchie vallen een andere boundary=* moeten hebben.
De grenzen van waterschappen (volgens de wiki boundary=administrative + admin_level=5) passen niet in de hiërarchie.
Voorstel boundary=water_management?
Worden de waterschapsgrenzen automatisch geimporteerd?
(hmm, ik zie geen waterschapsgrenzen, mis ik wat?)
Volgens het CBS krijgen zij de gemeentegrenzen uit de BRK.
Wijk- en buurtgrenzen worden (via opgave van gemeentes) in een shape file beschikbaar gesteld (licentie probleem: bronvermelding; misschien ook beschikbaar via PDOK - moet ik nog uitzoeken).
Met de CBS gegevens op wijk/buurt niveau zijn nog wel problemen:
Bij voldoende consensus ben ik wel bereid om wiki pagina’s hierover aan te maken (Nederlands en/of Engels).
Daarvoor zou ik eigenlijk ook nog willen weten welke bronnen gebruikt worden voor de automatische import(s).
En liefst ook met uitleg hoe je die importeert.
Kun jij dit aanleveren, sebastic?
Opmerkingen/aanvullingen, ik hoor ze graag.
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.