place=municipality bei Sammelgemeinden?

seichter wrote:

Bei den places sieht es aber nicht so gut aus.
...
Ob die place-Informationen bei diesen Gebilden an Knoten oder an Umrissen hängen sollte, sei mal außen vor, ich will die place-Knoten-Befürworter nicht bekehren.

Am liebsten würde ich die Place-Nodes und auch den place=*-Tag an Grenzen verschwinden lassen, da alle Informationen an die Administrativen Grenzen (auch 9 oder höher) passen sollten, sofern diese Grenzen vorhanden sind. Nur was wirklich ein Place (Platz/Stelle !) ist, sollte auch einen Place-Node behalten dürfen.

Meine "Missing Residentials"-Karte soll nicht dazu dienen, "fehlende" Place-Nodes nachzutragen sondern ganz im Gegenteil dort Residentials zu erfassen, wo Residentials oder auch Administrative Grenzen > 8 fehlen. Sonst hätte ich die Karte wohl eher "Missing Places"-Karte genannt 😉

Gruss
walter

Ich will keinen place-node ab hamlet setzen und befürworte das auch nicht.

Ich hätte mit diesem Vorschlag nur gern etwas mehr Konsistenz in den existierenden place-Tags an nodes (so sie denn vorhanden sind).
Löschen mit Umhängen der Information an Grenze (mit Hierarchieordnung) kommt für mich nur bei breitem Konsens in Frage.
Also: municipality an Gemeinden, village an Dörfer.
Bei Städten mit eingemeindeten Dörfern: town/city an Kernstadt, village an Dörfer (getrennt außerhalb), suburb an Stadtteile.

seichter wrote:

Ich will keinen place-node ab hamlet setzen und befürworte das auch nicht.

Ich hätte mit diesem Vorschlag nur gern etwas mehr Konsistenz in den existierenden place-Tags an nodes (so sie denn vorhanden sind).
Löschen mit Umhängen der Information an Grenze (mit Hierarchieordnung) kommt für mich nur bei breitem Konsens in Frage.
Also: municipality an Gemeinden, village an Dörfer.
Bei Städten mit eingemeindeten Dörfern: town/city an Kernstadt, village an Dörfer (getrennt außerhalb), suburb an Stadtteile.

+1
Und einen für den breiten Konsens zum Umhängen hast du auch.

seichter wrote:

Ich will keinen place-node ab hamlet setzen und befürworte das auch nicht.

Kannst du das erläutern?

Ich bin einer (freundlichen) Diskussion zu place=municipality auf Nordstrand:
Wikipedia: https://de.wikipedia.org/wiki/Nordstrand_(Gemeinde)
Overpass: http://overpass-turbo.eu/s/iBl
Diskussion: http://www.openstreetmap.org/changeset/42165127

Momentan ist Nordstrand als place=village im Nirgendwo getaggt da es keinen Wohnplatz gibt der so heißt. Die gesamte Gemeinde besteht aus Ortsteilen (welche auch im offiziellen Wohnplatzverzeichnis sind) welche meist voneinander getrennt sind. Die Ortsteile sind als place=neighbourhood getaggt (dazu mache ich einen separaten Thread auf)

Ich würde für die Gemeinde Nordstrand gern "place=municipality" verwenden, aber die Definition spricht zur Zeit dagegen:

https://wiki.openstreetmap.org/wiki/DE:Key:place wrote:

collection of arbitrary hamlets, villages and towns may form an administrative unit; sometimes members of a unit reform or join with another municipality as a result of political process.

-> Nordstrand als Gemeinde war nie eine eine Sammlung "beliebiger Weiler und Dörfer" und es gab auch keinen politischen Prozess der Zusammenlegung.

Sollte place=village weiterhin "hart" nur Wohnplätze kennzeichnen?

Wenn ja:
a) place=municipality als eine Art Sammelbecken nutzen für große und kleine Orte? (klein: Kromsdorf, Nordstrand; groß: Filderstadt, Leinfelden-Echterdingen)
b) Neues Tagging? Z.B. place=village_municipality, town_municipality, ...
c) Place=municipality sein lassen und mehr mit Grenzrelationen arbeiten - ala "alle bebauten Gebiete innerhalb der Grenze sehen sich als Gemeinde Nordstrand (vom Typ Dorf)".

