Resultate einer Straßensuche auf osm-org

OkerJoker · 2017-10-26T10:17:51.000Z

SimonPoole:

Ich wende bei solchen Diskussionen immer das gleich ein: existieren denn die Ortsteile den wirklich (jetzt noch) als Verwaltungseinheiten?

Nein. Nicht mit eigenständiger Administrative. Ob es Verwaltungsgrenzen innerhalb der Gemeinde gibt, ist eher fraglich.

SimonPoole:

Wenn nicht, so sollten sie IMHO auch nicht als solche gemappt werden (admin_level=was auch immer).

Eigentlich schon. Das Telefonbuch der Telekom zum Beispiel unterscheidet bei den Adressen schon zwischen den Ortsteilen.
Die Post kann auch etwas damit anfangen, wenn Du den Ortsteil bei der Adresse angibst.
In einer großen Stadt orientiert man sich doch auch an den Stadtteilen.

SimonPoole:

Und in einem solchen Fall halte ich den “Fehler” in Nominatim eher, dass ein Ortsteil überhaupt zurückgegeben wird (wenn natürlich keine Admingrenzen vorhanden sind ist das Verhalten vernünftig). Kurze Version: ich halte die ursprüngliche Fragestellung eher für fragwürdig und möglicherweise gar nicht vernünftig unterstützbar, als das wir hier ein Problem in OSM hätten.

Wenn Du Dir Schwülper als “künstliche” Verwaltungseinheit ansiehst, gibt es da 4 eigenständige Orte. Groß Schwülper, Lagesbüttel, Walle und Rothemühle. Alle zum Beispiel mit eigenen Feuerwehren und Sportvereinen und dem entsprechenden Ortsteilnamen. Schon deswegen macht eine Unterscheidung Sinn.

Der Fehler von OSM liegt wohl darin, daß place-Knoten schlecht definiert sind.
Und nein, ich halte das nicht für einen Fehler von Nominatim. Warum sollte Nominatim die Daten der OSM Datenbank schlechter auswerten als andere Programme?

chris66 · 2017-10-26T11:14:02.000Z

Signatur von OkerJoker:

Und ich dachte immer, es geht nicht schlimmer als Google Maps.

Nett…

OkerJoker · 2017-10-26T11:32:41.000Z

@ chris66

Danke.

@kreuzschnabel

Wieso sehe ich bei deinem Beispiel Großaspach den Namen des Ortes auf der Karte bis zu einer gewissen Zoomstufe und bei den Orten in Schwülper nicht?
Großaspach existiert in Nominatim auch nur einmal als Polygon und der Name wird angezeigt.

kreuzschnabel · 2017-10-26T12:03:02.000Z

OkerJoker:

Wieso sehe ich bei deinem Beispiel Großaspach den Namen des Ortes auf der Karte bis zu einer gewissen Zoomstufe und bei den Orten in Schwülper nicht?

Groß Schwülper wird bei mir in ZL 12 bis 15 angezeigt. Wenn bei dir nicht, dann liegt der Fehler bei dir. Die anderen Nodes sind noch nicht wiederhergestellt, weil ich noch nicht weiß, welche du alle gelöscht hast.

Großaspach existiert in Nominatim auch nur einmal als Polygon und der Name wird angezeigt.

Großaspach existiert in OSM als Polygon https://www.openstreetmap.org/way/31355966 und als Node https://www.openstreetmap.org/node/33796070. Wenn Nominatim so intelligent ist, das richtigerweise als dasselbe Objekt zu betrachten, dann werte das bitte nicht auch noch als Fehler

–ks

OkerJoker · 2017-10-26T18:31:18.000Z

Ich habe jetzt zu den “Ortsteil”-Polygonen wieder die “Ortsteil”-Knoten angelegt. Die Merkmale sind identisch.

