Mangelhafte Suchfunktion von OpenStreetmap

Jo Cassel · 2021-11-02 13:30:02

dieterdreist wrote:

Jo Cassel wrote:
Aber wird denn ein flächiger place-Name von einem Renderer auch *angezeigt*, angesichts der Namens-Dopplungsgefahr zu den (global weit überwiegenden) nodes?
Das ist imho kein Problem von carto oder von vector-Karten, sondern von OSM-grundsätzlich.
[...]
wie gesagt, die werden angezeigt, auch dedupliziert, aber halt nicht von Carto.

Ehrlicherweise sollte man es wohl so sagen:
"wer die Namen aus place-Flächen nutzten will, ist gezwungen die OSM-Daten zu dedublizieren",
sonst kommt sowas raus:
https://overpass-turbo.eu/s/1cE3
In der Abfrage kann man auch sehen, wo automatisch gesetzte Namen von Siedlungsplätzen ("place-nodes, Pah, brauchen wir doch nicht!") landen können,
nämlich gern auch mal dort, wo kein einziges Haus steht.

GeorgFausB · 2021-11-02 14:09:59

Moin,

Jo Cassel wrote:

In der Abfrage kann man auch sehen, wo automatisch gesetzte Namen von Siedlungsplätzen ("place-nodes, Pah, brauchen wir doch nicht!") landen können,
nämlich gern auch mal dort, wo kein einziges Haus steht.

das ist aber in meinen Augen ein Problem dessen, wie place-Flächen gesetzt werden - und was man damit nun bezeichnen will.
Man muss m. E. zwischen der Verwaltungseinheit (Stadtteil) und dem Siedlungsplatz (Stadtteil) unterscheiden.
Das Eine ist eine admin-boundary, das Andere kann eine place-Fläche (oder eben ein node) sein
Letztere sollte dann aber m. E. auch nur die besiedelte Teilfläche - inkl. umfassene Grünflächen, aber ohne externe Grünflächen - umfassen.

Grüße
Georg

dieterdreist · 2021-11-02 17:49:25

Jo Cassel wrote:

Ehrlicherweise sollte man es wohl so sagen:
"wer die Namen aus place-Flächen nutzten will, ist gezwungen die OSM-Daten zu dedublizieren",

je nachdem auf welchem Standpunkt man steht könnte man auch sagen die nodes widersprechen der one Element Regel wenn es schon ein Polygon gibt.

Jo Cassel · 2021-11-02 18:26:39

... Na, wenn das dein Standpunkt ist, dann solltest Du ihn auch mutig vertreten, und die "OSM-Karten-Entschriftung" konsequent fortzusetzen,
für den place-node "Rom" gibt es nämlich auch schon ein Polygon.

SimonPoole · 2021-11-02 19:18:02

Es gibt hier https://github.com/gravitystorm/openstr … /pull/2816 einen halben Roman zum Thema den ihr gerade neu auflegt.

Das Problem ist, dass ein Place-Node und Place-Fläche nicht die gleiche Information beinhalten, und das eine aus dem anderen nicht erzeugt werden kann. M.a.W. eine vernünftige De-duplizierung ist nur für den konkreten Anwendungsfall möglich.

Last edited by SimonPoole (2021-11-02 19:23:54)

Kelso-Mg · 2021-11-05 15:23:47

Hallo zusammen,
in den Niederland scheint man sich nach einer Diskussion im Forum, auf fogendes tagging geeinigt zu haben.
https://wiki.openstreetmap.org/wiki/Tag … ry%3Dplace
Das ist da wohl jetzt der Standard.
Das tagging führt zumindest dazu das man bei der Suche nur ein Ergebnis bekommt, bei welchem der Stadtteil mit seiner Grenze angezeigt wird und der place node anzeigt wo das Zentrum ist. Für den normalen einfachen Kartennutzer die optimale Lösung würde ich sagen.
https://www.openstreetmap.org/relation/ … 736/4.8983

Da boundary=adminastrative + admin_level z.B 10, anscheinend die gleiche Bedeutung hat wie boundary=place + place=suburb
und letzteres intuitiver zu taggen ist, meint man wohl auf die admin_level verzichten zu können. So verstehe ich zumindest das wiki zu boundary=place .

