Eine kleine Anmerkung, wenn man international unterwegs ist:
Nicht überall wird für Gemeinde als kleinste Verwaltungseinheit admin_level=8 genommen. Thailand hat kein 8 und 9 außer in der Hauptstadt.
Die Interpretation von municipality ist auch ziemlich verschieden.
Siehe die langen Länderlisten in https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative (englisch).
mein Eindruck ist anders, es sieht so aus als wären nur 350 von knapp 7000 place=municipality in Deutschland
http://taginfo.geofabrik.de/europe/germany/search?q=place%3Dmunicipality
29 in Österreich und 12 in der Schweiz.
4120 in Europa.
1477 in Ukraine
245 in Italien
300 in Spanien
15 in Frankreich
745 in Rumänien
49 Bulgarien
181 Nordamerika
155 Zentralamerika
916 Südamerika
1036 Asien (plus 1119x place:PH=municipality)
465 Australien Ozeanien
es ist also ziemlich weltweit verteilt.
aus Interesse: wie kommst du auf diese Länderliste? Ich habe z.b für Österreich mittels Overpass-Turbo nachgeschaut und erhalte da nur 4 Nodes
Na, wenn es aus Norwegen heißt “Rendering municipalities as nodes would not make any sense.”
dann ist das für mich sehr beruhigend, denn in meinem Konzept ist municipality schließlich der off-Schalter des Gemeinde-labels im Sinne von
“willst Du diesen name wirklich rendern?” (Söhrewald)
gegenüber town/village als on-Schalter “name bitte Darstellen!” (Baunatal)
Eine großflächige/internationale Beschriftung der admin_level=8 Grenzrelationen (in D die kreisangehörigen Gemeinden) ist imho primär auf Basis deren Daten sinnvoll - und schon lange möglich.
Was die municipality-Zählerei bringen soll, weiß ich nicht, aber dabei bitte beachten,
ein place=municipality als Zusatztag an dieser deutschen al=8 Gemeinde-Grenzrelation
https://www.openstreetmap.org/relation/452210
ist genauso sinnfrei wie ein place=city an dieser/diesen rumänischen al=8
https://forum.openstreetmap.org/viewtopic.php?pid=851745#p851745
Daher steht in meinem Konzept auch “… sollte nur als Node (Punkt) verwendet werden.”
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch2&oldid=2244215
ich habe auch ways und relationen gezählt, bzw. die gezählten Daten von der Geofabrik abgefragt, Link stand oben, analog Österreich:
http://taginfo.geofabrik.de/europe/austria/search?q=place%3Dmunicipality
Komisch, Overpass-Turbo liefert da für Relationen in Österreich überhaupt nichts. Und auf der taginfo-Seite kann ich auch keine Details finden welche es davon konkret geben sollte. Oder mache ich etwas falsch?
Mir ging es bei meinem Verweis auf die Bedeutung des Begriffes weniger darum, wie dieser Begriff in OSM angewendet wird, sondern was er im real life beinhaltet. Da ist auch nicht Wikipedia die sinnstiftende Autorität, sondern der Gebrauch im englischen Sprachraum. Dort beschränkt sich der Begriff eben nicht nur auf die hier debattierte kleinstmögliche kommunale Selbstverwaltungseinheit, die wir landläufig als “Gemeinde” kennen (und die admin level 8 entspricht), sondern bezeichnet die Selbstverwaltungseinheit per se. Nehmen wir als Beispiel Kanada. Da bilden z.b. die beiden Weiler Crozier und Roddick mit zusammen rund 800 Einwohnern die stolze “Municipality of Alberton”, aber es gibt z.B. auch eine “Municipality of Toronto” … u.s.w.
M.E. spricht nichts dagegen, einen Tag place=municipality als label in jede Gemeindegrenzen-Relation zu setzen. Wenn ich in der Standardkarte dann nach dem Gemeindenamen suche, bekomme ich genau da, wo der place-node platziert wurde, den Marker für mein Suchergebnis angezeigt (z.B. Söhrewald) - den Gemeindenamen jedoch nicht, da dieser nicht gerendert wird. Habe ich keinen place-node als label, bekomme ich den Marker für das Suchergebnis auch angezeigt, allerdings irgendwo mittig im Gemeindegebiet (z.B. Erftstadt).
Wenn ich so für alle Gemeinden verfahre (wie es JoCassel vorschlägt), also auch für solche, wo 1 village oder 1 town = 1 Gemeinde ist, dann muss ich natürlich damit rechnen, dass irgend jemand auf die Idee kommt, dass auch Hamburg eine municipality ist und den label dann ebenfalls haben sollte … was gemäß Definition auch stimmen würde. Sollte also theroetisch nichts schaden.
Dann habe ich aber immer noch nicht das Problem gelöst, dass für die administrativ aus mehreren Orten zusammengesetzten Gemeinden wie Erftstadt oder Söhrewald oder Wildeck zwar als Suchergebnis ein Marker auf der Standardkarte angezeigt wird, aber der Name dieser Gemeinde unauffindbar bleibt.
Und wenn ich für die Lösung dieses Problems den place=municipality label-node hernehmen will, dann muss ich von vorneherein eine Sonderregel definieren, dass das nicht für alle “municipalities” gelten soll, sondern nur für die aus mehreren Orten zusammengesetzten. Ist das wirklich die beste Lösung?
Oder nicht doch einfacher diesen speziellen Gemeinden ganz unabhängig von den label-nodes ein place=village node geben (Beispiel Rheinhausen BW) bzw. ein place=town node (Beispiel Baunatal) um das Problem der ungerenderten Namen zu lösen …??.. dafür bräuchte man weder eine Sonderregel noch zusätzliche Tags, alles vorhanden … und man müsste auch nicht bis zum Sankt Nimmerleinstag warten, bis eine Entscheidung herbeigeführt wurde, place=municipality unter bestimmten Bedingungen zu rendern.
@ JoCassel
Um Missverständnisse zu vermeiden … meine Skepsis gegenüber den Vorschlag, place=municipality zu rendern richtet sich keineswegs gegen Deinen Vorschlag zum strukturierten Taggen von Gemeinden. Du hast das ja hier in der Gegend schon vielfach umgesetzt, und wenn man irgendwo auf eine Gemeinde stößt, wo die Daten zur Relation und die nodes zu admin_center und label nachvollziehbar angelegt sind, stammt das im Normalfall von Dir, das ist schon richtig saubere Arbeit, egal ob man jetzt einen label-node goutiert oder nicht. Das muss auch mal gesagt werden. 
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
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 … 
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”).