Und ich erhalte hier jetzt alle möglichen Effekte.
Sehr gut: In Hülperode werden Fläche und Knoten von Nominatim als eine Einheit betrachtet, wie in Großaspach.
Gut: Für Groß Schwülper und Walle liegen in Nominatim Knoten und Fläche getrennt vor, aber der Knoten enthält keine Elemente.
Nicht gut: Für Lagesbüttel liegen in Nominatim Knoten und Fläche getrennt vor, aber der Knoten enthält einige Elemente.
Geht gar nicht: Für Rothemühle liegen in Nominatim Knoten und Fläche getrennt vor und in der Fläche fehlen alle Straßen.

Andreas_Binder · 2017-10-26T18:53:52.000Z

Die teilweise falschen Ortszuordungen beim Nominationsuchergebnis fallen meiner Meinung nach vielen OSM-Kartenbenutzern negativ auf und wurden schon häufiger in OSM als Fehler gemeldet.

Mein Senf dazu:
Das “Nomination-Anzeigeproblem” wäre keines, wenn Nomination die place=* im Ergebnis einfach weglassen würde, wenn das Suchziel innerhalb einer Gemeinderelation liegt und stattdessen nur den Namen der Relation anzeigen würde. Mir würde beim Suchergebnis genügen, wenn z.B. dransteht “Breisacherstraße 1, München”. Den Stadtteil, das Viertel oder Häuserblock brauche ich nicht, vorallem, wenn er nur teilweise stimmt.

Grüße
Andreas

RoterEmil · 2017-10-26T19:10:37.000Z

Andreas Binder:

Die teilweise falschen Ortszuordungen beim Nominationsuchergebnis fallen meiner Meinung nach vielen OSM-Kartenbenutzern negativ auf und wurden schon häufiger in OSM als Fehler gemeldet.

Das stimmt.

Andreas Binder:

Mir würde beim Suchergebnis genügen, wenn z.B. dransteht “Breisacherstraße 1, München”. Den Stadtteil, das Viertel oder Häuserblock brauche ich nicht, vorallem, wenn er nur teilweise stimmt.

Im Berliner Stadtgebiet gibt es m.W. 9x die Berliner Straße.** Allein im Bezirk Pankow findest Du drei (früher noch mehr) Berliner Straßen. Was macht man in diesen Fällen ohne Ortsteilzuordnung? Ich fürchte, Dein Vorschlag wäre hier ein elementarer Rückschritt.

** Das heutige Berlin entstand 1920 durch eine große Eingemeindung etlicher Städte und Dörfer, weshalb es bis heute viele Straßennamendopplungen in Berlin gibt.

streckenkundler · 2017-10-26T20:10:46.000Z

Nach 49 Beiträgen verstehe ich immer noch nicht die Intention der ersten Betrages…

Was will er damit bezwecken?

Ich habt zum Test mal die Straße “Asthoop” gewählt. Die PLZ-Datenbank will immer einen Ort hanben… ok… Bei OSM wir mir “Asthoop, Lagesbüttel, Schwülper, Samtgemeinde Papenteich, Landkreis Gifhorn, Niedersachsen, 38179, Deutschland” angezeigt… Ich habe das auch mit anderen Straßen getestet… Selbes Ergebnis.

OkerJoker:

SimonPoole schrieb:
Ich wende bei solchen Diskussionen immer das gleich ein: existieren denn die Ortsteile den wirklich (jetzt noch) als Verwaltungseinheiten?
Nein. Nicht mit eigenständiger Administrative. Ob es Verwaltungsgrenzen innerhalb der Gemeinde gibt, ist eher fraglich.

Wirklich? Ich glaube es nicht, daß man das nicht abgrenzen kann…

Im Zweifelsfall können unterhalb der Gemeinde Schwülper (AL=8) die entsprechenden Ortsteile mit ihrer Grenze als AL=10 erfasst werden. Als Grenzen können hier z.B. (alte) Gemarkungsgrenzen herhalten. Man muß es aber halt nur machen!!
Meiner Erfahrung nach verändern sich diese Gemarkungsgrenzen i.d. R. nicht, oder nur sehr wenig, so daß sie hinreichend und in der Fragestellung ausreichend sind…

