Doppelte Ortsbezeichnungen

Der doppelte Ortsname kommt bestimmt von den Grenzrelationen zu dne einzelnen Gemeinden wie z.B. http://www.openstreetmap.org/browse/relation/1268995

Ähnliche Effekte kann es auch geben, wenn die Postleitzahlen-Bereiche als Grenzrelationen erfasst sind, wie etwas nördlich bei Mihla z.B.

stephan75 wrote:

Der doppelte Ortsname kommt bestimmt von den Grenzrelationen zu dne einzelnen Gemeinden wie z.B. http://www.openstreetmap.org/browse/relation/1268995

Ähnliche Effekte kann es auch geben, wenn die Postleitzahlen-Bereiche als Grenzrelationen erfasst sind, wie etwas nördlich bei Mihla z.B.

Jetzt musste ich erst mal lange suchen, bis ich die entsprechenden Tags in der Relation gefunden habe.

Das Problem ist offensichtlich, dass die Relation mit einem "Name =" Tag versehen wurde.

Das "is_in=" Tag its auch mit einem "name=" Tag versehen.

Also müsste man sich einig werden, wo man den "name=" Tag weg lässt und dort ggf. ein "note=" Tag dafür einsetzt. Ich werd mal das WIKI checken.

Aber eigentlich mappen wir ja nicht für die Renderer 😉

Gruß

Volker

Edit: WIKI gecheckt: Sowohl die boundary Relation als auch der "is_in=" Tag werden mit einem "name=" Tag versehen...

Stellt sich die Frage, ob man die ganzen Place-Nodes nicht zu Gunsten ihrer Grenzrelationen abschaffen sollte (natürlich nur da, wo auch Grenzen existieren).

aeonesa wrote:

Edit: WIKI gecheckt: Sowohl die boundary Relation als auch der "is_in=" Tag werden mit einem "name=" Tag versehen...

sorry, wie soll das den gehen? tag an einen tag setzen????

der name=*-tag wird übrigens von nominatim und anderen programmen verwendet, um die administrative grenze der gegend zu kennen.(was liegt wo?)

renderer werten auch sehr gerne landuse=kleinkleckersdorf aus. wenn da dann noch ein place=village steht, haben wir es schon doppelt.

gruss
walter

Das ist mehr ein Renderingproblem. Gibt man den Namen eines Landkreises bei openstreetmap.org ein, wird man auch an die Stelle geleitet, an dem dieser bei hoher Zoomstufe zu sehen ist, was natürlich ziemlich sinnlos ist. Ob man das aber wirklich ändern kann, wird schwer, da die admin_level international für ziemlich verschiedene Dinge verwendet werden können und Mapnik sich dafür entschieden hat, alles ab admin_level=5 darzustellen.

Über is_in braucht man nicht zu diskutieren, das interessiert keinen mehr da dafür die boundary da sind. is_in gehört gelöscht.

Ob es sinnvoll ist Place-Nodes innerhalb einer benannten Fläche zu löschen, wurde bereits häufiger diskutiert.
Ich war ursprünglich grundsätzlich für die Löschung, weil man für Flächen POI-Overlays erstellen kann.
Es gibt allerdings ein wichtiges Gegenargument.

Bisherige Renderpraxis ist, daß das POI-Overlay in die geometrische Mitte der Fläche gesetzt wird und dort erscheint dann auch der Name des Polygons. Bei entsprechender Polygonform (Straßendörfer) können die Ortsnamen in die umliegenden Felder geraten.
Ohne die Erzeugung eines POI-Overlays hängt der Name des Polygons nur an der Fläche und wird abhängig vom Anzeige-Programm nur auf Abruf (Fläche mit MausCursor berühren) oder in der Fläche wandernd oder gar nicht angezeigt.
Die Suchfilter der mir bekannten GPS-Geräte werten bei der Städtesuche POIs aus und steuern diese als Ziel an.
Würde jedes Ortszentrum mit einem POI markiert, könnte man sich die POI-Overlays für die Residential-Flächen sparen. Und die verdoppelte Anzeige der Namens-POIs würde aufhören. Doch solange da keine Einigkeit herrscht (und das wird es wahrscheinlich nie), bleibt einem nur die Wahl zwischen zwei Übeln:
- doppelte Anzeige
- ein Teil der Ortsbezeichnungen fehlt und der Ort wird von Suchfiltern der GPS-Geräte-Karten nicht erfaßt

Eine Lösungsidee (irgendwo gelesen) ist, Place-Node und residential-Polygon in mit Hilfe einer Relation in Beziehung zu setzen und dann das Overlay-POI an die Place-Node-Position zu setzen. Da die geometrische Mitte eines residential-Polygons nicht zwangsläufig das Zentrum eines Ortes darstellt, hätte das zusätzlich den positiven Effekt, daß man beim Navigieren in die Ortsmitte gelenkt wird und nicht mit etwas Pech irgendwo in die Pampa.

