Hallo zämä Ihr seid aber fleissig! ;-)
Genauigkeit: zur Genauigkeit, die letzte Spalte im xls hat Koordinaten (2x 6stelligeZahl). Da ist auch ein Google-Link hinterlegt. ▲
Genügt diese Genauigkeit (vor allem bei den fehlenden zum Erzeugen)?
Reproduzierbarkeit: es gibt jedes Jahr etwa 20 Namensänderungen (gemäss Webseite braucht es da etwa 5 Formulare für einen offiziellen Antrag). Also 1x im Jahr würde es auch Sinn machen, die Daten automatisch zu aktualisieren? => dokumentierte Prozedur ... ?
Namensgebungen: A) Für Änderungen braucht es eben eine Bewilligung vom BAV ,-), es sind also 'offizielle Bezeichnungen. Ich fragte bei der SBB und der RBS, warum die Station 'Steinibach nicht 'Zollikofen vorangestellt hat (ich fand die Haltestelle auf dem iPhone in der SBB.app nicht unter Zollikofen xxxxx ). Zollikofen, Bahnhof gibt es, Münchenbuchse, Bahnhof nicht. Mir ist sie auch zuwenig systemisch, aber sie sollte meiner Meinung nach schon stimmen.
B) nat_name=Zürich Auf jeden Fall schlage ich vor einen einheitlichen Tag für alle zu verwenden, damit bei einem Aktualisieren die Tags mit einer eindeutigen Bezeichnung (Suchbegriff) auch sofort gefunden werden können? alt_name= Haltestelle CH ?
typ: Bus, NFB, Tram, Zug?
Endziel: so wie bei search.ch ? ;-))
Grundsätzlich: wir können nicht alles machen - je mehr Leute wir mit- involvieren können - desto besser!
än Gruess Arthur Bonino
Am 24.01.2010 um 18:17 schrieb Arthur Bonino_q:
Hallo zämä Ihr seid aber fleissig! ;-)
Genauigkeit: zur Genauigkeit, die letzte Spalte im xls hat Koordinaten (2x 6stelligeZahl). Da ist auch ein Google-Link hinterlegt. ▲
Diese Zahlen sind schweizer Koordinaten, die Einheit und somit auch die Genauigkeit dafür ist 1 Meter. Dies sollte locker reichen, da eine übliche Strasse mindestens 3m breit ist (sonst hat kein Bus mehr drauf platz!). --Sandro
Hallo zusammen
Ich schlage mich gerade mit Grenzen herum und habe Relationen dazu angelegt. Ich habe jedoch nirgendwo gefunden (auch auf Englisch nicht), ob bzw. wie man Eltern- und Kind-Relationen eintragen soll. Rein gefühlsmässig würde ich einfach alle Gemeinden (bzw. die Relationen davon) als Kinder von Bezirken definieren und die Bezirke, als Kinder von Kantonen und die Kantone dann von der Schweiz. Eine andere Möglichkeit wäre, dass die Gemeinden zusätzlich auch "Kinder" (zwar keine direkten Kinder aber ich weiss nicht wie das gedacht ist...) der Kantone und der Schweiz sind. Mir scheint dies wird bis jetzt ziemlich spährlich benutzt und ich habe auch keine durchgängigen Muster in der Benutzung entdeckt. Wie würde man eine Eltern-Kind-Relation überhaupt herstellen - mit gegenseitigen Rollendefinitionen der Relationen?
Auf das Eltern-Kind-Thema gestossen bich ich eigentlich, da bei der Ortssuche in OSM teilweise sehr komische Resultate rauskommen und ich dachte, dass das ev. damit zu tun hat: Suche nach Solothurn liefert unter anderem "Town Solothurn, Bezirk Thierstein, Oberaargau, SO, Switzerland, Europe" (die Stadt Solothurn liegt jedoch im Bezirk Solothurn) oder bei Olten: "Town Olten, Bezirk Gösgen, Oberaargau, Solothurn, Switzerland, Europe" (Olten liegt eigentlich im Bezirk Olten) Olten und Solothurn liegen beide im Oberaargau, das scheint ja riesig zu sein! :-) Auch seltsam: Einmal steht für den Kanton (oder was wird da abgefragt?) SO und einmal Solothurn, woher kommt das? Weiss da jemand genaueres über dieses "OpenStreetMap Nominatim" das die Suchresultate liefert?
Mich stört es weniger, dass die Eltern-Kind-Relationen kaum umgesetzt sind (ich weiss ja auch nicht wofür sie gut sind oder sein könnten). Aber für Endnutzer, die die OSM-Karte brauchen wollen um einen Ort zu finden ist es nicht gerade die beste Werbung für die Qualität von OSM wenn so komische Resultate auftauchen.
Grüsse, OSMfan
Hoi OSMfan
Solche Eltern-Kind Relationen sind eigentlich nicht notwendig, da diese Information durch die Georeferenzierung der Objekte in der Datenbank schon gegeben sind.
Unter http://nominatim.openstreetmap.org/ kannst Du dir genauer anschauen, wie nominatim sich die Informationen zusammensucht. Bei deinem Beispiel Olten (http://nominatim.openstreetmap.org/details.php?place_id=62782) denke ich dass der node http://www.openstreetmap.org/browse/node/245012219 die Information Oberaargau falsch zum Resultat hinzufügt. Dieser node sollte wohl durch eine entsprechende Relation ersetzt werden, dann stimmt auch das Resultat.
Das zeigt auch, dass eher schon zuviel Information in OSM drinn ist, die bestehenden Informationen eher bereinigt/ausgedünnt werden müssen.
Olten und Solothurn liegen beide im Oberaargau, das scheint ja riesig zu
sein! :-)
Aus der Sicht nominatims ist er wirklich riesig! http://nominatim.openstreetmap.org/details.php?place_id=599630
Gruess, Micha
Hallo Micha,
Besten Dank für die Erkärung... wobei wirklich kapiert hab ich den Nominatim trotzdem noch nicht. :-/
Micha Ruh schrieb:
Unter http://nominatim.openstreetmap.org/ kannst Du dir genauer anschauen, wie nominatim sich die Informationen zusammensucht.
Da hatte ich wohl Tomaten auf den Augen, als ich diese Seite vorher besuchte, mir ist nur die Karte aufgefallen. Allerdings helfen mir FAQ und Wiki-Seite nur begrenzt weiter...
Bei deinem Beispiel Olten (http://nominatim.openstreetmap.org/details.php?place_id=62782) denke ich dass der node http://www.openstreetmap.org/browse/node/245012219 die Information Oberaargau falsch zum Resultat hinzufügt. Dieser node sollte wohl durch eine entsprechende Relation ersetzt werden, dann stimmt auch das Resultat.
Ist ja ganz schön verwirrend. Ich kann jedenfalls nicht nachvollziehen, wieso der Node 245012219 das Resultat beeinflussen sollte, da er in Bern situiert ist (is_in) und von Bern taucht im Suchresultat nichts auf. Allerdings bezieht sich http://nominatim.openstreetmap.org/details.php?place_id=599630 auf diesen Node - wobei mir auch wieder nicht klar ist, wie denn die riesige Fläche (bis in Wallis) in dieser seltsamen Form daraus entseht.
Zudem steht ja im Oltner Beispiel vor "Oberaargau" auch noch der (falsche) "Bezirk Gösgen", wieder mit so einer komischen Form, obwohl es einen Bezirk Olten mit admin_level gibt; gemäss Nominatim-Beschreibung sollten doch admin-levels priorisiert werden, oder nicht?
Sehr kreativ ist auch der Bahnhof Olten, der ausser zu Gösgen und Oberaargau zuerst noch in die Nachbargemeinde Trimbach eingeordnet wird...
Verwirrte Grüsse, OSMfan
Hoi OSMfan,
Unter http://wiki.openstreetmap.org/wiki/Nominatim/Development_overviewsteht, wie nominatim sich die Hierarchie der verschiedenen Objekte zusammenbaut/bewertet. So ganz genau verstehen muss man das nicht unbedingt. :D
Ich denke viele der angesprochenen Probleme werden dadurch verursacht, dass Kantone/Bezirke als node und als Relations-Grenze getaggt sind, das bringt den armen nominatim durcheinander.
Löschen von nodes, welche durch den Import von genaueren (Kantons-)grenzen überflüssig wurden wird die Situation sicher verbessern.
Ist ja ganz schön verwirrend. Ich kann jedenfalls nicht nachvollziehen,
wieso der Node 245012219 das Resultat beeinflussen sollte, da er in Bern situiert ist (is_in) und von Bern taucht im Suchresultat nichts auf.
node 245012219 (Oberaargau) is_in = Bern;Berne,Schweiz,Europe
Wird von nominatim nicht korrekt in seiner Hierarchie eingeordnet (Siehe Address Sektion unter http://nominatim.openstreetmap.org/details.php?place_id=599630), nominatim weiss hier nicht, dass der Oberaargau zur Schweiz oder zu Bern gehört.
Hier wird der is_in Tag nicht korrekt sein, frag mich aber nicht wie er korrekt sein sollte, der node sollte sowieso von einer Relation abgelöst werden.
Allerdings bezieht sich http://nominatim.openstreetmap.org/details.php?place_id=599630 auf diesen Node - wobei mir auch wieder nicht klar ist, wie denn die riesige Fläche (bis in Wallis) in dieser seltsamen Form daraus entseht.
Da sind die Probleme in Brig-Glis (is_in = Bezirk Brig,Valais;Wallis,Valais,Schweiz,Europe) <- doppelt Valais Delémont (is_in = District de Delémont,Jura,Jura,Schweiz,Europe) <- doppelt Jura
Zudem steht ja im Oltner Beispiel vor "Oberaargau" auch noch der (falsche) "Bezirk Gösgen", wieder mit so einer komischen Form, obwohl es einen Bezirk Olten mit admin_level gibt; gemäss Nominatim-Beschreibung sollten doch admin-levels priorisiert werden, oder nicht?
Ich finde keinen 'Bezirk Olten mit admin_level' mit nominatim
Sehr kreativ ist auch der Bahnhof Olten, der ausser zu Gösgen und Oberaargau
zuerst noch in die Nachbargemeinde Trimbach eingeordnet wird...
Aber der Bahnhof wird gefunden :D
Ich finde es einfach toll, wie gut nominatim _weltweit_ in einem total heterogenen tagging Umfeld funktioniert.
Wenn du es jetzt perfektionieren willst, wird es darauf hinauslaufen, für jede Gemeinde eine Relation zu erstellen (name=), in welcher die Grenze beinhaltet ist und auch einen node fürs Dorfzentrum (place=village, aber ohne name= , der kommt von der Relation). Dann eine Relation pro Bezirk, welche als member die Gemeinde-Relationen beinhaltet, oder die Teil-Grenz-Ways der zu beinhaltenden Gemeinden (falls es überhaupt Bezirke im Kanton gibt), dann Kantone, dann eine für die Schweiz.
Ich sehe also schon hier mind. 2 verschiedene 'Korrekte' Varianten..
Die ganze Schweiz in einem solch einheitlichen Schema zu erfassen dauert wohl eine halbe Ewigkeit und ist einiges Komplizierter als die einfachen place=village nodes.
Die ganzen is_in= sind Datentechnisch gesehen überflüssig, ebenso die place=village nodes, place=state nodes etc. Die sind aber für 'einfacher' gestrickte Software sehr hilfreich und vorallem sind sie historisch gewachsen (früher gabs noch keine Relationen in OSM). Oder ich kann eintragen: 'Hier ist das Engadin', is_in=Graubünden ohne die genauen Grenzen zu kennen. Super Sache!
Im Moment wirst du damit leben müssen, dass nominatim ab und zu etwas falsch liegt, das wird sich erst bessern, wenn ein funktionierendes Schema gefunden wird, sich alle darauf Einigen, die Erfassung vollständig ist... kurz gesagt in ca. 3 Jahren :D
Gruess, Micha
Hoi Micha
Besten Dank für die ausführliche Antwort, mal schauen ob ichs jetzt besser verstanden habe. :-)
Micha Ruh schrieb:
Unter http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview steht, wie nominatim sich die Hierarchie der verschiedenen Objekte zusammenbaut/bewertet. So ganz genau verstehen muss man das nicht unbedingt. :D
Das hatte ich gelesen und zwar nicht 100% verstanden, aber vor allem das mit dem Indexing (country to street level) hatte ich im Kopf...
Löschen von nodes, welche durch den Import von genaueren (Kantons-)grenzen überflüssig wurden wird die Situation sicher verbessern.
Und was passiert mit den Daten aus OpenGeoDB, die häufig bei diesen Nodes zu finden sind? Die sind doch teilweise recht ausführlich...
Welche Nodes meinst du eigentlich, nur die der Kantone oder auch Gemeinden/Bezirke etc.? Ich habe den Überblick überhaupt nicht, wie Nodes in Dorf-/Stadtkernen behandelt werden sollen und habe auch nirgendwo Infos dazu gefunden, wo gibt's da eine Dokumenation dazu? Ich habe z.B. schon folgende Rollen gesehen: capital (oder auch fälschlicherweise capitol), core, admin_centre, label und noch weitere. Teilweise erscheint dann die Relation als "boundary", manchmal als "place" aber auch als "relation".
Ich finde keinen 'Bezirk Olten mit admin_level' mit nominatim
Vielleicht habe ich mich unklar ausgedrückt, ich finde jedenfalls diesen hier: http://nominatim.openstreetmap.org/?q=bezirk+olten&viewbox=-180%2C73.94%... Der hat einen admin_level (=6) zugeordnet und darum dachte ich, dass dieser richtige Bezirk erkannt werden sollte. Jetzt verstehe ich aber ein wenig besser, dass Nominatim durch uneinheitliche is_in Daten (Brig-Glis etc.) und darum überlappende Flächen durcheinandergebracht wird.
Wenn du es jetzt perfektionieren willst, wird es darauf hinauslaufen, für jede Gemeinde eine Relation zu erstellen (name=),
Daran war ich nämlich gerade :-) Zugegebenermassen ist es im Kanton Solothurn relativ einfach, da die genauen Grenzen schon importiert worden sind.
in welcher die Grenze beinhaltet ist und auch einen node fürs Dorfzentrum (place=village, aber ohne name= , der kommt von der Relation).
OK, das müsste ich dann noch ändern. Aber wie gesagt weiss ich nicht, welche Eigenschaften oder Rollen jetzt so ein Node idealerweise haben sollte. Wenn z.B. ein Ort gleichzeitig Hauptstadt von Bezirk und Kanton ist, bekommt der Node dann 3x ein place mit town (village/city), district und canton?
Dann eine Relation pro Bezirk, welche als member die Gemeinde-Relationen beinhaltet, oder die Teil-Grenz-Ways der zu beinhaltenden Gemeinden (falls es überhaupt Bezirke im Kanton gibt), dann Kantone, dann eine für die Schweiz.
Ich sehe also schon hier mind. 2 verschiedene 'Korrekte' Varianten..
Bei der ersten Variante bin ich nicht sicher, wie ich sie umsetzen könnte, ginge aber vermutlich viel schneller. Kann ich einfach eine Relation machen und alle Gemeinde-Relationen als Mitglieder definieren? Das wären dann aber die (nicht notwendigen) Eltern-/Kind-Relationen, oder nicht?
Sorry für die langen Posts und Grüsse, OSMfan