Sven

Andreas_Binder · 2017-10-26T20:11:47.000Z

RoterEmil:

…Im Berliner Stadtgebiet gibt es m.W. 9x die Berliner Straße.** Allein im Bezirk Pankow findest Du drei (früher noch mehr) Berliner Straßen. Was macht man in diesen Fällen ohne Ortsteilzuordnung? Ich fürchte, Dein Vorschlag wäre hier ein elementarer Rückschritt.

Wenn der Ortsteil durch eine Relation ermittelt wurde, habe ich auch nichts gegen “Breisacherstraße 1, Haidhausen Nord, München”.

Wenn der Ortsteil durch einen gewissen Umkreisradius um einen place=xy-POI “erraten” wurde, das Suchergebnis aber innerhalb einer place=xy-Relation liegt, wäre es mir lieber der Rate-Name würde nicht angezeigt werden und nur der Relations-Name. Liegt das Sucherbnis innerhalb keiner place=xy-Relation ist auch ein “geratener” Name besser als nix und soll auch weiterhin verwendet werden, nur eben nicht wenn es “bessere”, genauere Daten über eine place=xy-Relation gibt.

Das meinte ich damit und hoffe ich habe es nicht zu verwirrent erklärt.

Grüße
Andreas

RoterEmil · 2017-10-26T20:46:14.000Z

Andreas Binder:

Das meinte ich damit und hoffe ich habe es nicht zu verwirrent erklärt.

Entschuldige, stand auf der Leitung - und ziehe mein voriges Posting gewissermaßen zurück.

SimonPoole · 2017-10-26T21:14:50.000Z

RoterEmil:

Im Berliner Stadtgebiet gibt es m.W. 9x die Berliner Straße.** Allein im Bezirk Pankow findest Du drei (früher noch mehr) Berliner Straßen. Was macht man in diesen Fällen ohne Ortsteilzuordnung?

Ich nehme an

a) die Strassen sind in verschiedenen PLZ Gebieten,

b) Berlin wird tatsächlich irgend welche real existierende Verwaltungseinheiten unterhalb von AL 8 haben (wie alle grossen Städte im Schnitt)

Das Problem haben wir eher bei kleinen Gemeinden die bei denen es was unterhalb von AL8 eben nicht gibt.

Simon

kreuzschnabel · 2017-10-26T21:38:22.000Z

OkerJoker:

Ich habe jetzt zu den “Ortsteil”-Polygonen wieder die “Ortsteil”-Knoten angelegt. Die Merkmale sind identisch.

Nein, sind sie nicht, wenn du sie neu angelegt hast. Die History fehlt; es sieht jetzt so aus, als seiest du der erste, der diese place-nodes überhaupt jemals angelegt hat, die Dokumentation der Arbeit deiner Vor-Mapper ist durchs Löschen und Wieder-neu-Anlegen verloren gegangen. Deshalb habe ich dir angeboten, die Nodes wiederherzustellen, wenn du mir sagst, welche das waren.

Vergleich mal:

https://www.openstreetmap.org/node/89480508/history
Der place-node von Groß Schwülper hat 7 Versionen, die 10 Jahre zurückreichen. Version #6 ist deine Löschung.

https://www.openstreetmap.org/node/5191130288/history
Der place-Node von Rothemühle hat 2 Versionen, die 7 Stunden zurückreichen. Beide sind von dir, davor scheint es nichts gegeben zu haben.

Deshalb gleicht man eine Löschung nicht durch Wiederanlegen aus, sondern durch Wiederherstellen. ~~Der Editor iD, den du verwendest, kann das nicht, soweit ich weiß, aber JOSM, den ich verwende und die meisten anderen hier auch, kann es.~~ Du müsstest dazu aber etwas Teamgeist zeigen und kommunizieren, statt weiter auf eigene Faust herumzuwurschteln. Ich hab dich zwei Mal gefragt, welche place-Nodes du gelöscht hast, du hast nie geantwortet, und jetzt haben wir sie zwei Mal in der Datenbank (einmal gelöscht, physisch sind die Daten aber noch da, einmal neu).