Das name-tag am Polygon ist in jedem Fall wichtig. Der für mich persönlich wichtigste Grund: in Garmin-Karten kann man dadurch schnell und unkompliziert herausfinden, in welchem Gebiet man sich gerade befindet.
Das place-tag an residential-Polygonen ist für die zoom-Einstellungen wichtig. Damit kann man ein ranking erstellen.

Die Problematik scheint mir ziemlich komplex zu sein.
Wer nur eine Perspektive kennt und voreilig Nodes und Tags ausräumt, kann dabei viel Schaden anrichten.

Gruß
tippeltappel

Es geht ja nicht unbedingt um residential-Polygone. Denen einen Namen zu geben halte ich im allgemeinen für unsinnig. Aber die Namen der Grenzrelationen werden ja ebenfalls gerendert - und eigentlich sagt die Grenzrelation bereits alles über einen Ort aus, was auch der place-Node ausdrücken kann. Das mit den Formen mancher Dörfer stimmt zwar, ist aber ja ein Rendererproblem und keines der Datenerfassung.

errt wrote:

Es geht ja nicht unbedingt um residential-Polygone. Denen einen Namen zu geben halte ich im allgemeinen für unsinnig.

+1

errt wrote:

Aber die Namen der Grenzrelationen werden ja ebenfalls gerendert - und eigentlich sagt die Grenzrelation bereits alles über einen Ort aus, was auch der place-Node ausdrücken kann.

+1 . Allerdings hast Du speziell bei Dörfern das Problem, dass die Gemarkungen um die Dörfer herum riesig sind und dann der Ortsname irgendwo erscheint

Der place node (POI ?) liegt ja meistens mitten im Dorf. Und hier in der Gegend hat Mirko Küster, der ja leider nicht mehr dabei ist. Die Daten für den Place node aus irgendeiner Datenbank mit Gemeindeschlüssel usw. (Leider nicht für alle Orte) eingetragen. Das sieht nach einer standardisierten Maske aus. Deshalb wollte ich auch nicht drin rumpfuschen. Es beißt sich halt mit der Grenzrelation.

Deshalb wollte ich das Problem mal zur Sprache bringen um ggf. einen Kompromiss zwischen beiden zu finden.

Gruß

Volker

errt wrote:

Aber die Namen der Grenzrelationen werden ja ebenfalls gerendert

hast du bitte mal ein Beispiel (link). ich möchte da mal was checken und nicht Äpfel mit Birnen vergleichen.

mfg
walter

http://www.openstreetmap.org/?lat=50.65 … 4&layers=M

Da hast du gleich drei: Ranis, Seisla, Schmorda

Gruß BBO

errt wrote:

und eigentlich sagt die Grenzrelation bereits alles über einen Ort aus, was auch der place-Node ausdrücken kann.

Aber die Grenzrelationen beinhalten doch für gewöhnlich keinen place-Tag?! Wenn dieser fehlt ist es nicht möglich festzustellen ob es sich um Stadt oder Dorf handelt und das rendern in den Unterschiedlichen Zoomstufen funktioniert nichtmehr.

Gruß BBO

BBO wrote:

errt wrote:

und eigentlich sagt die Grenzrelation bereits alles über einen Ort aus, was auch der place-Node ausdrücken kann.

Aber die Grenzrelationen beinhalten doch für gewöhnlich keinen place-Tag?! Wenn dieser fehlt ist es nicht möglich festzustellen ob es sich um Stadt oder Dorf handelt und das rendern in den Unterschiedlichen Zoomstufen funktioniert nichtmehr.

Gruß BBO

das geht über den admin_min-level ganz gut.
gruss
walter

wambacher wrote:

das geht über den admin_min-level ganz gut.

Wo gibts dazu eine Doku? Oder meintest du admin_level?
admin_level=8 reicht doch auch von einer 8-Einwohner Gemeinde bis zur 25.000-Einwohner Stadt?!
Das sollte trotzdem in einigen Zoomstufen zu Überfüllung oder Leere führen?!

Gruß BBO

BBO wrote:

http://www.openstreetmap.org/?lat=50.65 … 4&layers=M

Da hast du gleich drei: Ranis, Seisla, Schmorda

Gruß BBO

thanks,

jo, "leider" alles ok 😉 hatte da nen verdacht aber war nix.

östlich von laskau knallt er auch noch die plz hin. ist eigentlich total uninformativ, wenn mitten in der pampa (sorry liebe laskauer) plötzlich ne freischwebende plz steht.

gruss
walter

BBO wrote:

Wo gibts dazu eine Doku? Oder meintest du admin_level?

Gruß BBO

Hallo BBO,

