[OSM-talk-nl] Woonplaatsen taggen

[Lennard]

Eugene van der Pijll wrote:
> Helaas kan ik de kaart op mijn (wat oudere) browser niet zien, maar ik
> zie het t.z.t. wel in OSM verschijnen.

Het is 'gewoon' een KML-laagje in OpenLayers. Als OL werkt voor je, dus 
als je de kaart ziet, zou je een KML daarop dan toch ook moeten zien?

> Hoe zit het met de buitengrenzen van de gemeente? Zijn die hetzelfde als
> onze huidige grenzen, of zijn ze nauwkeuriger?

Een stuk nauwkeuriger. En dat lijkt niet alleen zo (de lijnen sluiten 
mooi aan op wegen en wateren), maar van wat ik hier aan lokale kennis 
heb, is dat ook zo.

Alleen als je de KML in Google Earth laadt, dan is er toch weer een 
shift met de GE laag, dus dat moet je zeker niet als leidraad nemen. Op 
onze OSM kaart ligt de KML er echt heel strak op.

Bij het importeren wil ik dus ook de al beschikbare OSM grenzen 
verfijnen aan deze nieuwe data.

> Er zijn trouwens een groot aantal gemeenten met maar 1 woonplaats; die
> hoef je in principe niet aan te schrijven. Die kan je herkennen doordat
> ze in hun woonplaatsbesluit maar 1 woonplaatsnaam noemen.

Daarvoor zul je toch eerst het Woonplaatsbesluit op moeten vragen, want 
die zijn maar van een minderheid van de 441 gemeenten online te vinden.

> admin_level=X heeft als nadeel dat dat niet zegt dat deze grenzen met
> adressering te maken hebben. Op een gegeven moment moeten deze grenzen
> gebruikt gaan worden voor iets als de internationale Namefinder
> service, om adressen te zoeken.

Ik zie geen enkel probleem, juist omdat het binnen het admin_level 
schema valt.

> Eerder kwam het voorstel langs om admin_level=10 te gebruiken; maar een
> "woonplaats" is (over het algemeen!) groter dan een deelgemeente, en
> moet dus een lager admin_level hebben.

Moet? Dat is jouw interpretatie van admin_level blijkbaar, dat er een 
strakke hiërarchie aanwezig moet zijn, zodat elk lager niveau compleet 
binnen het opeenvolgende hogere niveau past. Dat is nergens vastgelegd, 
maar meer een gevolg van de opbouw van overheden in veel landen.

Ik hoef alleen maar naar onze zuiderburen te kijken, om gelijk al te 
zien dat het niet werkt. De grenzen van gewesten, gemeenschappen en 
provincies (resp admin_level 4/5/6 daar) zijn niet in een hiërarchie te 
vatten, en lopen op plekken door elkaar heen.

>>> Overigens moeten we de waterschappen ook nog een keer kwijt zien te
>>> raken in het model. Die grenzen lopen vaak totaal niet gelijk met
>>> gemeentegrenzen.
>> boundary=administrative, admin_level=5
> Slecht idee, want sommige waterschappen bevinden zich in 2 provincies.

Maar een provincie bevindt zich niet compleet binnen een Waterschap. 
Catch-22. Zou je de waterschappen dan op admin_level=3 zetten, dan is er 
ook al geen hiërarchie.

In Nederland hebben we overigens ook nog de COROP-regio's (NUTS 3), die 
de provincies weer opdelen. Die zouden beter op admin_level=5 passen dan 
waterschappen.

En dan kun je de Nederlandse NUTS-1 al niet eens meer kwijt, hoewel die 
zit ook tussen 2 en 4, qua dekking.

> Het admin_level-systeem is hierarchisch opgebouwd; iedere grens die

Zie boven. De enige hiërarchie is slechts schone schijn. De gedachte 
achter admin_level was dat er enige mate van overeenkomst is tussen 
verschillende landen, zodat er overal wel grenzen gerenderd kunnen 
worden voor entiteiten van ongeveer gelijke belangrijkheid.

> getagd is op niveau 2 ("Nederland") is tegelijk een 4-grens (provincie),
> en iedere provincie-grens is een gemeente-grens.

We gebruiken relaties voor grenzen. Ik zie het als een non-issue.

> Toepassingen die de afzonderlijke ways gebruiken raken in de war als we
> van dat principe afstappen.

Noem er eens een paar, relevante?

-- 
Lennard