You are not logged in.
- Topics: Active | Unanswered
Announcement
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***
#26 2019-10-24 06:20:23
- Tijgerd
- Member
- From: Sittard-Geleen
- Registered: 2019-08-26
- Posts: 34
Re: Grenzen in Nederland
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)
Offline
#27 2019-10-24 12:45:25
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
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?
Offline
#28 2019-10-24 15:05:25
- sebastic
- Member
- Registered: 2012-05-14
- Posts: 261
Re: Grenzen in Nederland
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.
Offline
#29 2019-10-24 15:24:49
- A67-A67
- Member
- Registered: 2014-04-08
- Posts: 783
Re: Grenzen in Nederland
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.
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.
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.
Offline
#30 2019-10-24 22:54:23
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
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?
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.
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.
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?
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.
Offline
#31 2019-10-25 00:29:21
- A67-A67
- Member
- Registered: 2014-04-08
- Posts: 783
Re: Grenzen in Nederland
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.
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.
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.
Offline
#32 2019-10-25 08:34:08
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
...
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?
Offline
#33 2019-10-25 08:57:21
- A67-A67
- Member
- Registered: 2014-04-08
- Posts: 783
Re: Grenzen in Nederland
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.
Offline
#34 2019-10-25 16:09:57
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
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=*.
...
Offline
#35 2019-10-25 16:26:00
- A67-A67
- Member
- Registered: 2014-04-08
- Posts: 783
Re: Grenzen in Nederland
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?
Offline
#36 2019-10-25 18:01:10
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
Vind je dit nou echt een goed argument?
Offline
#37 2019-10-25 18:52:11
- A67-A67
- Member
- Registered: 2014-04-08
- Posts: 783
Re: Grenzen in Nederland
Ik heb twee argumenten gegeven:
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.
Offline
#38 2019-10-25 19:24:22
- mmjo
- Member
- Registered: 2019-09-20
- Posts: 14
Re: Grenzen in Nederland
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?
Offline
#39 2020-12-30 11:52:34
- Riemer17
- Member
- Registered: 2020-06-23
- Posts: 52
Re: Grenzen in Nederland
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)
Offline
#40 2020-12-30 12:30:16
- eggie
- Member
- From: Dordrecht
- Registered: 2010-09-03
- Posts: 4,225
Re: Grenzen in Nederland
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.
Offline
#41 2020-12-30 13:37:25
- Colin Smale
- Member
- From: Maarssen, NL
- Registered: 2010-08-25
- Posts: 190
Re: Grenzen in Nederland
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.
Offline
#42 2020-12-30 15:13:58
- Riemer17
- Member
- Registered: 2020-06-23
- Posts: 52
Re: Grenzen in Nederland
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?
Offline
#43 2020-12-30 15:48:05
- eggie
- Member
- From: Dordrecht
- Registered: 2010-09-03
- Posts: 4,225
Re: Grenzen in Nederland
Yep.. z'n laatste edit was 3 uur geleden.. dus even de kans geven om te reageren. Het is een actieve mapper.
Offline
#44 2020-12-30 18:17:42
- Garmin-User
- Member
- Registered: 2009-10-01
- Posts: 677
Re: Grenzen in Nederland
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)
Offline