sowohl für die Grenrelation als auch für den place Tag (is_in=) war es eigentlich relativ einfach über die WIKI Suchfunktion zu finden bzw. über "How to map". Aber frag mich jetzt bitte nicht nach Links.

Gruß

Volker

aeonesa wrote:

Hallo BBO,

sowohl für die Grenrelation als auch für den place Tag (is_in=) war es eigentlich relativ einfach über die WIKI Suchfunktion zu finden bzw. über "How to map". Aber frag mich jetzt bitte nicht nach Links.

Hallo, jop, Danke, die warn mir bekannt. Zu "admin_min-level" fand ich halt nichts, aber da hat er sich wahrscheinlich vertippt.

Gruß BBO

BBO wrote:

aeonesa wrote:

Hallo BBO,

sowohl für die Grenrelation als auch für den place Tag (is_in=) war es eigentlich relativ einfach über die WIKI Suchfunktion zu finden bzw. über "How to map". Aber frag mich jetzt bitte nicht nach Links.

Hallo, jop, Danke, die warn mir bekannt. Zu "admin_min-level" fand ich halt nichts, aber da hat er sich wahrscheinlich vertippt.

Gruß BBO

jo hat er, wenn ich mit "der" gemeint war 😉

BBO wrote:

Aber die Grenzrelationen beinhalten doch für gewöhnlich keinen place-Tag?! Wenn dieser fehlt ist es nicht möglich festzustellen ob es sich um Stadt oder Dorf handelt und das rendern in den Unterschiedlichen Zoomstufen funktioniert nichtmehr.

Gruß BBO

Nein, aber man könnte ihn da ja durchaus dranhängen. Im Endeffekt ist es ja das gleiche, wie wenn ich bei einem shop einen eingetragenen Node lösche und dafür alle Informationen an das Gebäude außenrum hänge. Klar, man müsste erst definieren, dass Grenzrelationen place-Tags haben dürfen, aber ich sehe grundsätzlich nichts, was dagegen spricht.

errt wrote:

Nein, aber man könnte ihn da ja durchaus dranhängen. Im Endeffekt ist es ja das gleiche, wie wenn ich bei einem shop einen eingetragenen Node lösche und dafür alle Informationen an das Gebäude außenrum hänge. Klar, man müsste erst definieren, dass Grenzrelationen place-Tags haben dürfen, aber ich sehe grundsätzlich nichts, was dagegen spricht.

Das könnte man natürlich, wäre auch sinnvoll. Ich war nur über deine Aussage oben verwundert und dachte ich hätte etwas verpasst.

Gruß BBO

Ich habe mal irgendwo gelesen, dass man den place-node in die Grenz-Relation einbauen könnte. Dann kann man die Daten da speichern wo man sie braucht (name in der Relation, place im node oder wie auch immer) und das Zentrum ist auch markiert, denn zusammen gehört es ja irgendwie schon. Vielleicht wäre das ein Ansatz, redundante Informationen im Sinne einer konsistenten Datenstruktur zu vermeiden.

Das könnte evtl. gefährlich werden, weil, wie ich schon oben geschrieben habe, die Gemarkungen gegenüber den bebauten Flächen sehr groß sind. Da hast Du den Dorfnamen dann irgendwo in der Pampa.

Aber probieren könnte man das mal.

Gruß

Volker

Ja, aber das ist eben eher ein Rendererproblem. Gut, man macht es dem Renderer auch ziemlich schwer, herauszufinden, wo er am Besten den Namen rendern würde, aber theoretisch kann er sich ja eine besser geeignete Stelle suchen als mitten in der Pampa 😉

Wenn der place node Teil der Relation ist sollte sowohl jeder Routeing Engine als auch jedem vernünftigen Renderer klar, wo das Zentrum liegt und wo der name gerendert werden soll - nämlich da, wo der place node ist. Wenn er Teil der Grenzrelation ist, brauch er allerdings nicht mehr den name Tag und auch einige andere Tags würden dann nur noch in der Relation gespeichert. Alles in allem also eine Vereinfachung.

keinseier wrote:

Wenn der place node Teil der Relation ist sollte sowohl jeder Routeing Engine als auch jedem vernünftigen Renderer klar, wo das Zentrum liegt und wo der name gerendert werden soll - nämlich da, wo der place node ist. Wenn er Teil der Grenzrelation ist, brauch er allerdings nicht mehr den name Tag und auch einige andere Tags würden dann nur noch in der Relation gespeichert. Alles in allem also eine Vereinfachung.

hi,

schaut euch mal die grenzen in der schweitz an. dort wird sowas intensiv gemacht. aber wie sich dabei welche software verhält, kann ich nicht sagen.
eventuell steht bei denen was im wiki?
gruss
walter

aeonesa wrote:

Hallo,

