place=town für zusammengelegte Städte??

Zähle heute per overpass in Österreich
5 Nodes mit place=municipality - davon sind leider nur 3 per label in die admin_level=8 Grenzrelation eingebunden
(in Hessen aktuell 111 Nodes mit place=municipality, der Großteil ist nicht von mir)
Grenzrelationen mit place=municipality kann ich in A nicht finden - das ist auch gut so.

Auffällig ist, dass aber 13 admin_level=8 Gemeinden in A behaupten, sie hätten ein label, z.B.
https://www.openstreetmap.org/relation/947891
halte das für einen Zuordnungsfehler, der Siedlungsort “Götzendorf an der Leitha” ist doch wohl role=admin_centre der Gemeinderelation.

Abfrage zu role=label in al=8 Grenzrelationen
https://overpass-turbo.eu/s/1f0m


Du willst nicht wirklich 11000 Fake-place-Nodes in D (wieder neu) anlegen?


Nix neues in meinem Entwurf für die DE-Dokumentation:

https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=2244215

Danke, dann kann man offenbar den geposteten Zahlen von http://taginfo.geofabrik.de nicht wirklich vertrauen.

Lustig ist der Fall jener Gemeinde die seit gestern in Österreich dazu kam: Es geht um die Gemeinde “Rauris” https://www.openstreetmap.org/relation/1022928 die - wie meist bei Gemeinden - einen gleichlautetende Ort samt dazugehörigem place-node hat: https://www.openstreetmap.org/node/240056984
Da dieser Node nicht wirklich mittig im Gemeindegebiet liegt, wurde gestern ein weiterer Node erzeugt zwecks mittigem Label: https://www.openstreetmap.org/node/9411278461
Beide Nodes sind in die Gemeinde-Relation eingebunden. Es stellt sich die Frage ob solche Label-Nodes überhaupt sinnvoll sind - SOFERN es bereits einen gleichlautenden place-node der Gemeinde gibt. Und zweitens ob dieser label-node “place=municipality” getaggt sein soll? Könnte das nicht “doppelt gemoppelt” mit dem Node des Hauptortes “Rauris” der Gemeinde sein?

Es gibt in D (und wohl auch in A-CH)
A Gemeinden mit Kunstnamen (“Söhrewald”)
B Gemeinden deren Namen sich aus einem namensgebenden Hauptort ableitet (der dann idR auch Verwaltungssitz=admin_centre ist)

Aus Sicht der Gemeinderelation (und meinem Entwurf für die DE-Dokumentation) ist das aber völlig egal.

Den “Rauris”-Fall kenne ich bei mir z.B. bei “Calden”
https://www.openstreetmap.org/relation/455491
und sehe da datentechnisch-grundsätzlich keinerlei Probleme.

Meine einzige Kritik am neuen place=municipality-Node: die wikimedia-Tags zur Gemeinde gehören einzig und nur an die Grenzrelation der Gemeinde (“Ein Node mit place=municipality ist daher immer nur ein Zusatzelement dieser Grenzrelation”).
vgl. mein “Calden”-Gemeinde Node-Tagging
https://www.openstreetmap.org/node/6184200447

Sollte ich noch “Eine Dopplung der wikimedia-Tags (wikidata, wikipedia, wikimedia_commons) am label-Node ist unerwünscht.” aufnehmen?

C: Gemeinden, deren Name sich aus beiden Orten zusammensetzt… Gemeinde Byhleguhre-Byhlen Es ist eine amtsangehörige Gemeinde, daher ist selbst der Admin-Centre-Node schwierig, da es keine vollständige Gemeindeverwaltung gibt, sondern nur einen Bürgermeister mit Gemeinderat. Hauptverwaltungsaufgaben werden über das Amt erledigt.

Sven

Dann hatte ich dich vorher doch nicht richtig gelesen. Für dich ist also die korrekt-systematische Lösung über das Rendern der Namen an den Grenzrelationen unverhandelbar, richtig?

Ich stimme dir zu, dass die Antwort aus Norwegen es unwahrscheinlicher macht, dass der Vorschlag, municipality zu rendern, Zustimmung erfahren wird.

Mit dem Rendern von Namen an Grenzrelationen habe ich mich nun noch gar nicht beschäftigt und wäre insoweit erstmal wieder raus. Andererseits wurde dazu doch der damals zitierte Github Issue erfolglos geschlossen (Link folgt), oder nicht?

