"Rendering" van dorp/stad naam-node als label van grens

Communities Nederland (Netherlands)
1

Laat ik voorop stellen dat ik weet dat “mapping for renderer” niet de bedoeling is.
Ik weet echter niet zozeer of dit een renderer probleem is of dat ik iets over het hoofd zie met tagging.

Een aantal dagen terug ben ik bezig gegaan met het toewijzen van naam-nodes van steden/dorpen als labels van de grensrelaties.

Ik heb dit eerst gedaan met Munstergeleen.
Als je nu bij openstreetmap.org zoekt op munstergeleen krijg je heel fijn één resultaat, namelijk het dorp “Munstergeleen”.
In mijn inziens is dit een stuk beter dan wanneer je meerdere resultaten krijgt voor 1 dorp of stad. (One feature, one OSM element)

Het valt mij daarnaast ook op dat bijna overal de regel “One feature, one OSM element” enigszins wordt overschreden.
Zowel op de grens-relatie als de name-node is heel veel informatie “dubbel” te vinden.

**Nu de reden waarom ik eigenlijk deze post startte: **
Ik heb zoals eerder beschreven wat naam-nodes aan grens relaties toegevoegd.
Wanneer ik nu Geleen of Sittard opzoek krijg ik mooi, zoals denk ik gewenst, slechts 1 resultaat voor de desbetreffende stad.
Wanneer ik echter Limbricht op zoek krijg ik nog steeds zowel de naam-node als de grens-relatie los te zien.
Weet iemand wat ik fout doe? Doe ik daadwerkelijk iets fout?

Bij voorbaat dank!

2

Waarom ben je verbaast deze node te vinden? https://www.openstreetmap.org/node/42125183

3

Omdat de node van Geleen ( https://www.openstreetmap.org/node/4004062547 ) niet “los” te vinden is.
Als je naar “Geleen” zoekt krijg je alleen de grensrelatie, welke wordt weergegeven als de daadwerkelijke stad.

4

Misschien het verschil tussen place=town en place=village en de link met de admin_level=* ?

5

Ik denk dat dit gewoon een inconsistentie in de code van Nominatim is. Nominatim heeft veel bugs en te weinig programmeurs om die op te lossen.

6

Dat denk ik ook, maar het zou eigenlijk geen verschil moeten maken

Dat denk ik ook, vandaar dat ik op github deze “issue” net heb aangemaakt.

Ik vraag me wel oprecht af of alle informatie die terug te vinden is op zowel de grens-relatie als de plaats-node niet in strijd is met “One feature, one OSM element”…

Ik neem echter aan dat hier al eens een discussie over is geweest en mocht iemand er het antwoord op weten dan hoor ik het graag :slight_smile:

7

Net een bericht terug van de Nominatim developer, het schijnt dat als je niks aan posities van nodes doet, Nominatim dit niet zit als een update en deze dus ook niet doorvoert.

8

Dat is dus duidelijk een fout van Nominatim en niet van Openstreetmap zelf.

9

Helemaal waar!

Blijft mij wel nog de vraag of het “verspreiden” van de informatie op zowel de grens-relatie als de place-node niet tegen de richtlijnen van OSM in gaat…

10

Het gaat inderdaad tegen de richtlijnen in, maar het weglaten bij ofwel de grens ofwel de place-node zal ervoor zorgen dat datagebruikers de informatie lastiger kunnen vinden. Vooral als de informatie inconsistent wordt weggelaten, dus soms bij de grens en soms bij de place-node.

11

Is dit niet het moment om daar met de community een discussie over te voeren? (uiteraard in een nieuw topic)

Mijn persoonlijke mening is dat de grens-relatie de infromatie dient te bevatten en dat de label-node puur en alleen wordt gebruikt om de plaatsnaam op een gunstige plek te plaatsen.

12

Ik zou in ieder geval ook eens kijken hoe dat in de ons omringende landen wordt gedaan. Het heeft weinig zin om weer iets geheel afwijkends op te tuigen.
Met de volgende code kun je snel wat onderzoek doen. Ik heb hamlet maar even eruit gelaten…

[out:json];
(
  node["place"~"village|town|city"]({{bbox}});
  way["boundary"="administrative"]({{bbox}});
  relation["boundary"="administrative"]({{bbox}});
);
out body;
>;
out skel qt;

=====
edit: overpasscode aangepast zodat hij zowel boundary als place-node vindt.