beim Betrachten meiner Mapping Resultate habe ich in verschiedenen Orten im Wartburgkreis und auch in Eisenach eine doppelte Ortsbezeichnung in Mapnik gefunden (ab Layer 14).

Hat jemand dafür eine Erklärung ?

Um nochmal (etwas ausschweifend) auf die eigentliche Frage zurückzukehren.:
Ich stelle fest, dass die Mehrzahl der Flächen von Städten und Gemeinden mit 'landuse=residential' getaggt wird.
Das kann nicht richtig sein, denn die eigentliche Wohnfläche ist nur ein Teil der Siedlungsfläche, wie auch Gewerbegebiete, Parkflächen, etc.
Das Wiki besagt dazu eindeutig

Die Ausdehnung des mit landuse=residential erfaßten Gebietes soll lediglich den tatsächlich besiedelten Bereich markieren und nicht das gesamte (auch unbesiedelte) Gemeindegebiet. Die Ausdehnung von landuse=residential ist also nicht in jedem Fall identisch mit town oder village.

Nun hatte ich mich in Deutschland und im benachbarten Ausland einmal umgeschaut um zu sehen wie dies überwiegend gehandhabt wird und stieß dabei auch auf einige Gemeinden im Raum Thüringen, in welchen ich die Erklärung für die doppelten Ortsnamen fand.
Dort hat man neben den Node ('place=*' + 'name=*') auch die Fläche der Gemeinde mit 'landuse=residential' + 'place=*' + 'name=*' versehen und so erscheint durch das doppelte "place+name" auch der Ortsname doppelt.

Ich bin jetzt für mich dazu übergegangen die Gemeideflächen meiner Region mit 'place=*' (aber ohne 'name=*') zu taggen und dazu den entsprechenden Node (place + name) im Zentrum.
Der Fläche 'place=*' füge ich den Tag 'layer=-1' hinzu um Probleme mit anderen (eventuell bereits bestehenden) Flächen zu vermeiden.
O.k., ich weiß jetzt werden die "Multipolygon-Fetischisten" wieder aufschreien, aber wozu soll ich nun daraus Multipolygone erstellen; die Gemeindefläche ist doch im Prinzip nur eine virtuelle Fläche und kann somit auch den Layer-Tag verkraften.

mfG Michael

Die Ausdehnung des mit landuse=residential erfaßten Gebietes soll lediglich den tatsächlich besiedelten Bereich markieren und nicht das gesamte (auch unbesiedelte) Gemeindegebiet. Die Ausdehnung von landuse=residential ist also nicht in jedem Fall identisch mit town oder village.

Ist imho so zu verstehen das nicht Felder, Wälder, etc. mit eingeschlossen sind. Das heißt aber nicht das auf einer residential Fläche nicht auch mal ein Park, Parkplatz oder ähnliches liegen darf.

r-michael wrote:

Nun hatte ich mich in Deutschland und im benachbarten Ausland einmal umgeschaut um zu sehen wie dies überwiegend gehandhabt wird und stieß dabei auch auf einige Gemeinden im Raum Thüringen, in welchen ich die Erklärung für die doppelten Ortsnamen fand.
Dort hat man neben den Node ('place=*' + 'name=*') auch die Fläche der Gemeinde mit 'landuse=residential' + 'place=*' + 'name=*' versehen und so erscheint durch das doppelte "place+name" auch der Ortsname doppelt.

Der Ortsname hat imho wirklich nichts an landuse=residential verloren. Die Ursache für die doppelten Ortsnamen im Raum Thüringen sind aber meist der place-node und die vorhandene Grenze.

Gruß BBO

r-michael wrote:

O.k., ich weiß jetzt werden die "Multipolygon-Fetischisten" wieder aufschreien, aber wozu soll ich nun daraus Multipolygone erstellen; die Gemeindefläche ist doch im Prinzip nur eine virtuelle Fläche und kann somit auch den Layer-Tag verkraften.

Und was ist jetzt nun für dich "Gemeindefläche"? Der besiedelte Teil, oder das ganze Gebiet innerhalb der Gemeindegrenzen?

Für ersteres gibt es landuse=residential, für letzteres Grenzrelationen. In die Grenzrelation kannst du auch deine place-nodes einbauen. Dafür braucht es keine neue Flächenelemente. Und unterirdisch (layer=-1) sind die schon garnicht. Die Grenzrelation kann auch für PLZ und Adressuche von Vorteil sein.

gruß,
ajoessen

ajoessen wrote:

Und was ist jetzt nun für dich "Gemeindefläche"? Der besiedelte Teil, oder das ganze Gebiet innerhalb der Gemeindegrenzen?

Der besiedelte Teil, welcher alle innerörtlichen Flächen beinhaltet.

Für ersteres gibt es landuse=residential...