Ich verstehe zugebener massen nicht was SimonPoole oben meint, und habe auch nicht vor mir deshalb den halben Roman einzuverleiben, aber vielleicht ist es ja möglich den place node (Stadtteil) mit Fläche als boundary=place einzutragen und die boundary=adminastrative, wenn das nicht das selbe ist wie SimonPoole meint bzw. unterschiedlich Daten enthalten soll weiterhin auch als solche einträgt.

Kelso-Mg · 2021-11-05 18:50:24

Hallo nochmal
mir fiehl eben noch folgendes ein.

Falls SimonPoole hier auf die Verwaltungseinheit abzielt, was der begriff adminastrive ja nahelegt, sind die zumindest in Mönchengladbach in Nord, West , Ost u. Süd eingeteilt.
https://www.moenchengladbach.de/de/stadtbezirke
https://ris-moenchengladbach.itk-rheinl … si0046.asp
Die dann in MG wohl mit admin_level 9 einzutragen wären. Einzelne Stadtteile die keine eigene Verwaltung haben mit boundary=adminstrative zu taggen wären dann unlogisch. Hier wäre boundary=place die bessere Lösung.
Denn Stadtbezirken müsste man dann wohl die einzelnen Stadtteile als Relationen mit role=inner zuordnen.

seichter · 2021-11-05 21:54:45

Kelso-Mg wrote:

Die dann in MG wohl mit admin_level 9 einzutragen wären. Einzelne Stadtteile die keine eigene Verwaltung haben mit boundary=adminstrative zu taggen wären dann unlogisch. Hier wäre boundary=place die bessere Lösung.

Für Stadtteile ohne Verwaltung ist die Einordnung unter AL=10 gebräuchlich.
Hierarchisch darunter gibt es auch noch oft level 11 und sogar 12 (suburb, quarter, neighbourhood) mit der Interpretation "Grenzen für Verwaltung" und nicht "Grenzen von Verwaltung".
boundary=place wäre u.U. treffender, wird aber viel seltener verwendet (5000 vs. 400000).

SimonPoole · 2021-11-06 09:32:55

Kelso-Mg wrote:

Hallo nochmal
mir fiehl eben noch folgendes ein.
Falls SimonPoole hier auf die Verwaltungseinheit abzielt, was der begriff adminastrive ja nahelegt, sind die zumindest in Mönchengladbach in Nord, West , Ost u. Süd eingeteilt.
https://www.moenchengladbach.de/de/stadtbezirke
https://ris-moenchengladbach.itk-rheinl … si0046.asp
Die dann in MG wohl mit admin_level 9 einzutragen wären. Einzelne Stadtteile die keine eigene Verwaltung haben mit boundary=adminstrative zu taggen wären dann unlogisch. Hier wäre boundary=place die bessere Lösung.
Denn Stadtbezirken müsste man dann wohl die einzelnen Stadtteile als Relationen mit role=inner zuordnen.

Wie ich oben schon oben geschrieben habe, geht es mir darum das administrative Grenzen (und die entsprechende admin_level) nur für echte administrative Einheiten verwendet werden. Graubereich geschenkt.

Um ein (sehr) konkretes Beispiel zu geben, die (politische) Gemeinde, admin_level=8, in der ich lebe besteht aus 6 verschiedenen Siedlungen die als Hof, Weiler oder Dorf als Punkt gemappt sind. Es gäbe aber einen klaren Mehrwert wenn der Verbund Siedlungsfläche und Zentrum gemappt werden könnte für diese Dorfteile ohne fake administrative Grenzen zu verwenden. Und nein es gibt -keine- offiziellen Grenzen zwischen den Dorfteilen, auch die swisstopo zum Beispiel braucht grob das Siedlungsgebiet.

Last edited by SimonPoole (2021-11-06 10:10:11)

the-asca · 2021-11-08 09:30:51

