Am 11.10.2011 12:08, schrieb Peter Wendorff: > Hallo Nils. Moin! > Ich glaube nicht, dass eine solche API sinnvoll machbar ist. > Im Gegenteil würde eine solche API die Problematik des Preprocessings > erneut verstecken. > Eine Routing-Anwendung braucht ein anderes Datenformat als ein Renderer > und wieder was anderes als eine lokale Restaurantsuche. > Sinnvollerweise wird die Restaurantsuche außerdem nur ein kleines Subset > der Datenbank überhaupt haben wollen, andere Anwendungen brauchen andere > Teilmengen. > > Der Zugriff ist komplett unterschiedlich: Suche ich in erster Linie nach > Namen (Lokalsuche), nach Topologie (Router) oder nach geografischer > Position ohne Berücksichtigung der Topologie? > > Die Inhalte sind komplett unterschiedlich: Nur OSM-Editoren werden die > komplette Datenbank mit den Original-Tags brauchen, alle anderen werden > das vorverarbeiten. Wozu "highway=residential" als Tag speichern, wenn > nur 8 wohldefinierte Tags gebraucht werden? > > Insofern bin ich mir nicht sicher, ob das so sinnvoll und machbar ist, > was Du vorschlägst.
Tsm tsm tsm... Das stimmt, bricht aber die Idee noch nicht ganz - vielleicht drücke ich mich da undeutlich aus bzw. sehe das nur von meinem aktuellen Wunsch nach einer plattformübergreifenden Navi Software für OSM gefärbt ;) Wenn es diese stark unterschiedlichen Teile braucht, dann müssen das eben, da wo es nicht mehr unter einen Hut zu bekommen ist, getrennte Module werden. Ich kann mir aber dennoch vorstellen, daß viel miteinander vereinbar ist. So wäre bspw. die POI Sache sicherlich auch mit dem einen Datenbank-Modul abbildbar und man könnte in die Erzeugung der Datenbank aus dem OSM File Optionen einfließen lassen, sodaß bestimmte Informationen eben weggelassen oder stark vereinfacht werden. Letztlich basieren sehr viele Anwendungen ja doch auf einer 2D Suche in dem riesigen Datenbestand - egal ob nach POIs oder Ways für die Darstellung gesucht wird. Das Routing ist in der Tat etwas, wo man anders herangehen könnte - das wäre dann mal mit Experten für solche Routing-Algorithmen zu klären, was man da wiederverwenden oder neu machen müßte. In Spatialite ist das über recht komplexe Indize (AFAIK) gelöst, d.h. die Datenbank ist immernoch die gleiche Datenbank, es kommt "nur" ein komplexer Index dazu, der dann das Routing ermöglicht. Ich bin da leider auch kein Experte und habe auch leider keine Zeit es zu werden... doch naiv sehe ich da immernoch mehr Schnittmenge als disjunkte Teile. > Gruß > Peter Viele Grüße nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