Ja und das ist der Denkfehler!
Du findest auch im kleinsten Dorf nicht 100% Wohngebiet, da gibt's immer noch andere Flächen.
Kleinstes Beispiel - dein Grundstück; dort gibst Wohnfläche, Garten, Garage, etc.
O.k., so detailiert taggt man normalerweise nicht, sollte aber auch nur ein Anschauungsbeispiel sein.

r-michael wrote:

Du findest auch im kleinsten Dorf nicht 100% Wohngebiet, da gibt's immer noch andere Flächen.
Kleinstes Beispiel - dein Grundstück; dort gibst Wohnfläche, Garten, Garage, etc.
O.k., so detailiert taggt man normalerweise nicht, sollte aber auch nur ein Anschauungsbeispiel sein.

Großer Denkfehler: Rasen, Garage und WOHNUNG sind Bestandteil eines WOHN-Gebietes. da kommt der Name her.
Zudem sind Garagen und Wohnungen in der Regel Gebäude, die irgendwo rumstehen.
Landuse (Land-Benutzung) beschreibt die Nutzung einer Fläche. Diese Fläche beinhaltet selbstverständlich die Objekte, die sich dort befinden. z.b Buildings und sogar Straßen, Wege.

wambacher wrote:

r-michael wrote:

Du findest auch im kleinsten Dorf nicht 100% Wohngebiet, da gibt's immer noch andere Flächen.
Kleinstes Beispiel - dein Grundstück; dort gibst Wohnfläche, Garten, Garage, etc.
O.k., so detailiert taggt man normalerweise nicht, sollte aber auch nur ein Anschauungsbeispiel sein.

Großer Denkfehler: Rasen, Garage und WOHNUNG sind Bestandteil eines WOHN-Gebietes. da kommt der Name her.
Zudem sind Garagen und Wohnungen in der Regel Gebäude, die irgendwo rumstehen.
Landuse (Land-Benutzung) beschreibt die Nutzung einer Fläche. Diese Fläche beinhaltet selbstverständlich die Objekte, die sich dort befinden. z.b Buildings und sogar Straßen, Wege.

Also ich verstehe das Anliegen schon. Irgendwo muss man einfach mal vereinfachen. Es gibt neben landuse=residential auch noch Werte wie meadow für Wiese, garages für Geragen, greenhouse_horticulture für Gewächshäuser, etc.
Daher finde ich es durchaus legitim in kleineren Orten und bei Ansiedlungen alles als landuse=residential zu taggen. Sollte dann später noch ein Industriegebiet dazu kommen oder ein village_green dann ist das doch wie in der ganzen OSM geschichte. Erstmal grob und dann immer feiner.

BBO wrote:

Der Ortsname hat imho wirklich nichts an landuse=residential verloren.

das sehe ich genauso, da man keinem Renderer sonst vorwerfen kann, hier zu entscheiden, ob eine Anzeige sinnvoll ist oder nicht (bei vielen Dingen wie der Benennung von Gewerbegebieten oder Landwirtschaftsbetrieben die durch ein landuse beschrieben werden, ist es ja durchaus sinnvoll, den Namen anzuzeigen). Ich halte es auch deshalb nicht für sinnvoll, da mit der Platzierung des Namens auf dem residential Material kein einheitliches Tagging geschaffen wird, da es bei einigen Dörfern und größeren Städten ohnehin utopisch ist, das ganze residential-Gebiet in einen Weg zu packen bzw. dies nur mit aufwändigem Multipolygoneinsatz möglich wäre.

Die Anzeige des Namens der boundary halte ich hingegen für schwer umgänglich, vielleicht sollte man hier einen Tag render:name=no einführen oder man bringt mapnik endlich mal bei, dass es vollkommen unnütz ist, die Informationen die mit boundary=administrative in Verbindung stehen, in hohen Zoomstufen zu rendern. So ist es nämlich auch möglich, den Namen 3 mal anzuzeigen: http://www.openstreetmap.org/?lat=51.39 … 4&layers=M (place+landuse+boundary)

monotar wrote:

BBO wrote:

Der Ortsname hat imho wirklich nichts an landuse=residential verloren.

das sehe ich genauso, da man keinem Renderer sonst vorwerfen kann, hier zu entscheiden, ob eine Anzeige sinnvoll ist oder nicht (bei vielen Dingen wie der Benennung von Gewerbegebieten oder Landwirtschaftsbetrieben die durch ein landuse beschrieben werden, ist es ja durchaus sinnvoll, den Namen anzuzeigen). Ich halte es auch deshalb nicht für sinnvoll, da mit der Platzierung des Namens auf dem residential Material kein einheitliches Tagging geschaffen wird, da es bei einigen Dörfern und größeren Städten ohnehin utopisch ist, das ganze residential-Gebiet in einen Weg zu packen bzw. dies nur mit aufwändigem Multipolygoneinsatz möglich wäre.
...