Insofern habe ich, bei allem Respekt vor deiner Kenntnis der Materie, doch wieder das Gefühl, dass wir uns im Kreis drehen und bin zunehmend geneigt, dem seinerzeit geäußerten von MapHe_Ro geäußerten Gedanken zuzustimmen, dass man sich mittelfristig mit der unserem Konsens nach falschen Verwendung von place=town abfinden könnte/müsste. Vielleicht mit einem Subtag für place=town einführen wie town=rural / town=nocentre / town=administrative o.ä.?

Ja, sorry C gibt es natürlich auch, und auch da kann/könnte ganz entspannt (zusätzlich zu admin_centre) ein place=municipality label-Node “ins grüne” gesetzt werden, und nix geht kaputt.

Gruß
Jo

Sicher, es geht nichts kaputt, ich halte aber von einem label-Node zu 100% garnichts! Für mich ist das ein Taggen für den Renderer ersten Grades… Das Rendering-Programm muß anhand von entsprechenden Positionierungregeln der Beschriftung selbständig die ideale Position finden. Alle einschlägigen, normalen Gis-Programme können das auch.

Sven

Doofe Frage, was machst du bei Verbandsgemeinden wie dieser dann?

Danke für das Beispiel… Das ist für mich vor allem in dieser Zoomstufe das klassische Beispiel, daß solch ein Place-Node völlig sinnfrei ist. Mit einem Place-Node wird der Name in der Regel immer an der falschen Stelle sein. In deinem Beispiel muß der Name nur innerhalb des Polygon erscheinen… ob in der nördlichen, oder südlichen Teilfläche ist hier völlig egal!! Es ist erst dann irgendwann abhängig von der Zoomstufe… bin ich in der nördlichen Teilfläche: Name hinreichend etwa in der Mitte des sichtbaren Grenzausschnitts innerhalb des Grenz-Polygons… Stelle ich die südliche Teilfläche dar, dann ebenso. Da bei OSM- Tiles gerendert werden, sollte das durchaus nicht unmöglich sein.

Für mich in meiner hauptberuflichen GIS-Arbeit ist sowas das tägliche Brot… Manuelle Positionierungen von Beschriftungen mache ich nur, wenn auf Grund einer darzustellenden besonderen Beschriftungen diese Regelsammlungen an ihre Grenzen stoßen, bzw. wenn ich ob einer gewissen Kontinuität auf eine bestimmte Darstellungsweise nicht verzichten möchte, sie sich über Jahre etabliert hat. Alles andere kostet viel zu viel Zeit und ist ob der Möglichkeiten zu 98% unnötig.

Rendering-Regeln…

Es gibt z.B. Regeln, mit denen man erzwingen kann, daß ein Beschriftung nur innerhalb eines Polygon gerendert wird… Das ist sogar mit die wichtigste Regel! Weitere Regeln: bei Gemeindenamen wie “Märkische Heide” wird automatisch ein Zeilenumbruch zwischen den beiden Worten erzwungen, um der Regel “Beschriftung nur innerhalb des Polygon” zu entsprechen… Passt eine Beschriftung nicht ins Polygon, fehlt sie… oder es wird eine Skalierung der Schriftart angewendet… oder erst bei einer höheren Zoomstufe dargestellt… Die erweiterten Rendering-Regeln bei ArcGis gehen über die Maplex-Engine… bei QGis sind die Regeln ähnlich.

Solche Regeln sind so sehr vielfältig… als daß man da sich zunächst etwas mit den wichtigsten Regeln berschäftigen muß… Das ist aber dann eben so… Ich kann mir beim besten Willen nicht vorstellen, daß die Renderingregeln der OSM-Hauptkarte dazu nicht in der Lage wären…

Sven

Was soll diese polemische (das ist die höfliche Formulierung) Frage? Es geht hier keineswegs darum, die gesammtelten 11.000 DE-Gemeinden mit “FakePlaceNodes” zu versehen, sondern ausschließlich die, bei denen der Gemeindename nicht durch den Namen eines Ortes ohnehin repräsentiert wird, der Bestandteil der Gemeinde ist, also z.B. Söhrewald. Das dürften vermutlich schon mal weniger als die Hälfte sein. Und bei vielen davon (Beispiel Rheinhausen oder Seeheim-Jugenheim) wurde ohnehin bereits ohne lange Diskussion die pragmatische Lösung gewählt, den Namen über place=village/town in der Standardkarte sichtbar zu machen.