–ks

OkerJoker · 2017-10-27T07:21:33.000Z

Ich freue mich für Eure Wertschätzung des Historischen.

kreuzschnabel:

OkerJoker:

Ich habe jetzt zu den “Ortsteil”-Polygonen wieder die “Ortsteil”-Knoten angelegt. Die Merkmale sind identisch.

Anders formuliert: Ich habe alle Schlüssel mit allen Werten, die an den Knoten vorhanden waren, an den jeweiligen Polygon gehängt, der den besiedelten Ortsteil darstellen soll.

chris66 · 2017-10-27T07:49:50.000Z

kreuzschnabel:

Den place-Node lassen. Da das place-Polygon nichts Physisches ist, rendert Mapnik daraus keinen Namen und braucht den Node zusätzlich. Ist doof, ich weiß, weil place-Polygon und place-Node zwei mal dasselbe repräsentieren.

place-Node und place-Polygon zu mappen halte ich für falsch, verstößt gegen das one-feature Prinzip, und führt dazu, dass ein Ort bei der Ortssuche im Navi doppelt erscheint.

Harald_Hartmann · 2017-10-27T07:59:18.000Z

chris66:

und führt dazu, dass ein Ort bei der Ortssuche im Navi doppelt erscheint.

Was aber auch ein Fehler der Navi App ist, die hätte durchaus Möglichkeiten, sowas zu filtern.

OkerJoker · 2017-10-27T08:55:42.000Z

chris66:

kreuzschnabel:

Den place-Node lassen. Da das place-Polygon nichts Physisches ist, rendert Mapnik daraus keinen Namen und braucht den Node zusätzlich. Ist doof, ich weiß, weil place-Polygon und place-Node zwei mal dasselbe repräsentieren.

place-Node und place-Polygon zu mappen halte ich für falsch, verstößt gegen das one-feature Prinzip, und führt dazu, dass ein Ort bei der Ortssuche im Navi doppelt erscheint.

Ich finde die Lösung auch nicht toll.
Es ist aber nun mal offensichtlich so, daß man den name-Schlüssel nicht formatieren kann.

D.h. ich habe hier Polygone, die ich um Orte, die verwaltungstechnisch als Ortsteile gezeichnet werden, ziehen muß, damit die Straßen überhaupt dem richtigen Ort (-steil) zugeordnet werden.
Dabei werden 1) ab einer bestimmten Zoomstufe (etwa, wenn man die Straßennamen erkennen kann) die Ortsnamen nicht mehr angezeigt, im Gegensatz zu einem place-Knoten, und 2) umfaßt der eine oder andere Ortspolygon ein geographisch so weit auseinanderliegendes Straßen-/Siedlungsgebiet (Bsp. Rothemühle), daß ein zentrierter Ortsname mitten in der Pampa liegen müßte.

Wenn also der Name auch in etwas tieferen Zoomschichten angezeigt werden könnte und man ihn formatieren könnte (links, mittig, rechts) oder besser, man die Position des Schriftzuges an eine geographische Position binden könnte, wäre ich zufrieden.

Natürlich wäre es irgendwie einfacher, die Straßen mit einem “located_in” Schlüssel zu versehen, um sie eindeutig einem Ort zuzuordnen. Einen postal_code hat man ja bei OSM schnell hinbekommen…

wambacher · 2017-10-27T09:44:02.000Z

Das darf doch wohl nicht (dein/euer?) Ernst sein:

Einfach wie wild ein paar Linien zu zeichnen und damit zu definieren, was wo hingehört?

Diese “Place-Polygone” sind genau so willkürlich wie “meine” geschätzten Admin Boundaries, allerdings sind die “Places” zu 100% geraten, wärend die AL-Grenzen zumindest an der Peripherie sauber sind.