c) hat für mich seinen Charme.

seichter wrote:

Ich will keinen place-node ab hamlet setzen und befürworte das auch nicht.

Ganz ohne place=* wird es aber nicht gehen. So gibt es bei uns einige Ortsteile (admin-level=9) einer Großgemeinde, die sich aus mehreren einzelnen Orten/Dörfern zusammensetzen.

So gibt es z.B. den Ortsteil "Nanz-Willershausen", der zur Großgemeinde Lohra gehört und sich aus den Dörfern Willershausen und Nanzhausen, sowie dem Einzelgehöft Wüsteburg zusammensetzt:

https://de.wikipedia.org/wiki/Nanz-Willershausen
http://www.openstreetmap.org/#map=15/50.7523/8.6392

Ähnlich verhält es sich mit dem Ortsteil Beltershausen-Frauenberg in der Großgemeinde Ebsdorfergrund. Hierzu gehören die Dörfer Beltershausen, Frauenberg und das Einzelgehöft Hof Capelle:

https://de.wikipedia.org/wiki/Beltersha … rfergrund)
https://de.wikipedia.org/wiki/Beltershausen-Frauenberg
https://de.wikipedia.org/wiki/Hof_Capelle

http://www.openstreetmap.org/#map=15/50.7627/8.7982

Es gibt zwar für die Ortsteile entsprechende Gemarkungsgrenzen, die z.T. noch eingetragen werden müssen (diese würden ja dann mit admin-level=9 erfasst werden), für die "Sub-Ortsteile" existieren diese Gemarkungsgrenzen jedoch nicht (diese würden ja dann eigentlich mit admin-level=10 erfasst werden). Da jedoch diese Sub-Ortsteile eigenständige Ortschaften sind, die auch so entsprechend bekannt sind, müssten diese nach wie vor mit place=* erfasst werden.

Ich bin mir sicher, dass es ähnliche Konstellationen auch noch in anderen Regionen gibt.

VG,
Thorsten

Jojo4u wrote:

seichter wrote:

Ich will keinen place-node ab hamlet setzen und befürworte das auch nicht.

Kannst du das erläutern?

place-nodes für Gemeinde/Städte sind ein Relikt aus den Anfangszeiten von OSM, damit der Name wenigstens auf der Karte auftauchte, wenn auch sonst noch nichts gemappt war.
Später wurde es gern dafür verwendet (missbraucht?), den Namen in der Karte an eine bestimmte Stelle zu platzieren.
Der Kritikpunkt an diesen Nodes ist mW vor allem, dass Tools wie Nominatim die Entfernung zu den place-nodes für die Zuordnung hernehmen, was zu den absonderlichsten Ergebnissen führen kann.

Zu Nordstrand:
Nach dem Grenzeintrag und Wiki ist es admin_level=8 , also eigenständige Gemeinde. Die admin-Relation erzeugt auch ohne place-node einen Namen auf der Karte, letzterer ist also eigentlich entbehrlich.
municipality passt mMn nicht, da kein Gebilde aus früher selbständigen Ortschaften.
Bei den Wohngebieten darin ist keine einheitliche Linie vorhanden: Teils hängt der place am residential, teils am isolierten Node.
Norderhafen ist hamlet, Süderhafen village ...
Die Kooge als locality sind mMn ok, da als Gebiet unbestimmt.
place-nodes haben generell eine Berechtigung, wo keine Gebiete eingetragen werden können.

Grenzfälle wird es immer geben: Im Schwarzwald z.B. gibt es "Weiler", die aus Einzelgehöften bestehen, die z.T. hunderte Meter voneinander getrennt sind.

DoDoMR wrote:

Es gibt zwar für die Ortsteile entsprechende Gemarkungsgrenzen, die z.T. noch eingetragen werden müssen (diese würden ja dann mit admin-level=9 erfasst werden), für die "Sub-Ortsteile" existieren diese Gemarkungsgrenzen jedoch nicht (diese würden ja dann eigentlich mit admin-level=10 erfasst werden). Da jedoch diese Sub-Ortsteile eigenständige Ortschaften sind, die auch so entsprechend bekannt sind, müssten diese nach wie vor mit place=* erfasst werden.

Ein place-node ist hier nicht zwingend, der Name könnte mMn auch an das residential-Gebiet (falls vorhanden) gehängt werden.

Der Vorteil der admin-Hierarchie ist, dass sie wenigstens bis AL9 halbwegs eindeutig definiert ist. Sie setzt aber die Einteilung in Gebiete voraus.
Die place-Hierarchie ist deutlich diffuser, muss sich aber nicht um Gebiete kümmern.

Ich halte wenig von place-POIs. Den place ist in Wirklichkeit ein Gebiet, mit einer Grenze und einem "gehört dazu" und "gehört nicht dazu". Mit einem place-POI kann man erzwingen, das der Gebietsname an einer gewünschten Stelle steht. Das wird zum Nachteil, wenn diese Stelle außerhalb des dargestellten Ausschnitts ist.

hfst wrote:

Ich halte wenig von place-POIs. Den place ist in Wirklichkeit ein Gebiet, mit einer Grenze und einem "gehört dazu" und "gehört nicht dazu". Mit einem place-POI kann man erzwingen, das der Gebietsname an einer gewünschten Stelle steht. Das wird zum Nachteil, wenn diese Stelle außerhalb des dargestellten Ausschnitts ist.

Das sehe ich nicht so negativ, ich halte es mit den Gründervätern: Ein place-node ist besser als gar nichts.
Wenn aber was "da" ist, wird der place-POI nicht selten zum Ärgernis.

"place=locality"-POI als echte Punkte braucht man relativ selten, weil es dafür häufig genaueres Tagging wie z.B. natural=*, information=*, historic=* gibt.

seichter wrote:

Bei den Wohngebieten darin ist keine einheitliche Linie vorhanden: Teils hängt der place am residential, teils am isolierten Node.
Norderhafen ist hamlet, Süderhafen village ...

Ja, das waren meine Taggingideen, natürlich mit einheitlicher Linie: Die village hatten 200 Häuser oder mehr, die hamlet weniger. Ein paar der Wohngebiete waren schon als Fläche getaggt, dann natürlich mit landuse=residential dran, die bekommen natürlich trotzdem place=hamlet.

Ich habe das gemäß der Diskussion im Changeset wieder zurückgesetzt auf neighbourhoods.

Viele hier sagen place-Knoten sind ein Anachronismus. Ich würde da zustimmen gäbe es Alternativen. Ihr wollt über Grenzen alles abbilden. Probleme dazu, korrigiert mich wenn ich falsch liege.

1. Manchmal gibt es keine passenden Grenzen: z.b. bei Tokio als Millionenstadt wie wir sie verstehen
2. Es ist immer noch wichtig den Mittelpunkt der Siedlung zu definieren: z.B. interessiert mich ein Label von Stuttgart-West nicht mitten im Wald - man bräuchte also admin_centre, ergo das Äquivalent zu place 😉
3. Irgendwann weiter unten gibt es die Grenzen auch nicht mehr (Bsp. oben).

Auch eine Weiterentwicklung von place-Knoten zu Polygonen hin ist sehr mühsam. Für place=* bei größeren Städten hätte man folgende Optionen:
- ein großes Polygon: unwartbar
- Mitbenutzung von landuse-Ways: würde multipolygon für alle landuse bedeuten, dies wollen wir nicht
- eigene Relation mit Segmenten wie bei Boundaries: machbar, aber aufwändig
- ... und wieder bräuchte man ein admin_centre

Und was wäre dann gewonnen? Den Umfang urbaner Flächen einfach zu bekommen ist meist nicht nötig. Wer wissen möchte wie groß eine Siedlung ist sollte landuse innerhalb einer Grenze zusammenzählen.

