Hallo, weiß jemand, warum fast keine Straßen in Lage gefunden werden? Siehe zum Beispiel hier: <http://www.openstreetmap.org/search?query=Meierstra%C3%9Fe%2C%20Lage#map=19/51.99171/8.79392> Ich habe schon einige Sachen angeschaut, z.B. die Stadtgrenze von Lage mit der einer administrativ ähnlichen Stadt – ich habe willkürlich Versmold genommen – verglichen. Ich finde keine Erklärung, weiß aber auch nicht gut, wohin man schauen sollte. Danke Sebastian
Am 16.07.2016 um 19:40 schrieb Sebastian Lisken:
Hallo,
weiß jemand, warum fast keine Straßen in Lage gefunden werden? Siehe zum Beispiel hier:
<http://www.openstreetmap.org/search?query=Meierstra%C3%9Fe%2C%20Lage#map=19/51.99171/8.79392>
Ich habe schon einige Sachen angeschaut, z.B. die Stadtgrenze von Lage mit der einer administrativ ähnlichen Stadt – ich habe willkürlich Versmold genommen – verglichen. Ich finde keine Erklärung, weiß aber auch nicht gut, wohin man schauen sollte.
Danke
Sebastian
Hmm, seltsam ... Die Suche mit "Meierstraße, Lippe" hat drei Treffer, darunter auch den in Lage. In der Auflistung zu dem Treffer in Lage fehlt dann aber die Angabe "Lage". Da steht nur: "Meierstraße, Kernstadt, Ehrentrup, Kreis Lippe, Regierungsbezirk Detmold, North Rhine-Westphalia, 32791, Germany" "Kernstadt" und "Ehrentrup" sind eigentlich Widersprüche. Die Kernstadt von Lage heisst ausserdem "Lage" und nicht "Kernstadt". Ich denke, da stimmt was nicht mit der Relation: http://www.openstreetmap.org/relation/142650 Die hat vielleicht ein Loch? -- Frank Jäger wwwFrank
Am 16.07.2016 um 20:07 schrieb Frank Jäger:
Am 16.07.2016 um 19:40 schrieb Sebastian Lisken: ...
Ich denke, da stimmt was nicht mit der Relation: http://www.openstreetmap.org/relation/142650
Die hat vielleicht ein Loch?
Nö, sieht gut aus: http://ra.osmsurround.org/analyzeRelation?relationId=142650&noCache=true&_no...
This relation seems ok.
-- Frank
Hallo in die Runde, ich habe mir das mal angeschaut und behoben. Das Hauptproblem scheint gewesen zu sein, dass die Relation um die Lage herum (die "Kernstadt"-Relation https://www.openstreetmap.org/relation/6094767) einen admin_level=10 hatte. Zum Vergeleich: Der admin_level der "Kernstadt" von Lemgo ist auf 9 eingestellt (https://www.openstreetmap.org/relation/3978589). Nachdem ich den admin_level auf in Lage auch entsprechend angepasst hatte funktionierte die Suche. Außerdem habe ich noch Kleinigkeiten angepasst: Z.B. Kernstadt in Lage umbenannt. Viele Grüße, Jan-Friedrich Ehlenbröker
On 2016-07-17 01:30, Jan-Friedrich Ehlenbröker wrote:
ich habe mir das mal angeschaut und behoben.
Großartig, vielen Dank!
Das Hauptproblem scheint gewesen zu sein, dass die Relation um die Lage herum (die "Kernstadt"-Relation https://www.openstreetmap.org/relation/6094767) einen admin_level=10 hatte. Zum Vergeleich: Der admin_level der "Kernstadt" von Lemgo ist auf 9 eingestellt (https://www.openstreetmap.org/relation/3978589). Nachdem ich den admin_level auf in Lage auch entsprechend angepasst hatte funktionierte die Suche.
Außerdem habe ich noch Kleinigkeiten angepasst: Z.B. Kernstadt in Lage umbenannt.
Vielen Dank auch für die Informationen. Ich habe mir die Änderungen angeschaut und würde gerne noch wissen, warum der Knoten „Innenstadt“ nötig ist <http://www.openstreetmap.org/node/4306688734>. Er ist mit nichts verbunden, insbesondere nicht mit der Stadtteil-Relation, die du von „Kernstadt“ zu „Lage“ umbenannt hast <http://www.openstreetmap.org/relation/6094767>, die hat ja den Node <http://www.openstreetmap.org/node/240023556> als admin_centre. Interessanterweise hat die Relation für die eigentliche Stadtgrenze <http://www.openstreetmap.org/relation/142650> keinen Node als Member. Trotzdem scheint der Knoten „Innenstadt“ relevant für Suchergebnisse zu sein. Ist das der Grund für seine Existenz? Ob zum Beispiel eine Straße von der Suche als Teil von „Innenstadt“ oder „Maßbruch“ ausgegeben wird, scheint an der relativen Nähe zum Knoten „Innenstadt“ (s.o.) vs. Knoten „Maßbruch“ <http://www.openstreetmap.org/node/547954622> zu liegen. Mit teilweise seltsamen Ergebnissen: so liegt laut nominatim die Händelstraße in Maßbruch <http://www.openstreetmap.org/search?query=H%C3%A4ndelstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>, aber zwei Straßen weiter in Richtung Nordwesten die Blumenstraße angeblich in der Innenstadt <http://www.openstreetmap.org/search?query=Blumenstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>. Die Marker, die beim Überfahren der Suchergebnisse sichtbar werden, könnten als Erklärung dienen, denn für die Händelstraße liegt der Marker mittig zwischen der Thusneldastraße und der Flurstraße, also eher in Richtung Maßbruch, für die Blumenstraße an der Kreuzung Thusneldastraße, also vielleicht etwas mehr in Richtung Innenstadt. Ich kann aber auch in JOSM nicht erkennen, warum die Marker so liegen. Die Händelstraße hat fünf Knoten, die Blumenstraße genau zwei am Anfang und Ende. Für beide Straßen liegen die Knoten etwa symmetrisch und bevorzugen keines der Enden, beide Weg-Objekte sind von der Thusneldastraße zur Flurstraße orientiert. Würde die Suche exakter sein, wenn statt Knoten oder zusätzlich zu ihnen noch ein genaue Grenze als Weg oder Relation existieren würden? (Nicht dass ich das hier anregen möchte, es geht mir nur darum, etwas dazuzulernen.) Ich erwarte natürlich keine vollständigen Antworten (oder irgendwelche). Mir ist nicht neu, dass nominatim schwer erklärbar ist. Vor allem bin ich dankbar für die Reparatur! Sebastian
Am 17.07.2016 um 11:29 schrieb Sebastian Lisken:
On 2016-07-17 01:30, Jan-Friedrich Ehlenbröker wrote:
ich habe mir das mal angeschaut und behoben. Großartig, vielen Dank!
Das Hauptproblem scheint gewesen zu sein, dass die Relation um die Lage herum (die "Kernstadt"-Relation https://www.openstreetmap.org/relation/6094767) einen admin_level=10 hatte. Zum Vergeleich: Der admin_level der "Kernstadt" von Lemgo ist auf 9 eingestellt (https://www.openstreetmap.org/relation/3978589). Nachdem ich den admin_level auf in Lage auch entsprechend angepasst hatte funktionierte die Suche.
Außerdem habe ich noch Kleinigkeiten angepasst: Z.B. Kernstadt in Lage umbenannt. Vielen Dank auch für die Informationen. Ich habe mir die Änderungen angeschaut und würde gerne noch wissen, warum der Knoten „Innenstadt“ nötig ist <http://www.openstreetmap.org/node/4306688734>. Er ist mit nichts verbunden, insbesondere nicht mit der Stadtteil-Relation, die du von „Kernstadt“ zu „Lage“ umbenannt hast <http://www.openstreetmap.org/relation/6094767>, die hat ja den Node <http://www.openstreetmap.org/node/240023556> als admin_centre. Interessanterweise hat die Relation für die eigentliche Stadtgrenze <http://www.openstreetmap.org/relation/142650> keinen Node als Member. Trotzdem scheint der Knoten „Innenstadt“ relevant für Suchergebnisse zu sein. Ist das der Grund für seine Existenz?
Ob zum Beispiel eine Straße von der Suche als Teil von „Innenstadt“ oder „Maßbruch“ ausgegeben wird, scheint an der relativen Nähe zum Knoten „Innenstadt“ (s.o.) vs. Knoten „Maßbruch“ <http://www.openstreetmap.org/node/547954622> zu liegen. Mit teilweise seltsamen Ergebnissen: so liegt laut nominatim die Händelstraße in Maßbruch <http://www.openstreetmap.org/search?query=H%C3%A4ndelstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>, aber zwei Straßen weiter in Richtung Nordwesten die Blumenstraße angeblich in der Innenstadt <http://www.openstreetmap.org/search?query=Blumenstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>. Die Marker, die beim Überfahren der Suchergebnisse sichtbar werden, könnten als Erklärung dienen, denn für die Händelstraße liegt der Marker mittig zwischen der Thusneldastraße und der Flurstraße, also eher in Richtung Maßbruch, für die Blumenstraße an der Kreuzung Thusneldastraße, also vielleicht etwas mehr in Richtung Innenstadt. Ich kann aber auch in JOSM nicht erkennen, warum die Marker so liegen. Die Händelstraße hat fünf Knoten, die Blumenstraße genau zwei am Anfang und Ende. Für beide Straßen liegen die Knoten etwa symmetrisch und bevorzugen keines der Enden, beide Weg-Objekte sind von der Thusneldastraße zur Flurstraße orientiert. Würde die Suche exakter sein, wenn statt Knoten oder zusätzlich zu ihnen noch ein genaue Grenze als Weg oder Relation existieren würden? (Nicht dass ich das hier anregen möchte, es geht mir nur darum, etwas dazuzulernen.)
Ich erwarte natürlich keine vollständigen Antworten (oder irgendwelche). Mir ist nicht neu, dass nominatim schwer erklärbar ist. Vor allem bin ich dankbar für die Reparatur!
Sebastian
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm Hi, ich habe festgestellt, dass bei solchen Sachen wie "warum meint der jetzt das x in y liegt" die Detailansicht von Nominatim ganz gut ist: http://nominatim.openstreetmap.org/details.php?place_id=130900528 Da kann man dann besser nachvollziehen wie er die Zuordnungen zu den verschiedenen Adminleveln usw. macht. Falls das aktuelle Objekt auf einem Admin-Level nicht in einer umschließenden Region liegt (Relation oder Area), da aber entsprechende Nodes rumliegen, dann nimmt er den nächsten Node zur Zuordnung. Zumindest vor zwei Jahren hat der hierzu einfach den euklidischen Abstand von Längen- und Breitengraden berechnet. War also eine recht grobe weil in unseren Breiten schon gut verzerrte Annäherung. Das war damals auch der Grund weshalb ich versucht habe die Stadtteile von Lemgo einzuzeichnen: OSM/Nominatim waren der Überzeugung, dass ich in Entrup wohnte. Das passte gar nicht. Hier mal ein Beispiel für Place-Raten: http://nominatim.openstreetmap.org/details.php?place_id=66262125 Leider wurde inzwischen die Nominatim-Seite überarbeitet und der zeigt die Distanz nicht mehr richtig an sondern oft 0. :/
Zu dem Innenstadt-Node: Das dürfte dazu führen, dass quasi alles in der "Kernstadt"-Relation auch als Innenstadt angesehen wird, da es nur diesen suburb dadrin gibt. Und die Relation umfasst ja mehr als die Innenstadt. Würde man da jetzt noch mehr suburbs reinpacken, so hat man das oben beschriebene "Nächster Node"-Problem, ist also zu ungenau. Um ein ausfüllen der "Kernstadt"-Relation zu vermeiden müsste man eigentlich eine eigene Relation/Area für die Innenstadt machen. Dafür ist das aber meiner Meinung nach zu Schwammig/Subjektiv was Innenstadt ist und was nicht. Gruß, Andreas
Am 17.07.2016 15:42 schrieb tabris:
... Hi, ich habe festgestellt, dass bei solchen Sachen wie "warum meint der jetzt das x in y liegt" die Detailansicht von Nominatim ganz gut ist: http://nominatim.openstreetmap.org/details.php?place_id=130900528 Da kann man dann besser nachvollziehen wie er die Zuordnungen zu den verschiedenen Adminleveln usw. macht. Falls das aktuelle Objekt auf einem Admin-Level nicht in einer umschließenden Region liegt (Relation oder Area), da aber entsprechende Nodes rumliegen, dann nimmt er den nächsten Node zur Zuordnung. Zumindest vor zwei Jahren hat der hierzu einfach den euklidischen Abstand von Längen- und Breitengraden berechnet. War also eine recht grobe weil in unseren Breiten schon gut verzerrte Annäherung. Das war damals auch der Grund weshalb ich versucht habe die Stadtteile von Lemgo einzuzeichnen: OSM/Nominatim waren der Überzeugung, dass ich in Entrup wohnte. Das passte gar nicht. Hier mal ein Beispiel für Place-Raten: http://nominatim.openstreetmap.org/details.php?place_id=66262125 Leider wurde inzwischen die Nominatim-Seite überarbeitet und der zeigt die Distanz nicht mehr richtig an sondern oft 0. :/
Vielen Dank für den Hinweis auf die Detailansicht von Nominatin. Sowas hat mir gestern gefehlt.
Zu dem Innenstadt-Node: Das dürfte dazu führen, dass quasi alles in der "Kernstadt"-Relation auch als Innenstadt angesehen wird, da es nur diesen suburb dadrin gibt. Und die Relation umfasst ja mehr als die Innenstadt. Würde man da jetzt noch mehr suburbs reinpacken, so hat man das oben beschriebene "Nächster Node"-Problem, ist also zu ungenau. Um ein ausfüllen der "Kernstadt"-Relation zu vermeiden müsste man eigentlich eine eigene Relation/Area für die Innenstadt machen. Dafür ist das aber meiner Meinung nach zu Schwammig/Subjektiv was Innenstadt ist und was nicht.
Da stimme ich mit dir überein. Ich habe den Innenstadt-Node gestern als "schneller Lösung". Ohne den Innenstadt-Node wurden alle Adressen der Kernstadt-Relation dem einzigen suburb-Node (Maßbruch, https://www.openstreetmap.org/node/547954622) hinzugefügt. Genau aufgrund der von dir beschriebenen Problematik. Eine bessere Lösung ist es wohl den Innenstadt-Node wieder zu löschen und den Maßbruch-Node in eine Fläche umzuwandeln. Dabei habe ich allerdings gerade gemerkt, dass ich damit auch in das Schwammig/Subjektiv-Problem laufe, da die Grenzen vom Maßbruch nicht wirklich definiert sind. Eventuell könnte ich mich da an den Wahlbezirken der Stadt Lage orientieren (http://lage.de/media/custom/1883_498_1.PDF?1434965411), aber da weiß ich nicht, ob ich das einfach als Datengrundlage verwenden darf (Lizenz?). Hat da vielleicht noch jemand andere Ideen? Viele Grüße, Jan
Am 17.07.2016 um 16:18 schrieb Jan-Friedrich Ehlenbröker:
Am 17.07.2016 15:42 schrieb tabris:
... Hi, ich habe festgestellt, dass bei solchen Sachen wie "warum meint der jetzt das x in y liegt" die Detailansicht von Nominatim ganz gut ist: http://nominatim.openstreetmap.org/details.php?place_id=130900528 Da kann man dann besser nachvollziehen wie er die Zuordnungen zu den verschiedenen Adminleveln usw. macht. Falls das aktuelle Objekt auf einem Admin-Level nicht in einer umschließenden Region liegt (Relation oder Area), da aber entsprechende Nodes rumliegen, dann nimmt er den nächsten Node zur Zuordnung. Zumindest vor zwei Jahren hat der hierzu einfach den euklidischen Abstand von Längen- und Breitengraden berechnet. War also eine recht grobe weil in unseren Breiten schon gut verzerrte Annäherung. Das war damals auch der Grund weshalb ich versucht habe die Stadtteile von Lemgo einzuzeichnen: OSM/Nominatim waren der Überzeugung, dass ich in Entrup wohnte. Das passte gar nicht. Hier mal ein Beispiel für Place-Raten: http://nominatim.openstreetmap.org/details.php?place_id=66262125 Leider wurde inzwischen die Nominatim-Seite überarbeitet und der zeigt die Distanz nicht mehr richtig an sondern oft 0. :/
Vielen Dank für den Hinweis auf die Detailansicht von Nominatin. Sowas hat mir gestern gefehlt.
Zu dem Innenstadt-Node: Das dürfte dazu führen, dass quasi alles in der "Kernstadt"-Relation auch als Innenstadt angesehen wird, da es nur diesen suburb dadrin gibt. Und die Relation umfasst ja mehr als die Innenstadt. Würde man da jetzt noch mehr suburbs reinpacken, so hat man das oben beschriebene "Nächster Node"-Problem, ist also zu ungenau. Um ein ausfüllen der "Kernstadt"-Relation zu vermeiden müsste man eigentlich eine eigene Relation/Area für die Innenstadt machen. Dafür ist das aber meiner Meinung nach zu Schwammig/Subjektiv was Innenstadt ist und was nicht. Da stimme ich mit dir überein. Ich habe den Innenstadt-Node gestern als "schneller Lösung". Ohne den Innenstadt-Node wurden alle Adressen der Kernstadt-Relation dem einzigen suburb-Node (Maßbruch, https://www.openstreetmap.org/node/547954622) hinzugefügt. Genau aufgrund der von dir beschriebenen Problematik. Eine bessere Lösung ist es wohl den Innenstadt-Node wieder zu löschen und den Maßbruch-Node in eine Fläche umzuwandeln. Dabei habe ich allerdings gerade gemerkt, dass ich damit auch in das Schwammig/Subjektiv-Problem laufe, da die Grenzen vom Maßbruch nicht wirklich definiert sind. Eventuell könnte ich mich da an den Wahlbezirken der Stadt Lage orientieren (http://lage.de/media/custom/1883_498_1.PDF?1434965411), aber da weiß ich nicht, ob ich das einfach als Datengrundlage verwenden darf (Lizenz?).
Hat da vielleicht noch jemand andere Ideen?
Viele Grüße, Jan
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
Für Lemgo und Enger hatte ich damals die "Gemarkungen"-Karte vom NRW-Atlas als Grundlage genommen: wms:http://www.wms.nrw.de/geobasis/wms_nw_gemarkungen_fluren?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=nw_gemarkungen_fluren_gemarkungen&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} Aber Achtung: Die müssen nicht völlig mit den Stadtteilen übereinstimmen. Im Falle von Enger habe ich z.B. schon gehört, dass das nicht überall so richtig passt. Allerdings kenne ich jetzt auch keine bessere Quelle. Maßbruch finde ich z.B. gar nicht als Gemarkung. Und nicht anfangen auch noch die Fluren abzuzeichnen (sollten bei dem wms-Link eh nicht angezeigt werden). Die haben keinen Mehrwert für OSM und könnten hier zu bösen Erinnerungen führen. Gruß, Andreas
tabris schrieb:
Für Lemgo und Enger hatte ich damals die "Gemarkungen"-Karte vom NRW-Atlas als Grundlage genommen: wms:http://www.wms.nrw.de/geobasis/wms_nw_gemarkungen_fluren?FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=nw_gemarkungen_fluren_gemarkungen&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} Aber Achtung: Die müssen nicht völlig mit den Stadtteilen übereinstimmen. Im Falle von Enger habe ich z.B. schon gehört, dass das nicht überall so richtig passt. Allerdings kenne ich jetzt auch keine bessere Quelle. Ich habe die Gemarkungen vom NRW-Atlas gerade mal mit den Informationen direkt von der Stadt Lage verglichen (http://lage.de/media/custom/2517_179_1.PDF?1438266931 letzte Seite). Die Daten vom NRW-Atlas sehen gut aus.
Bei der Gelegenheit habe ich dabei auch festgestellt, dass die derzeit eingezeichnete Grenze für Ortsteil Lage so nicht ganz korrekt ist. Da werde ich bei Gelegenheit mal dran setzen.
Maßbruch finde ich z.B. gar nicht als Gemarkung. Maßbruch ist auch kein offizieller Ortsteil. Das Gebiet Maßbruch findet aber schon Niederschlag in der lokalen Kommunikation und z.B. auch in der Benennung von Gebäuden (z.B. Hauptschule Maßbruch). Als Vergleich könnte in Lemgo z.B. Spiegelberg, Biesterberg und Laubke herhalten. Wobei es bei der Eintragung in OSM den Unterschied gibt, dass Spiegelberg etc. in Lemgo als neighbourhood und nicht als suburb eingetragen sind. Aber sie sind auch als einzelne Nodes eingetragen. Allerdings sind in Lemgo deutlich mehr entsprechende Nodes eingetragen, was wohl dazu führt, dass Nominatim häufig eine sinnvolle Orszuordnung vornimmt.
Und nicht anfangen auch noch die Fluren abzuzeichnen (sollten bei dem wms-Link eh nicht angezeigt werden). Die haben keinen Mehrwert für OSM und könnten hier zu bösen Erinnerungen führen.
Ich meine die Diskussionen habe ich (hier in der Mailingliste?) auch mitbekommen. Das werde ich vermeiden, wenn ich die Grenzen anfasse ;-) Viele Grüße, Jan
Am 17.07.2016 um 15:42 schrieb tabris: ...
Um ein ausfüllen der "Kernstadt"-Relation zu vermeiden müsste man eigentlich eine eigene Relation/Area für die Innenstadt machen. Dafür ist das aber meiner Meinung nach zu Schwammig/Subjektiv was Innenstadt ist und was nicht.
Es gibt eine Reihe von außen liegenden Ortsteilen und einen Ortsteil, der "Lage" heißt, genau wie die Gemeinde bzw. Stadt auf einem kleineren "admin_level". Diesen Ortsteil würde ich als Innenstadt bezeichnen. Statt einer eigenen Gemarkungskarte kann man auch die übliche ALKIS-Karte aus dem NRW-Atlas nehmen. Die habe ich im Hintergrund, wenn ich mit dem "Tracer" Gebäudeumringe bilde. Dort sind die politischen Grenzen durch rosafarbige gestrichelte Linien über den Flurstücksgrenzen zu sehen (bis ca. 1:1500). In dieser Karte steht allerdings nicht der Name der Gemarkung dran dran. Das eignet sich eher zur Feinkorrektur der Lage wenn die grobe Struktur schon steht. Ausserdem muss man aufpassen, dass man nur Gemarkungsgrenzen verwendet und nicht die Flurgrenzen. "Flur" ist im Kataster eine Unterteilung der "Gemarkung", für OSM hat das keine Bedeutung. "Gemarkung" ist auch ein Katasterbegriff aber in den meisten Fällen wurde die Kataster-Gemarkung nach den politischen Ortsteilen zugeschnitten. Beispiele: http://www.wms.nrw.de/geobasis/wms_nw_alkis?VERSION=1.1.1&REQUEST=GetMap&SER... http://www.wms.nrw.de/geobasis/wms_nw_alkis?VERSION=1.1.1&REQUEST=GetMap&SER... ALKIS-Karte mit der Grenze zwischen Lage und Ehrentrup. Die hat überraschend viele Schlenker. -- Frank
Am 17.07.2016 um 18:45 schrieb Frank Jäger:
Am 17.07.2016 um 15:42 schrieb tabris: ...
Um ein ausfüllen der "Kernstadt"-Relation zu vermeiden müsste man eigentlich eine eigene Relation/Area für die Innenstadt machen. Dafür ist das aber meiner Meinung nach zu Schwammig/Subjektiv was Innenstadt ist und was nicht. Es gibt eine Reihe von außen liegenden Ortsteilen und einen Ortsteil, der "Lage" heißt, genau wie die Gemeinde bzw. Stadt auf einem kleineren "admin_level". Diesen Ortsteil würde ich als Innenstadt bezeichnen.
Wie schon geschrieben: Innenstadt ist meiner Meinung nach etwas Schwammig/Subjektives. Für mich wäre die Innenstadt deutlich kleiner. Bei Lemgo würde ich z.B. alles innerhalb der Wälle als Innenstadt bezeichnen. Bei Enger wäre es das Gebiet zwischen Bahnhofstraße, Mühlenstraße und Maiwiese. Bei Lage fehlt mir die Ortskenntniss, aber es würde sicherlich auch auf etwas wie "Historischer Stadtkern" hinauslaufen. Für mich persönlich ist die Kernstadt der Stadtteil ohne die umliegenden Dörfer und die Kernstadt besteht für mich aus der Innenstadt und die direkt angrenzenden Wohn-/Gewerbegebiete. Das ist meine subjektive Meinung und die unterscheidet sich ja von deiner Definition einer Innenstadt. Das ist ja einer der Gründe weshalb ich eine Kennzeichnung der Innenstadt als problematisch ansehe. Generell habe ich nichts gegen weitere Unterteilungen, aber dann sollte es schon klarer sein was gemeint ist. Gruß, Andreas
Am 17.07.2016 11:29 schrieb Sebastian Lisken:
Vielen Dank auch für die Informationen. Ich habe mir die Änderungen angeschaut und würde gerne noch wissen, warum der Knoten „Innenstadt“ nötig ist <http://www.openstreetmap.org/node/4306688734>. Er ist mit nichts verbunden, insbesondere nicht mit der Stadtteil-Relation, die du von „Kernstadt“ zu „Lage“ umbenannt hast <http://www.openstreetmap.org/relation/6094767>, die hat ja den Node <http://www.openstreetmap.org/node/240023556> als admin_centre. Interessanterweise hat die Relation für die eigentliche Stadtgrenze <http://www.openstreetmap.org/relation/142650> keinen Node als Member. Trotzdem scheint der Knoten „Innenstadt“ relevant für Suchergebnisse zu sein. Ist das der Grund für seine Existenz?
So wie ich das verstehe bezieht Nominatin Namen auf verschiedenen Ebenen mit in das Suchergebnis mit ein. Also wird im Falle von Lage z.B. place=town (name=Lage) auf einer anderen Ebene als place=suburb (name=Maßbruch) mit einbezogen. Dabei werden auch place-Knoten mit in die Suche einbezogen. Der Maßbruch ist soweit ich das gesehen habe der einzige place=suburb Knoten in Lage. Deshalb hatte ich gestern den Effekt, dass die ganze Innenstadt von Lage dem Maßbruch zugeordnet wurde. Daher habe ich als schnellen (und kruden) Fix den Innenstadt-Konten hinzugefügt.
Ob zum Beispiel eine Straße von der Suche als Teil von „Innenstadt“ oder „Maßbruch“ ausgegeben wird, scheint an der relativen Nähe zum Knoten „Innenstadt“ (s.o.) vs. Knoten „Maßbruch“
So verstehe ich das auch.
<http://www.openstreetmap.org/node/547954622> zu liegen. Mit teilweise seltsamen Ergebnissen: so liegt laut nominatim die Händelstraße in Maßbruch <http://www.openstreetmap.org/search?query=H%C3%A4ndelstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>, aber zwei Straßen weiter in Richtung Nordwesten die Blumenstraße angeblich in der Innenstadt <http://www.openstreetmap.org/search?query=Blumenstra%C3%9Fe%2C%20Lage#map=16/51.9992/8.8039>. Die Marker, die beim Überfahren der Suchergebnisse sichtbar werden, könnten als Erklärung dienen, denn für die Händelstraße liegt der Marker mittig zwischen der Thusneldastraße und der Flurstraße, also eher in Richtung Maßbruch, für die Blumenstraße an der Kreuzung Thusneldastraße, also vielleicht etwas mehr in Richtung Innenstadt. Ich kann aber auch in JOSM nicht erkennen, warum die Marker so liegen. Die Händelstraße hat fünf Knoten, die Blumenstraße genau zwei am Anfang und Ende. Für beide Straßen liegen die Knoten etwa symmetrisch und bevorzugen keines der Enden, beide Weg-Objekte sind von der Thusneldastraße zur Flurstraße orientiert. Würde die Suche exakter sein, wenn statt Knoten oder zusätzlich zu ihnen noch ein genaue Grenze als Weg oder Relation existieren würden? (Nicht dass ich das hier anregen möchte, es geht mir nur darum, etwas dazuzulernen.)
Die seltsamen Ergebnisse liegen auch meiner Vermutung nach an der Verwendung von Knoten anstelle von Flächen. Ich werde nachher mal schauen, ob ich den Maßbruch nicht sinnvoll in eine Fläche umwandeln kann. Dann kann der Innenstadt-Knoten vermutlich auch wieder gelöscht werden.
Ich erwarte natürlich keine vollständigen Antworten (oder irgendwelche). Mir ist nicht neu, dass nominatim schwer erklärbar ist. Vor allem bin ich dankbar für die Reparatur!
Mir macht das ja Spaß :-) Ich habe bei der Suche nach mehr Details auch noch einige Quellen bzgl. Nominatim gefunden: - Vortrag von Sarah Hoffmann auf der SOTM 2013 (englisch; Video: https://vimeo.com/79526203 PDF: http://osm.lonvia.de/presentations/sotm2013_nominatim.pdf ) - Vortrag von Sarah Hoffmann auf der FOSSGIS 2013 (deutsch; Video: https://www.youtube.com/watch?v=f-lGGpuUtOw PDF: http://www.fossgis.de/konferenz/2013/programm/attachments/441_Sarah_Hoffmann... ) - Kurze Übersicht bzgl. des Ablaufs von Nominatim: https://wiki.openstreetmap.org/wiki/Nominatim/Development_overview Diese Quellen sollten einen guten Überblick über die allgemeine Funktionsweise von Nominatim liefern. Wobei ich nicht weiß, inwiefern die Vorgehensweise so noch aktuell ist. Viele Grüße, Jan
participants (4)
-
Frank Jäger -
Jan-Friedrich Ehlenbröker -
Sebastian Lisken -
tabris