Das sehe ich völlig anders. Und ich vertrete die Meinung, daß das name-Tag bei landuse=residential bleiben muß.
In mit mkmap gerenderten Karten wird das name-tag von landuse=residential so ausgewertet, daß man am PC und im GPS-Gerät in den Karten mit Hilfe des Mauszeigers den Namen des Ortes durch Berühren der Fläche anzeigen lassen kann. Das ist sehr praktisch. Und daher ist nicht einzusehen, warum das name-tag aus residential verschwinden soll. Es kann doch wohl kein Problem sein, den Mapnik-Renderer darauf einzustellen, daß der Name von landuse=residential nicht zur Anzeige kommt. Das Tag wegzunehmen, und damit Renderern anderer Karten die damit verbundenen Vorteile kaputt zu machen, kann nicht die Lösung sein. Ich dachte, wir mappen nicht für Renderer! Das Entfernen des Name-Tags wäre ein Beispiel für "wir mappen für (!) Renderer" und zwar mal wieder vorrangig auf Mapnik focussiert. 🙁
Finde ich nicht in Ordnung.

Gruß
tippeltappel

@ tippeltappel
Die Anzeige von "wo bin ich" kann mittels Grenzen gelöst werden. Außerdem ist es oft nicht sinnvoll und/oder möglich eine Fläche die den ganzen Ort umschließt zu erstellen. Ein komplettes weglassen der Namen an residential-Flächen würde auch bedeuten das Wohngebietsnamen, die ich oft an die entsprechend große Fläche hänge, nichtmehr angezeigt würden.

Gruß BBO

eine Stadt besteht ja oft aus mehreren residential Flächen. Zum einen weil die Polygone sonst zu groß werden würden und zum anderen weil es auch trennende Industrie-, Gewerbe- oder sonstwas für Gebiete gibt. Ein name= halte ich daher auch für falsch. Ein is_in kann dagegen nicht schaden. Auf das Garmin Argument müsste man mit dem Standardspruch antworten: "wir mappen nur Gebäude für Renderer"....okay das war jetzt leicht abgewandelt

Hat zwar nichts mit den doppelten Ortsbezeichnungen zu tuen, aber

viw wrote:

...Sollte dann später noch ein Industriegebiet dazu kommen oder ein village_green d...

village_green ist nicht einfach eine Grünfläche.

key:landuse / village_greeen wrote:

An area of common land, usually grass, in the centre of a village (quintessentially English - defined separately from 'common land' under the Commons Registration Act 1965 and the Commons Act 2006).

Für Grünflächen in der Stadt sind landuse=grass bzw. meadow oder leisure=park vorgesehen. Wieso ein Merkmal für ein britisches Gesetz Einzug in OSM gefunden hat, weiss ich nicht. Der Beschreibung nach passt es aber nicht für eine Grünfläche auf dem Festland.

-trekki

tippeltappel wrote:

Ich dachte, wir mappen nicht für Renderer! Das Entfernen des Name-Tags wäre ein Beispiel für "wir mappen für (!) Renderer" und zwar mal wieder vorrangig auf Mapnik focussiert. 🙁
Finde ich nicht in Ordnung.

Eben, wir mappen nicht für die Renderer. Ein name-Tag stehen zu lassen, wo es nicht hingehört, damit mkmap es wie gewünscht auswertet. Soll das Programm eben lernen, das mit den Grenzrelationen zu machen. Außerdem kann Mapnik nicht einfach Namen an landuse Flächen einfach nicht darstellen, denn manchmal mögen sie Sinn machen, wenn eben ein Wohngebiet einen eigenen Namen (und zwar eben einen eigenen Namen nur für das tatsächliche Wohngebiet) hat und keine administrative Einheit ist. Aber eben nur dann.

tippeltappel wrote:

Das sehe ich völlig anders. Und ich vertrete die Meinung, daß das name-Tag bei landuse=residential bleiben muß.
In mit mkmap gerenderten Karten wird das name-tag von landuse=residential so ausgewertet, daß man am PC und im GPS-Gerät in den Karten mit Hilfe des Mauszeigers den Namen des Ortes durch Berühren der Fläche anzeigen lassen kann. Das ist sehr praktisch. Und daher ist nicht einzusehen, warum das name-tag aus residential verschwinden soll. Es kann doch wohl kein Problem sein, den Mapnik-Renderer darauf einzustellen, daß der Name von landuse=residential nicht zur Anzeige kommt. Das Tag wegzunehmen, und damit Renderern anderer Karten die damit verbundenen Vorteile kaputt zu machen, kann nicht die Lösung sein. Ich dachte, wir mappen nicht für Renderer! Das Entfernen des Name-Tags wäre ein Beispiel für "wir mappen für (!) Renderer" und zwar mal wieder vorrangig auf Mapnik focussiert. 🙁
Finde ich nicht in Ordnung.

