Grenzen in Nederland

Tijgerd · 2019-10-24 06:20:23

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.

village (Limbricht): https://www.openstreetmap.org/relation/1421977
town (Geleen): https://www.openstreetmap.org/relation/1421667

EDIT: taalfouten, links, ik was niet helemaal wakker

Last edited by Tijgerd (2019-10-24 07:26:36)

mmjo · 2019-10-24 12:45:25

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?

sebastic · 2019-10-24 15:05:25

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.

A67-A67 · 2019-10-24 15:24:49

mmjo wrote:

boundary=place + place=* komt (vrijwel) niet voor in combinatie met boundary=place

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.

mmjo wrote:

place=* is problematisch als het op een area staat (wordt niet goed weergegeven)

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.

mmjo wrote:

Ik vind sowieso dat adminstrative + admin_level niet passend zijn voor de waterschapsgrenzen.

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.

mmjo · 2019-10-24 22:54:23

sebastic wrote:

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.

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?

A67-A67 wrote:

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.

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.

sebastic wrote:

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 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.

A67-A67 wrote:

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).

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?

A67-A67 wrote:

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.

Een place-node kan inderdaad handig zijn.

A67-A67 · 2019-10-25 00:29:21

mmjo wrote:

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.

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.

mmjo wrote:

1194 x wordt boundary=place wereldwijd gebruikt.

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.

mmjo wrote:

Sowieso is er geen eens een wiki voor boundary=place. Dus waarom wordt dit aangeraden?

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.

mmjo · 2019-10-25 08:34:08

A67-A67 wrote:

...
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.

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?

A67-A67 · 2019-10-25 08:57:21

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.

mmjo · 2019-10-25 16:09:57

Bij boundary=place staat helemaal niks.

Bij place=* staat wel wat.

Verwarring ontstaat wellicht door de term 'administrative'. Of door OP.

Relevante quote uit de wiki voor boundary=administrative:

An administrative boundary. Subdivisions of areas/territories/jurisdictions recognised by governments or other organisations for administrative purposes.
Administrative boundaries range from large groups of nation states right down to small administrative districts and suburbs, with an indication of this size/level of importance, given by the combo tag 'admin_level' which takes a value from 1 to 11 as described below.
...
Many administrative boundaries are currently tagged also with place=*.
...

A67-A67 · 2019-10-25 16:26:00

Dus boundary=place is geen logische tag, omdat het geen wiki-pagina heeft? Dat argument valt toch gewoon weg als we een wiki-pagina aanmaken?

mmjo · 2019-10-25 18:01:10

Vind je dit nou echt een goed argument?

A67-A67 · 2019-10-25 18:52:11

Ik heb twee argumenten gegeven:

A67-A67 wrote:

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.

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.

mmjo · 2019-10-25 19:24:22

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?

Riemer17 · 2020-12-30 11:52:34

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?

Hier de betreffende changeset:
https://www.openstreetmap.org/changeset/81166637

Last edited by Riemer17 (2020-12-30 11:52:48)

eggie · 2020-12-30 12:30:16

Je zou in ieder geval de bewuste mapper kunnen berichten..want die is random over Europa allerlei bouderies aan het 'fixen'.
5 min geleden nog.

Colin Smale · 2020-12-30 13:37:25

Riemer17 wrote:

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.

Riemer17 · 2020-12-30 15:13:58

eggie wrote:

Je zou in ieder geval de bewuste mapper kunnen berichten..want die is random over Europa allerlei bouderies aan het 'fixen'.
5 min geleden nog.

Ja ik wilde hem in ieder geval een bericht sturen. Dat kan gewoon onder de changeset toch?

eggie · 2020-12-30 15:48:05

Yep.. z'n laatste edit was 3 uur geleden.. dus even de kans geven om te reageren. Het is een actieve mapper.

Garmin-User · 2020-12-30 18:17:42

Hello,

I changed the type=multipolygon back to type=boundary + boundary=place:
https://www.openstreetmap.org/changeset/96681835

(Two relations have already been corrected.)

I'm sorry!

Best regards
Mario

Last edited by Garmin-User (2020-12-30 18:18:29)

#26 2019-10-24 06:20:23

Re: Grenzen in Nederland

#27 2019-10-24 12:45:25

Re: Grenzen in Nederland

#28 2019-10-24 15:05:25

Re: Grenzen in Nederland

#29 2019-10-24 15:24:49

Re: Grenzen in Nederland

#30 2019-10-24 22:54:23

Re: Grenzen in Nederland

#31 2019-10-25 00:29:21

Re: Grenzen in Nederland

#32 2019-10-25 08:34:08

Re: Grenzen in Nederland

#33 2019-10-25 08:57:21

Re: Grenzen in Nederland

#34 2019-10-25 16:09:57

Re: Grenzen in Nederland

#35 2019-10-25 16:26:00

Re: Grenzen in Nederland

#36 2019-10-25 18:01:10

Re: Grenzen in Nederland

#37 2019-10-25 18:52:11

Re: Grenzen in Nederland

#38 2019-10-25 19:24:22

Re: Grenzen in Nederland

#39 2020-12-30 11:52:34

Re: Grenzen in Nederland

#40 2020-12-30 12:30:16

Re: Grenzen in Nederland

#41 2020-12-30 13:37:25

Re: Grenzen in Nederland

#42 2020-12-30 15:13:58

Re: Grenzen in Nederland

#43 2020-12-30 15:48:05

Re: Grenzen in Nederland

#44 2020-12-30 18:17:42

Re: Grenzen in Nederland

Board footer