Es wird eine neues Konstrukt eingeführt (zumindest in DE)
Es werden uralte, obsolete Tags verwendet (is_in), die in einer Spatialen Datenbank nichts zu suchen haben.
Es werden PLZ verwendet, obwohl es dafür fertige Relationen gibt
Die Gebiete überschneiden sich teilweise, auch wenn place=* identisch ist.
Es gibt riesige Lücken, die undefiniert sind.

Gesamturteil: Pfusch

Um der Frage vorzubeugen: “Es gibt dort ja keine Grenzen, erst recht keine Administrativen”

Warum haben wir dann diese Grenzen in DEU? davon ca 5500 AL10-12?


select level, count(*)
planet3-# from boundaries
planet3-# where country='DEU'
planet3-# group by level
planet3-# order by wno_number(level);
 level | count 
-------+-------
 2     |     1
 4     |    16
 5     |    19
 6     |   399
 7     |  1254
 8     | 11162
 9     |  4758
 10    |  4353
 11    |  1056
 12    |   164

Ich bin jedenfalls froh, dass es die (in OSM) gibt.

Gruss
walter

wambacher · 2017-10-27T09:49:49.000Z

OkerJoker:

Natürlich wäre es irgendwie einfacher, die Straßen mit einem “located_in” Schlüssel zu versehen, um sie eindeutig einem Ort zuzuordnen. Einen postal_code hat man ja bei OSM schnell hinbekommen…

Ist dir eigentlich klar - oder auch nur bekannt - , dass OSM auf einer Spatialen Datenbank basiert? Dass es dabei absolut unnötig ist, irgendwelche Konstrukte (toll, nun auch noch “located_in”) an die Objekte dranzuschreiben, damit man weiss, wo sie sich befinden?

Dann können wir OSM auch gleich auf mySQL oder Excel/Access umstellen, das kennen eh viel mehr Leute.

wambacher

ps: Ansonsten bestätigt sich bei mir der Eindruck, dass du nicht bereit - oder in der Lage? - bist, konstruktive Kritik zu lesen, zu verstehen und zu akzeptieren. Manche Sachen wurden schon von mehreren Kollegen dargestellt aber du scheinst da nicht drauf zu reagieren.

dooley · 2017-10-27T09:49:50.000Z

OkerJoker:

Wenn also der Name auch in etwas tieferen Zoomschichten angezeigt werden könnte und man ihn formatieren könnte (links, mittig, rechts) oder besser, man die Position des Schriftzuges an eine geographische Position binden könnte, wäre ich zufrieden.

Natürlich wäre es irgendwie einfacher, die Straßen mit einem “located_in” Schlüssel zu versehen, um sie eindeutig einem Ort zuzuordnen. Einen postal_code hat man ja bei OSM schnell hinbekommen…

a) Wenn Dich die Darstellung auf der Hauptkarte oder auf irgendwelchen anderen OSM-basierten Karten nicht gefällt > gibts alles als Opensource > selber Hand anlegen und nach deinen Wünschen gestalten. Easy as this. Kannst ja mal bei Mapbox vorbeischauen, da kannst du, soviel ich weiß, so ziemlich alles in einem eigenen Stil anpassen und dann diesen verwenden.

b) Wie @wambacher Dir schon schrub, ist postal_code an highways “etwas” veraltet und Du hättest gerne ein located_in? Mitnichten wäre es einfacher, einen located_in-Key zu verwenden. Teilst du die highways genau an der Grenze auf? Pflegst du die ganzen located_in bei Eingemeindungen/Änderungen? Wieviele der Mapper würden daran denken, das zu tun? Im Gegenteil würde das den Prozess für viele Mapper verkomplizieren, und das brauchen wir sicher nicht.

geri-oc · 2017-10-27T09:52:24.000Z

chris66:

place-Node und place-Polygon zu mappen halte ich für falsch, verstößt gegen das one-feature Prinzip, und führt dazu, dass ein Ort bei der Ortssuche im Navi doppelt erscheint.

Man kann ja nach der Anzeige sich entscheiden für welchen “Namen” sich man entscheidet - entweder zum node oder “nur in die Gegend”.