Gruß
tippeltappel

Ich gehe mal davon aus, Du meinst das der place node mit allen seinen angehängten Tags im residential Gebiet angesiedelt sein sollte. (das ist für mich die Gemeindefläche) Wenn ja, dann +1 von mir.

Das residential Gebiet ist auf dem Dorf relativ einfach einzuzeichnen. Alles, wo Wohnhäuser sind incl. der Hausgärten, ist residential. Die großen Ställe und die Gewerbegebiete bleiben außen vor. In der Stadt ist es halt etwas zergliederter, weil da unterschiedliche Landuses sich abwechseln. Und an Landuse residential gehört denke ich kein Name-Tag. Der Name-Tag hat die unangenehme Eigenschaft immer angezeigt zu werden.

Die Intention, weswegen ich den Thread aufgemacht habe, war eventuell einen Kompromiss zwischen dem place node und der Boundary Relation zu finden und die ggf. zu vereinigen. (Die Boundary Relation ist für mich die Gemarkung)

Übrigens beschränkt sich das Phänomen, was ich angeführt habe, nicht nur auf Thüringen. Am Wochenende habe ich im Kreis Parchim gewildert. Da war das gleiche zu finden.

Gruß

Volker

BBO wrote:

@ tippeltappel
Die Anzeige von "wo bin ich" kann mittels Grenzen gelöst werden. Außerdem ist es oft nicht sinnvoll und/oder möglich eine Fläche die den ganzen Ort umschließt zu erstellen. Ein komplettes weglassen der Namen an residential-Flächen würde auch bedeuten das Wohngebietsnamen, die ich oft an die entsprechend große Fläche hänge, nichtmehr angezeigt würden.

Gruß BBO

Grenzen sind Linien. Willst Du die dann als Fläche rendern, damit beschriebene Funktion realisierbar wird? Mit dem Ergebnis, daß die vom Grenzpolygon überlagerten Flächen nicht mehr abrufbar sind? Realisiere Deinen Lösungsvorschlag doch mal in Form einer kleinen Garmin-Testkarte. Ich würde gerne sehen, wie das funktioniert.

SunCobalt wrote:

eine Stadt besteht ja oft aus mehreren residential Flächen. Zum einen weil die Polygone sonst zu groß werden würden und zum anderen weil es auch trennende Industrie-, Gewerbe- oder sonstwas für Gebiete gibt. Ein name= halte ich daher auch für falsch. Ein is_in kann dagegen nicht schaden. Auf das Garmin Argument müsste man mit dem Standardspruch antworten: "wir mappen nur Gebäude für Renderer"....okay das war jetzt leicht abgewandelt

Die Zergliederung der residential-Flächen ist kein Argument gegen das name-Tag. Wenn Mapnik aufhört, auf jedes residential-Polygon einen Namen zu setzen, "zieht" das Argument genauso wenig, wie die Doppelanzeige der Dorfnamen. Wenn man mit der Maus ein residential-Polygon berührt und daraufhin den Namen der Siedlung, des Dorfes oder oder .... angezeigt bekommt, verbessert das dagegen den Komfort der Karte.

Nur Gebäude für Renderer mappen? Was soll das denn jetzt heißen?
Was haben Gebäude mit den Residential-Polygonen zu tun?

Wie dem auch sei.
Mapnik muß lernen, daß landuse=residential mit einem anderen Schema auszuwerten ist, als die anderen landuse-Tags, dann ist das Problem gelöst.

Gruß
tippeltappel

errt wrote:

tippeltappel wrote:

Ich dachte, wir mappen nicht für Renderer! Das Entfernen des Name-Tags wäre ein Beispiel für "wir mappen für (!) Renderer" und zwar mal wieder vorrangig auf Mapnik focussiert. 🙁
Finde ich nicht in Ordnung.

Eben, wir mappen nicht für die Renderer. Ein name-Tag stehen zu lassen, wo es nicht hingehört, damit mkmap es wie gewünscht auswertet. Soll das Programm eben lernen, das mit den Grenzrelationen zu machen. Außerdem kann Mapnik nicht einfach Namen an landuse Flächen einfach nicht darstellen, denn manchmal mögen sie Sinn machen, wenn eben ein Wohngebiet einen eigenen Namen (und zwar eben einen eigenen Namen nur für das tatsächliche Wohngebiet) hat und keine administrative Einheit ist. Aber eben nur dann.

