hi
Zuerst mal möchte ich sagen, dass ich etwas mit Studenten im Rahmen
einer Übung machen will.
Ideal wäre eine "normale" SQL basierte Lösung und dann eine schnellere
Lösung die
wie auch immer gemacht wird - falls es so etwas gibt.
Das was ich mit den Stundenten machen werde, wird sehr wahrscheinlich
nichts sein das
man gleich produktiv einsetzen kann.
Im Rahmen einer Diplomarbeit könnte dann aber eventuell etwas tolles
entstehen.
Hallo, auch wenn du erstmal keine Stored Procedures brauchst, würde
ich dir trotzdem
zu PostgreSQL/PostGIS raten. Du hast damit ca. 800 geo-spezifische
Funktionen
die du nicht mehr neu erfinden mußt und was die Admins kennen und was
getestet ist kommt halt aus gutem Grund auch schneller auf
die Server. Gerade die erste deiner Anwendungsideen lässt sich schon
jetzt mit PostGIS realisieren und das mit
viel weniger Overhead wie er durch den OSM-XML-Output entsteht.
Aufwändig für die DB ist es in einem minlat, minlng, maxlat, maxlng
Bereich (bounds) Daten zu finden.
Noch schwieriger ist es Pfade zu erkennen die diesen Bereich nur
tangieren und keine Punkte in diesem
Bereich haben.
Soweit ich das gesehen habe, ist PostGIS eher eine HighLevel Sache die
dabei nicht helfen kann.
Für die XAPI braucht es kein postGIS - ich hab aber ehrlich gesagt keine
Ahnung von postGIS.
War es nicht mal angedacht, von dem Mapnik-DB-Layout ausgehend, bei
Wegen und Flächen nicht nur die Listen von Längen- und
Breitengraden zu hinterlegen, sondern auch eine Liste von Node-IDs mit
in eine zusätzliche Spalte zu schreiben?
Über diese Node-ID-Liste müßte sich doch mehr oder weniger schnell,
weil die ID's ja indiziert sind, ein XML-File erstellen lassen,
was dem Xapi-Output zumindest nahe kommt. Das ganze ggf. unterstützt
durch Funktionen in der Datenbank.
Die Node IDs sind easy, das ist sicher kein Problem und mit einem super
simplen index zu lösen. Das kann jede DB.
Was ich noch angedacht habe ist eine verlustbehaftete Komprimierung.
Wenn man z.B alle Autobahnen per Vektordaten auf eine Europakarte
bringen will, dann gibt es viel
zu viele Details.
Wenn auf einer Europakarte die Autobahnen darstellen werden sollen, dann
wäre es komplett egal wenn man jeden zweiten node einer Autobahn
auslassen würde. Es wäre auch egal wenn man jeden 2^x ten Punkt
weglassen würde, wobei das x variabel sein soll.
Die Vorgaben für mein Lehrveranstaltung sind:
Ruby, git, http/xml Schnittstelle (optional json), Datenbankanbindung
wobei die Studenten lernen sollen, dass eine high level Schnittstelle
(xapi) ermöglicht die DB Lösung zu opimieren ohne die Schnittstelle zu
ändern.
Stored procedures, trigger ... sind nicht teil der LV aber natürlich
auch nicht verboten.
Im Moment weiss ich nicht welche Datenbank den besten Index für Geodaten
hat (hash, btree,...).
Wenn ich mir OSM technisch anschaue, dann schaut es so aus als wären
hier ein paar wirklich klug Leut am Werk.
Im Moment bin ich am Wein trinken und überleg mir was bei der LV
rauskommen soll.
Möglichkeiten wären:
- OSMOSIS verbessern,
- Komprimierung,
- Speed
Jeder input ist willkommen.
lg, Bernhard
Grüße Kolossos
bernhard zwischenbrugger schrieb:
Am 03.09.10 20:59, schrieb Lars Francke:
Ich kann schlicht und einfach nicht arbeiten wenn die XAPI tot ist.
Wenn ich das richtig verstanden habe ist dei XAPI in einer
Programmiersprache geschrieben, die außer dem Author der XAPI niemand
spricht.
Die Programmiersprache ist Erlang und als db wird die couchdb
verwendet.
Ähem...nein.
Die Programmiersprache ist MUMPS[1] und die Datenbank ist GT.M[2]
Oops. Das hab ich vor ein paar Tagen gerade nachgeschaut - naja der
Kalk rieselt ;-)
10.000.000 items sind aber ca. 1 GByte und das aus einer DB zu
laden ist
nicht wirklich sinnvoll.
Kommt ganz auf die DB und das Schema an. Es gibt heutzutage eine ganze
Menge Produkte für die das relativ einfach ist und die auf solche
streamenden Sachen vernünftig antworten können.
Was gibt es da?
Ich will in den nächsten Wochen so ein DB mit XML Schnittstelle
aufbauen.
Für ein XAPI ähnliches System braucht ich keine Trigger, Stored
Procedures, Rollback,...
Was bietet sich da an?
lg, Bernhard
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
