Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
Ich arbeite selber gerade an reverse Geocoding mit OSM. Allerdings mit höheren Ansprüchen an die Qualität des Ergebnisses als die Ad-Hoc SQL-Scripte hier. Wird sich noch zeigen wie gut das Resultat dann am Ende wird. Dauert alles noch. Das mit der geografischen zuordnung zu einem Place oder City wird schon schwieriger - Eine eindeutige zuordnung geht nur ueber die boundary relations alles andere ist professionelles raten Mit ein bischen vorbereiten der boundary relations als geometrien in einer datenbank geht das dann auch so: select cb.id, cb.adminlevel, cb.name fromcompleteborders cb, (select ST_SetSRID(ST_Makepoint(8.1, 51.0), 4326) as pos) pos where ST_Within(pos.pos, cb.border) order by adminlevel desc; id | adminlevel |name ++- 163253 | 8 | Hilchenbach 62761 | 4 | Nordrhein-Westfalen (2 rows) Time: 38.139 ms Nur das für die überaus meisten Ortschaften keine solche Relation existiert sonder maximal ein Polygon(way) und meist nur ein node. Weiterhin: Wäre das Ergebniss der Auswertung der Relation nicht ein Multipolygon statt einem Polygon? Das generieren der vordefinierten polygone aus den boundary relations habe ich schonmal hier geschrieben: http://lists.openstreetmap.org/pipermail/talk-de/2009-October/056253.html Dein Ansatz ignoriert vollkommen die Rollen-Tags. Leider spezifiziert http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative so überhaupt garnichts ordentlich. Vor allem hinsichtlich dem gewünschten Inhalt von Relationen. Das ganze oben ist natuerlich zu einfach - Es ist nicht garantiert das die naechstliegende Straße noch in Hilchenbach ist .. D.h. eigentlich muesste man erst das polygon suchen und dann die Straße suchen und zu distance noch pruefen ob die Straße auch durch das Polygon laeuft ... Aber das sind details die im ersten wurf mal zu vernachlaessigen sind ... Das kommt noch alles dazu. Und jetzt noch das Chaos mit den PLZ dazu... Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
On Thu, 29 Oct 2009 12:35:37 +0100, Florian Lohoff f...@rfc822.org wrote: On Thu, Oct 29, 2009 at 11:54:37AM +0100, marcus.wolsc...@googlemail.com wrote: Ich arbeite selber gerade an reverse Geocoding mit OSM. Allerdings mit höheren Ansprüchen an die Qualität des Ergebnisses als die Ad-Hoc SQL-Scripte hier. Wird sich noch zeigen wie gut das Resultat dann am Ende wird. Dauert alles noch. Was kannst du da besser machen? Die SQL Scripte geben exakte resultate d.h. nach spatialen kriterien. Die Daten vorher passend massieren. * PLZ -Suche ermöglichen * In Tags angegebene Länder, Orte, PLZ, ... beachten. * Multipolygone beachten. * Verschiedene Tag-Schreibweisen und alternativ verwendete Tags. * Die ganze Hausnummern-Zuordnung incl. Interpolation. Und nachdenken muss jeder der sowas macht ... Die anforderung bestimmt das ergebniss ... Und du kannst ja mal deine generische behauptung untermauern mit fakten oder meinungen - Das alles scheisse ist weiss ich - erzaehle ich auch jedem der es nicht hoeren moechte ... Hab ich das behauptet? Ich lese nur dass ich recht hohe Ansprüche an die Korrektheit des Ergebnisses stelle. Eine Anforderung die nicht überall nötig ist. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
On Thu, 29 Oct 2009 13:05:45 +0100, Florian Lohoff f...@rfc822.org wrote: Damit bezweifelst du dir korrektheit der SQL Statements - hast du dafuer belege? Das oben ist nur zusaetzliche information aber nichts was mit korrektheit zu tun hat. Sie sind insofern nicht korrekt, dass die durchaus möglicher Rolle inner z.B. nicht beachtet wird und wege in anderen Rollen als und outer nicht ignoriert werden. z.B. dürfte jeder eine Referenz mit einer neuen Rolle part_of auf das Polygon eines umgebenden Gebietes einbauen oder Partnerstadt auf das Polygon einer anderen Ortschaft und solche Spässe. Darf ja jeder machen wie er will da so eine Rolle noch nicht mit einer anderen Semantik benutzt wird oder dokumentiert ist. Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner. Derjeniger moechte das die Daten funktionieren soll die Tags richtig schreiben und nicht allen die die daten verarbeiten aufzwingen megabyte an alternativschreibweisenlisten zu pflegen. addr:postcode ist genauso richtig wie postal_code. is_in:country ist genauso richtig wie addr:country ... Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
On Thu, 29 Oct 2009 13:11:54 +0100, Satz Klauer satzkla...@googlemail.com wrote: Nana, nicht gleich streiten! Das war ja nun wirklich eine eher harmlose Frage - was macht ihr bei einer Diskussion Windows vs. Linux oder Java vs. C#? ;-) On 10/29/09, marcus.wolsc...@googlemail.com marcus.wolsc...@googlemail.com wrote: Ich arbeite selber gerade an reverse Geocoding mit OSM. Klingt gut - wird es Open Source? Unwarscheinlich aber einige Ideen, die mir so gekommen sind, kann ich für die beiden alternativen Vorwärts-Adresssuchen in Traveling Salesman gut verwenden. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
On Thu, 29 Oct 2009 15:20:52 +0100, Florian Lohoff f...@rfc822.org wrote: On Thu, Oct 29, 2009 at 03:17:09PM +0100, marcus.wolsc...@googlemail.com wrote: On Thu, 29 Oct 2009 13:05:45 +0100, Florian Lohoff f...@rfc822.org wrote: Damit bezweifelst du dir korrektheit der SQL Statements - hast du dafuer belege? Das oben ist nur zusaetzliche information aber nichts was mit korrektheit zu tun hat. Sie sind insofern nicht korrekt, dass die durchaus möglicher Rolle inner z.B. nicht beachtet wird und wege in anderen Rollen als und outer nicht ignoriert werden. Wieviele admin boundarys mit enclaven oder exclaven haben wir denn in D? Und wieviel der prozentualen flaeche macht das aus? a) Ich beschränke mich nicht auf D. Warum nimmst du das an? b) Ganze Länder sind selber ein admin-boundary mit Exclaven und Enclaven. Wie viel mehr Fläche hättest du gerne? Alles admin_boundary sind ja gleich zu verarbeiten. Egal was in admin_level steht. Also behandelst du ein paar gültige Fälle halt nicht. Das macht in 99% keine Probleme und man kann es als Design-Entscheidung problemlos akzeptieren. Muss man aber nicht. z.B. dürfte jeder eine Referenz mit einer neuen Rolle part_of auf das Polygon eines umgebenden Gebietes einbauen oder Partnerstadt auf das Polygon einer anderen Ortschaft und solche Spässe. Darf ja jeder machen wie er will da so eine Rolle noch nicht mit einer anderen Semantik benutzt wird oder dokumentiert ist.Q Das problem ist alleine das in D wir mal alles ganz anders machen als alle anderen - type=multipolygon hat international nichts mit grenzen zu tun - Nur in D ... Es ist trivial zu unterstützen also kann man's auch gleich universell machen. Multipolygon ist neben Polygon ja einer der Standard-Datentypen in der GIS-Erweiterung. Wenn wir es in D anders machen als woanders, dann muss eine Suche halt mit Deutschland und mit dem Rest der Welt umgehen können ohne Fehler zu machen. Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner. Derjeniger moechte das die Daten funktionieren soll die Tags richtig schreiben und nicht allen die die daten verarbeiten aufzwingen megabyte an alternativschreibweisenlisten zu pflegen. Verschiedene Philosophien. Du verweigerst ein korrektes Ergebniss und willst so Mapper zwingen korrekt zu mappen. Dabei unterstelle ich dir mal dass du annimmst, derjenige welcher die Suche benutzt ist überhaupt Mapper. Ich will das akurateste mögliche Ergebniss mit dem was momentan so tatsächlich getagged ist. Das umfasst auch sehr oft benutzte, alte Tags welche nützliche Informationen enthalten. (wie z.B. postal_code) addr:postcode ist genauso richtig wie postal_code. is_in:country ist genauso richtig wie addr:country Wofuer brauche ich die in dem obigen Beispiel? Du brauchst sie, weil PLZ, Land und Hausnummer untrennbar zur Adresse gehören. Und jetzt lass mal das Rumgetrolle. Das ich nach mehr als nur Strasse+Ort suche ist dir ja jetzt ausreichend bekannt. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner. Derjeniger moechte das die Daten funktionieren soll die Tags richtig schreiben und nicht allen die die daten verarbeiten aufzwingen megabyte an alternativschreibweisenlisten zu pflegen. addr:postcode ist genauso richtig wie postal_code. is_in:country ist genauso richtig wie addr:country ja klar, es ist alles richtig in OSM, auch heiwei=preimeri, nur halt ein bisschen unueblicher, aber vielleicht hat sich derjenige ja was dabei gedacht. Schadet trotzdem nicht, die tags, die derzeit/mittlerweile ueblich sind, bevorzugt zu nennen, da man so die Daten am ehesten einheitlich bekommt. Wenn man bei jeder Gelegenheit auch weniger haeufig verwendete Alternativen promoted, wird dieses Ziel noch schwerer zu erreichen. Die addr:... -Tags haben ja z.B. den Vorteil, dass sie einer durchgehenden Logik (Adressen-namespace) folgen, waehrend man sich ansonsten die Dinger aus name, postal_code und isin einzeln zusammensuchen muss. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
2009/10/29 Martin Koppenhoefer dieterdre...@gmail.com: Und bei deiner Tag-Schreibweisen bin ich ja ein erklaerter gegner. Derjeniger moechte das die Daten funktionieren soll die Tags richtig schreiben und nicht allen die die daten verarbeiten aufzwingen megabyte an alternativschreibweisenlisten zu pflegen. addr:postcode ist genauso richtig wie postal_code. is_in:country ist genauso richtig wie addr:country ja klar, es ist alles richtig in OSM, auch heiwei=preimeri, nur halt ein bisschen unueblicher, aber vielleicht hat sich derjenige ja was dabei gedacht. Schadet trotzdem nicht, die tags, die derzeit/mittlerweile ueblich sind, bevorzugt zu nennen, da man so die Daten am ehesten einheitlich bekommt. Wenn man bei jeder Gelegenheit auch weniger haeufig verwendete Alternativen promoted, wird dieses Ziel noch schwerer zu erreichen. Die addr:... -Tags haben ja z.B. den Vorteil, dass sie einer durchgehenden Logik (Adressen-namespace) folgen, waehrend man sich ansonsten die Dinger aus name, postal_code und isin einzeln zusammensuchen muss. Das hat nur bei interaktiven Anwendungen, nur wenn der Nutzer Mapper ist und nur wenn der Nutzer erfährt warum da keine Adresse raus kommt erzieherische Wirkung. Wie gesagt, ist nicht mein Ziel. Mir geht es in diesem einen Fall darum OSM zu promoten mit hey, schaut mal wie gut und zuverlässig das schon klappen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orts/Straßennamen zu Koordinaten finden
Schadet trotzdem nicht, die tags, die derzeit/mittlerweile ueblich sind, bevorzugt zu nennen, da man so die Daten am ehesten einheitlich bekommt. Wenn man bei jeder Gelegenheit auch weniger haeufig verwendete Alternativen promoted, wird dieses Ziel noch schwerer zu erreichen. Guckt man in die Daten so machen is_in:country und postal_code gerade mal noch 5% im tagging aus, der Rest hat es mit dem Karlsruher Schema ausgedrückt. Könnte man also getrost beerdigen. Würde man das Karlsruher Schema noch um Kreise etc. erweitern, könnte man sich auch noch das is_in komplett schenken und hätte langsam eine einheitliche Ausdrucksform für Standortfragen. Zumal die einzel is_in sowieso kaum einer nutzt und statdessen das schlecht auswertbare full is_in mit Kommas noch zu 90% in Nutzung ist. Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