Nochmal zur Sache wieder ein reales Beispiel: Überfelder Str., 42855 Remscheid
Typischer Weise wieder Ort weggelassen, PLZ weggelassen, mit "in" versucht, ... aber diesmal blieb's unauffindbar. Remscheid ist ein wenig groß um's mit der Hand abzusuchen, als... Google
Und siehe da, es ist nicht "Über..." sondern wirklich "Ueber...": https://www.openstreetmap.org/way/34391228

Klar, technisch ist "Ü" was ganz anderes als "Ue", aber wie viele werden sich ärgern etwas nicht zu finden, weil man's einfach nicht wissen kann?

Edit: Diskussionen zu Ue/Überfeld bitte hier rein: https://forum.openstreetmap.org/viewtopic.php?id=74207

Last edited by the-asca (2021-11-08 09:40:29)

dieterdreist · 2021-11-11 23:52:02

seichter wrote:

Für Stadtteile ohne Verwaltung ist die Einordnung unter AL=10 gebräuchlich.
Hierarchisch darunter gibt es auch noch oft level 11 und sogar 12

+1

seichter wrote:

(suburb, quarter, neighbourhood) mit der Interpretation "Grenzen für Verwaltung" und nicht "Grenzen von Verwaltung".

place kann sich überschneiden oder deckungsgleich sein, muss aber nicht. Bei Verwaltungsgrenzen hat man normalerweise keine Überschneidungen oder Lücken, das gesamte Territorium ist aufgeteilt, und die Teile sind wieder unterteilt, die Hierarchien sind klar. Bei place ist das nicht unbedingt so, die können sich auch überschneiden, ein quarter kann auch in 2 unterschiedlichen suburbs sein, z.B., etc.

SimonPoole · 2021-11-12 10:59:30

seichter wrote:

Kelso-Mg wrote:
Die dann in MG wohl mit admin_level 9 einzutragen wären. Einzelne Stadtteile die keine eigene Verwaltung haben mit boundary=adminstrative zu taggen wären dann unlogisch. Hier wäre boundary=place die bessere Lösung.
Für Stadtteile ohne Verwaltung ist die Einordnung unter AL=10 gebräuchlich.

In Deuschland.

Hierarchisch darunter gibt es auch noch oft level 11 und sogar 12 (suburb, quarter, neighbourhood) mit der Interpretation "Grenzen für Verwaltung" und nicht "Grenzen von Verwaltung".
....

Damit lässt sich natürlich alles rechtfertigen, auch ein level 14 admin boundary um jedes Grundstück.

Last edited by SimonPoole (2021-11-12 13:18:42)

dieterdreist · 2021-11-12 16:54:09

SimonPoole wrote:

Damit lässt sich natürlich alles rechtfertigen, auch ein level 14 admin boundary um jedes Grundstück.

stimmt, aber ist das nicht bei allen admin_leveln ohne eigene Administration so?

Announcement

#76 2021-11-02 13:30:02

Re: Mangelhafte Suchfunktion von OpenStreetmap

#77 2021-11-02 14:09:59

Re: Mangelhafte Suchfunktion von OpenStreetmap

#78 2021-11-02 17:49:25

Re: Mangelhafte Suchfunktion von OpenStreetmap

#79 2021-11-02 18:26:39

Re: Mangelhafte Suchfunktion von OpenStreetmap

#80 2021-11-02 19:18:02

Re: Mangelhafte Suchfunktion von OpenStreetmap

#81 2021-11-05 15:23:47

Re: Mangelhafte Suchfunktion von OpenStreetmap

#82 2021-11-05 18:50:24

Re: Mangelhafte Suchfunktion von OpenStreetmap

#83 2021-11-05 21:54:45

Re: Mangelhafte Suchfunktion von OpenStreetmap

#84 2021-11-06 09:32:55

Re: Mangelhafte Suchfunktion von OpenStreetmap

#85 2021-11-08 09:30:51

Re: Mangelhafte Suchfunktion von OpenStreetmap

#86 2021-11-11 23:52:02

Re: Mangelhafte Suchfunktion von OpenStreetmap

#87 2021-11-12 10:59:30

Re: Mangelhafte Suchfunktion von OpenStreetmap

#88 2021-11-12 16:54:09

Re: Mangelhafte Suchfunktion von OpenStreetmap

Board footer