Da werden also so viele nicht mehr übrig bleiben, die noch eines “FakePlaceNodes” bedürfen. Und wenn ich das richtig verstanden habe, geht es hier in diesem Topic nicht darum, allen Gemeinden Deutschlands ein place=municipality als label für die Grenzrelation zu verpassen, sondern den bisher “namenlosen” Gemeinden und Städten wie Söhrewald oder Erftstadt dazu zu verhelfen, ihre ganz offiziellen Ortsnamen auf der Standardkarte darzustellen. Und ob der place=municipality label-node dafür der richtige Ansatz ist, habe ich kritisch hinterfragt, mehr nicht.

Kommt mir irgendwie bekannt vor … hatte ich in diesem Topic wohl auch schon mal … :roll_eyes:

Tippfehler korrigiert

wieso? Wikipedia unterscheidet in der Regel nicht bzw. selten zwischen place und boundary, es sind Artikel die mehrere Konzepte abdecken.

Der Artikelausbau ist unterschiedlich und im Fluss, aber es gibt viele Gemeindeartikel in denen die Ortsteile mit abgehandelt werden.
Dann ist es natürlich völlig ok, wenn in OSM diese village/town-Nodes (ohne eigene al=9 Grenzrelation) den identischen (gedoppelten) wikipedia-Tag bzw. value haben wie die al=8 Gemeinde-Grenzrelation - auch ein per role=admin_centre eingebundene Hauptort/Verwaltungssitz.

Bei einer datentechnisch sauber erfassten al=8 Gemeinde-Grenzrelation ist eine derartige Dopplung am role=label Node aber systematisch immer Dopplungs-Unfug (“unerwünscht”).

Liebe Leute, vielen Dank für eure ausführlichen Antworten auf meine Anfangsfrage “place=town für zusammengelegte Städte?”.

Die 4 Seiten Diskussion (+ die über mehrere Jahre vorausgehenden Diskussionen) beantworten die Frage für mich in der Summe wie folgt: “Ja, leider, weil es nicht absehbar ist, dass das legitime Ziel, Verbundgemeinden wie Erfstadt etc. in Carto gerendert zu sehen, in einem überschaubaren Zeitraum anders erreicht werden kann.”

Sag es, wie es ist, bro …!!.. das ist auch mein Fazit an dieser Stelle … aber gut, dass wir mal drüber gesprochen haben :smiley:

man kann natürlich weiterwursteln und dann wird sich das nie ändern, oder man einigt sich auf ein alternatives tagging mit dem es unwahrscheinlicher wird, dass man mitten in den Wald geschickt wird wenn man eine solche “Stadt” anfahren will. Das wird zwar nicht sofort von Carto gerendert werden, aber wenn man ein etabliertes Schema hat, für etwas relativ seltenes wie solche Städte, dann werden die Entwickler nach meiner Einschätzung auch nicht auf 5000 oder 2000 gemappten Objekten bestehen. Wenn es natürlich nur 15 sind, wird es eher nichts werden. Grundsätzlich wollen die Carto-Entwickler Stadtnamen sicher auch sehen.

Seufz … Du hast natürlich wie oftmals (aber nicht immer!) Recht … es wäre schön, wenn es für das Problem der fehlenden Ortsbezeichnungen eine einfache, pragmatische Lösung gäbe. Die ist hier aber m.E. leider nicht in Sicht. Die Diskussion dreht sich, wie 38446 leicht entnervt aber völlig richtig festgestellt hat, im Kreis und in vielen Beiträgen geht es gar nicht um eine pragmatische Lösung für das angesprochene Problem, sondern darum, eine bestimmte Tagging-Ideologie zu verteidigen oder Nebenschauplätze zu bearbeiten.

Dass das hier angesprochene Problem einer Lösung bedarf, erkennt man schon daran, dass es in den letzten Jahren diverse Male diskutiert wurde. Ohne lange zu suchen, habe ich dazu diese zusätzlichen Topics gefunden:

https://forum.openstreetmap.org/viewtopic.php?id=73638
https://forum.openstreetmap.org/viewtopic.php?id=64942
https://forum.openstreetmap.org/viewtopic.php?id=57723

Es gibt sicher noch mehr davon, sowie zusätzliche Issues auf Github zu dem Thema (was mir nichts sagt).

Dabei ist das Problem doch gar nicht besonders kompliziert: Es gibt Gemeinden, bei denen die Anzahl der Ortsnamen, die gerendert werden und von jedem Navi gefunden werden sollten gleich ist der Anzahl der zur Gemeinde gehörenden Orte +1.

Man braucht also lediglich einen zusätzlichen Tag für den überzähligen Namen, der eben keine gewachsene Ortschaft im Sinne von OSM darstellt, aber trotzdem ein real existierender Ort ist. Es entspricht im Prinzip einer City, die aus ‘n’ gewachsenen Suburbs besteht und trotzdem einen zusätzlichen eigenen Namen führt. Vorschläge für dieses zusätzliche Tag gibt es bereits mehrere:

  1. place=municipality