Daher: Place-Knoten behalten, Grenzen weiter ausbauen und über admin_level=* beide verbinden. Damit kann Nominatim dann die Suche anhand der Grenzen einschränken. Wo es noch keine Grenzen gibt für bis zu village place als Polygon verwenden.
Die admin_levels von Grenzen und place verbinden sollte eigentlich eine Selbstverständlichkeit sein, warum wird das noch nicht generell gemacht?

seichter wrote:

hfst wrote:

Ich halte wenig von place-POIs. ...

Das sehe ich nicht so negativ, ich halte es mit den Gründervätern: Ein place-node ist besser als gar nichts.
Wenn aber was "da" ist, wird der place-POI nicht selten zum Ärgernis.
...

Da gehe ich mit.

Moin,

Jojo4u wrote:

Viele hier sagen place-Knoten sind ein Anachronismus. Ich würde da zustimmen gäbe es Alternativen. Ihr wollt über Grenzen alles abbilden. Probleme dazu, korrigiert mich wenn ich falsch liege.

Will ich dann mal versuchen.

Jojo4u wrote:

1. Manchmal gibt es keine passenden Grenzen: z.b. bei Tokio als Millionenstadt wie wir sie verstehen

Wenn die Weltstadt als die gesamte Region verstanden wird - warum kann man dann nicht die gesamte Region als Relation nehmen?

Jojo4u wrote:

2. Es ist immer noch wichtig den Mittelpunkt der Siedlung zu definieren: z.B. interessiert mich ein Label von Stuttgart-West nicht mitten im Wald - man bräuchte also admin_centre, ergo das Äquivalent zu place 😉

Man möchte gerne ein label haben - hat man doch auch, zumindest ist es möglich.

Jojo4u wrote:

3. Irgendwann weiter unten gibt es die Grenzen auch nicht mehr (Bsp. oben).

Ja, da wird es oft schwierig - aber eigentlich ist lokal immer bekannt, welcher Bereich darunter verstanden wird.
Zudem ist es dann meist so kleinräumig, dass man dort mit Polygonen arbeiten kann.

Jojo4u wrote:

Auch eine Weiterentwicklung von place-Knoten zu Polygonen hin ist sehr mühsam. Für place=* bei größeren Städten hätte man folgende Optionen:
- ein großes Polygon: unwartbar
- Mitbenutzung von landuse-Ways: würde multipolygon für alle landuse bedeuten, dies wollen wir nicht
- eigene Relation mit Segmenten wie bei Boundaries: machbar, aber aufwändig
- ... und wieder bräuchte man ein admin_centre

Bei den ersten beiden Punkten gebe ich Dir vollkommen recht - weil der dritte Punkt nämlich nicht aufwändig, sondern in der Regel bereits gegeben/vorhanden ist:
Gerade bei großen Städten ist der place doch meist identisch mit dem admin-Bereich bzw. der Unterschied (geringer Grüngürtel) vernachlässigbar.
Und label s. o.

Daher: Place-Knoten wo es möglich ist durch Polygon oder Relation (ggf. mit label) ersetzen.

Jojo4u wrote:

Die admin_levels von Grenzen und place verbinden sollte eigentlich eine Selbstverständlichkeit sein, warum wird das noch nicht generell gemacht?

Ich stoße oft genug auf places, die zwar namengeben für den admin sind, aber eben gerade nicht dessen level haben - schließlich ist es oft doch nur ein Siedlungsplatz neben anderen - und damit auch nur Ortsteil statt Gemeinde ...

Edit:
[Missverständnis - wieder gelöscht]

Grüße, Georg

GeorgFausB wrote:

Jojo4u wrote:

1. Manchmal gibt es keine passenden Grenzen: z.b. bei Tokio als Millionenstadt wie wir sie verstehen

Wenn die Weltstadt als die gesamte Region verstanden wird - warum kann man dann nicht die gesamte Region als Relation nehmen?

Leider ganz einfach:

wikipedia wrote:

Im administrativen Sinn existiert keine Stadt Tokio. Stadtgebiet im Sinne dieses Artikels sind die 23 Bezirke Tokios. Ihre Fläche beträgt 621,98 Quadratkilometer. Sie bilden den städtischen Kernbereich des Ballungsraums und befinden sich auf dem Gebiet der ehemaligen Stadt Tokio, die als politische Einheit 1943 aufgelöst wurde. Jeder Bezirk (jap. 区 ku) ist administrativ eine eigenständige Kommune.

siehe: https://de.wikipedia.org/wiki/Tokio#Def … _von_Tokio

Nicht destso trotz ist Japan wirklich "undurchsichtig" erfasst - oder ich blick da nur nicht durch 😉

Gruss
walter

Alle AL7 in "Tokio(4)"

etwas genauer:

GeorgFausB wrote:

Jojo4u wrote:

1. Manchmal gibt es keine passenden Grenzen: z.b. bei Tokio als Millionenstadt wie wir sie verstehen

Wenn die Weltstadt als die gesamte Region verstanden wird - warum kann man dann nicht die gesamte Region als Relation nehmen?

Bis jetzt gibt es keine einzelne Relation - die alte Stadt Tokio besteht jetzt aus 23 Bezirken (admin_level=7 getaggt) innerhalb der Präfektur Tokio (admin_level=4). In der Präfektur Tokio gibt es noch einiges mehr mit admin_level 5,6 und 7.

GeorgFausB wrote:

Jojo4u wrote:

3. Irgendwann weiter unten gibt es die Grenzen auch nicht mehr (Bsp. oben).

Ja, da wird es oft schwierig - aber eigentlich ist lokal immer bekannt, welcher Bereich darunter verstanden wird.
Zudem ist es dann meist so kleinräumig, dass man dort mit Polygonen arbeiten kann.

Also Übereinstimmung dass man bei kleinen place (ich sage bis village) bei fehlenden Grenzen mit Polygonen arbeiten sollte?

GeorgFausB wrote:

Jojo4u wrote:

Auch eine Weiterentwicklung von place-Knoten zu Polygonen hin ist sehr mühsam. Für place=* bei größeren Städten hätte man folgende Optionen:
- ein großes Polygon: unwartbar
- Mitbenutzung von landuse-Ways: würde multipolygon für alle landuse bedeuten, dies wollen wir nicht
- eigene Relation mit Segmenten wie bei Boundaries: machbar, aber aufwändig
- ... und wieder bräuchte man ein admin_centre

Bei den ersten beiden Punkten gebe ich Dir vollkommen recht - weil der dritte Punkt nämlich nicht aufwändig, sondern in der Regel bereits gegeben/vorhanden ist:
Gerade bei großen Städten ist der place doch meist identisch mit dem admin-Bereich bzw. der Unterschied (geringer Grüngürtel) vernachlässigbar.
Und label s. o.

Gerade das Beispiel von Suttgart-West (ein Bezirk, place=suburb) ist ja genau das Gegenteil. Jede Weiterentwicklung von place=* weg von Knoten muss die nicht-urbanen landuses innerhalb der Grenzen ausschließen.

GeorgFausB wrote:

Daher: Place-Knoten wo es möglich ist durch Polygon oder Relation (ggf. mit label) ersetzen.

Welches Tagging mit Relationen meinst du genau? Eine type=boundary, boundary=place Relation? Diese würde wenn möglich die boundary=administrative Ways mitnutzen und wäre definiert als "alle urbanen landuse darin". Der place-Knoten bekommt dann die Rolle place_centre. Denn ein role=label wird durch die OSM-Carto Maintainer abgelehnt wird.

Angesichts eines Umtaggens von place=town->municipality bin ich auf diesen Wert gestoßen. Wer das verwenden will, möge sich aber bitte die Mühe machen, das vernünftig zu definieren. Bisher habe ich gefunden:
- einen aufgegebenen Proposal von 2008
- einen Redirect Tag:place=municipality -> Key:place, dort aber keine Definition
- auf der deutschen Place-Seite eine englische Definition.