Nein.
Wenn im Zentrum eines Ortes ein Node gesetzt werden soll, damit sicher gestellt ist, daß der Name dort und nicht in der geometrischen Mitte des Polygons angezeigt wird, dann gilt das auch für das von Dir genannte Beispiel. Setz einen Node in das Wohngebiet, damit der Name als Schriftzug auf der Karte erscheint. Dann braucht Mapnik den Namen des residential-Polygons nicht als Overlay zu rendern. Für Anwendungen, die in der Lage sind dieses Feature sinnvoll zu nutzen, muß das name-Tag am residential-Polygon erhalten bleiben.

tippeltappel wrote:

Grenzen sind Linien. Willst Du die dann als Fläche rendern, damit beschriebene Funktion realisierbar wird? Mit dem Ergebnis, daß die vom Grenzpolygon überlagerten Flächen nicht mehr abrufbar sind? Realisiere Deinen Lösungsvorschlag doch mal in Form einer kleinen Garmin-Testkarte. Ich würde gerne sehen, wie das funktioniert.

Ich will da garnix rendern. Mit einer Garmin-Karte geht das vlt. nicht, das ist aber nicht unser Problem. Wenn wir unser Verhalten daran anpassen ist das taggen für den renderer.

tippeltappel wrote:

Die Zergliederung der residential-Flächen ist kein Argument gegen das name-Tag. Wenn Mapnik aufhört, auf jedes residential-Polygon einen Namen zu setzen, "zieht" das Argument genauso wenig, wie die Doppelanzeige der Dorfnamen. Wenn man mit der Maus ein residential-Polygon berührt und daraufhin den Namen der Siedlung, des Dorfes oder oder .... angezeigt bekommt, verbessert das dagegen den Komfort der Karte.

Von mir aus kann eine Karte anzeigen residential-Fläche xy liegt in Ort zx. Dazu soll sie prüfen in welcher Grenzrelation die Fläche liegt und fertig.
Wenn du an jede residential-Teilfläche den Ortsnamen hängen willst, wohin dann der Wohngebietsname? Wozu x-fach den Name des Ortes erfassen?

Gruß BBO

BBO wrote:

Von mir aus kann eine Karte anzeigen residential-Fläche xy liegt in Ort zx. Dazu soll sie prüfen in welcher Grenzrelation die Fläche liegt und fertig.

genau so sollte es sein und so macht es auch OSM Nominatim. Was die Eingliederung von kleineren OT betrifft, ist es lediglich der User, der für Dörfer unterhalb der Gemeindeebene noch keine Grenzrelationen angelegt hat, dann würden auch diese Abfragen tadellos funktionieren. Ich habe schon einen Test hierzu gemacht, allerdings bin ich ob der bescheidenen Darstellung noch in meinem Elan gebremst (und auch, weil es bisher nirgends groß gemacht wurde). Die Zuordnung von Straßen im Grenzbereich von 2 Orten zu einer bestimmten Ortschaft funktioniert aber dann besser (auch wenn das place-Tag noch einen Bug in der Zuordnung erzeugt, aber ich denke das wird irgendwann noch behoben). An Grenzrelationen führt da kein Weg dran vorbei, andere Schemata wie landuse benennen wäre nur Pfusch der nicht auf das bisherige Prinzip der hierarchischen Verwaltungsgrenzen aufsetzt.

@tippeltappel: Von Namen, die in der Ortsmitte gerendert werden sollen, habe ich doch garnichts gesagt. Ich beziehe mich rein auf Ortsteile und Siedlungen, die zwar einen eigenen Namen haben aber keine administrative Einheit darstellen. Ein node dort wäre mappen für den Renderer, der name-Tag am landuse-Polygon dagegen drückt das korrekte aus: Dieses Wohngebiet hat diesen Namen. Und in dem Fall finde ich es durchaus korrekt, wenn Mapnik den Namen dann auch rendert. Natürlich könnte er es lassen, aber trotzdem bin ich der Meinung, dass deine Variante ein taggen für den Renderer, in deinem Fall eben mkmap ist. Warum sollte mkmap nicht die Grenzrelation genauso auswerten wie ein landuse=residential-Polygon aktuell? Wenn die landuse-Flächen dort nichtmehr anklickbar sind, überlagern sie dann auch nicht die aus der Grenzrelation gebildete Ortsfläche. Hat außerdem den Vorteil, dass auch nicht-residential Flächen mit korrektem Ortsnamen angezeigt werden. Andere Alternative wäre, wie BBO vorschlägt, an der Grenzrelation festzustellen, in welchem Ort eine landuse-Fläche liegt. Dann kann man immernoch in seinem Programm diese Fläche dann mit dem Ortsnamen ergänzen. Aber in OSM selbst passt es meiner Meinung nach nicht. Dritte Alternative wäre, dass man das landuse=residential mit einem is_in ausstattet und dieses statt dem Namen (bzw. zusätzlich dazu) auswertet. Wobei ich da denn Vorteil zu Alternative zwei nicht sehe.