Problematisch, weil

  1. Municipality eine Verwaltungseinheit bezeichnet, keine physische Ortschaft und daher zu Recht nicht gerendert wird.
  2. Municipality sich nicht auf den Problemfall beschränken lässt, sondern für alle Gemeinden/Städte Gültigkeit hat.

Es müsste also nicht nur erreicht werden, einen bisher verschmähten Tag zu rendern, sondern das Rendern durch ein entsprechendes Regelwerk auf die Problemgemeinden zu beschränken. Das ist alles andere als eine KISS-Lösung.

  1. place=town/village

Ist gängige Praxis und lässt sich einfach und ohne zusätzliche Regeln anwenden. Das Problem dabei ist eher ideologischer Natur, weil es der OSM-Definition der Begriffe villag/town nicht vollumfänglich entspricht. Ich persönlich halte das trotzdem für eine akzeptable Lösung, vor allem wenn so vorgegangen wird wie hier:

https://www.openstreetmap.org/node/8862687987#map=14/48.9691/9.1831

und der place=village Tag mit einer note “Dieser node dient nur zur Markierung der Gemeinde Ingersheim …” versehen und sinnvoll im Gemeindegebiet platziert wird.

  1. place=xxx

Wenn man 1. und 2. nicht goutiert, könnte alternativ für die betroffenen Gemeinden ein ganz eigener und eindeutig darauf bezogener place-tag erfunden werden. Aber mal ganz davon abgesehen, dass es nicht einfach sein wird, einen wirklich eindeutigen Begriff zu finden, zweifele ich auch daran, dass dies die beste Lösung darstellt.

Wenn eine Einigung und entsprechende Dokumentation in der deutschen Wiki nicht möglich ist, bleibt es vermutlich dabei, dass jeder nach eigenem Gusto taggt … JoCassel nach 1., viele andere nach 2., und noch andere machen einfach die einzelnen Ortschaften zu suburbs oder hängen einen name-tag an die landuse=residential area usw. usw. … weiterwursteln, wie Du es so schön genannt hast.

1 Like

Moin Moin Freunde,

könnt ihr mal einen Blick auf folgenden Node werden:

Node 129992313

Hier hat man eine Straßenkreuzung auf dem freien Feld, fernab der nächstgelegenen Siedlung, mit “place=city” getaggt. Doch halt! Dieser Key ist doch explizit für Stadtzentren gedacht, nicht wahr?

In unserem deutschsprachigen Wiki ist unter DE:Tag:place=city folgendes zu lesen:

Wie mappen?
Setze einen Knoten Knoten oder Punkt in das Zentrum der Großstadt wie z.B. den Marktplatz, das Rathaus, eine Hauptkirche und füge place=city hinzu.

Was sagt die Community hierzu?

LG euer Olaf

Wo würdest du den place-Node für Salzgitter platzieren? Die Stadt ist halt ziemlich verteilt.

Das en-Wiki schlägt auch große zentrale Kreuzungen als Ort für den place-Node vor:

Place a node at the center of the city, like the central square, a central administrative or religious building or a central road junction and tag it place=city.

Es würde sich bei einer Großstadt doch bestimmt ein dafür besser geeigneter Ort finden als eine Autobahn-Kreisstraßen-Kreuzung auf einer freien Wiese. Bei kleineren Städten ist es Konsens, diese nicht als place=town zu taggen, wenn die Stadt aus mehreren Dörfern zusammengeklöppelt ist und sich kein klar definiertes Stadtzentrum ausmachen lässt. Beispiele Stutensee, Kraichtal, Filderstadt, Weinstadt, Remseck am Neckar etc.

Stattdessen gibt es place=municipality, welches aber nicht von Mapnik gerendert wird.

Ich weiß nicht, ob die hier große us-amerikanische Siedlungen zum Vorbild haben, also Großstädte ohne historischen Stadtkern, die quasi nur aus Kreuzungen bestehen, aber selbst das o.g. A39/K30-Kreuz auf dem Acker entspricht doch nicht im entferntesten der Definition einer großen, innerstädtisch zentralen Kreuzung, die für so ein tagging prädestiniert ist, oder irre ich mich?

LG Olaf

Ach so, jetzt verstehe ich.

Wäre es ok das Thema mit diesem hier zusammenzuführen, wo Salzgitter auch schon erwähnt wurde?

1 Like