Frederik Ramm schrieb: > Hallo, > > Josias Polchau wrote: >> wenn ich es richtig verstanden hab geht es also um das schnelle >> Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? > > Ja. Erschwerend kommt hinzu, dass wir fuer sehr viele Anwendungen diese > Informationen im topologisch sauberen OSM-Modell ausliefern wollen und > *nicht* in Form von Standardgeometrien. Das heisst, wir wollen schoen > ordentlich alle betroffenen Nodes, Ways und Relations haben und nicht > einfach eine in die Landschaft gezeichnete Linie. > > Auf letzteres sind die einschlaegigen Geodatenbanken aber in der Regel > spezialisiert. > > In der API sieht eine typische "gib mir alles in diesem Bereich"-Anfrage > so aus: > [..] das ist die geo-Herangehensweise. eine weitere nötige Operation ist das Finden aller Knoten mit dem Tag XY und natürlich auch anders herum
Wenn sowohl das Gebiet (ist ja meist der fall) als auch die tags eingeschränkt sind müsste das Programm so intelligent sein, heraus zu finden, welches der beiden die Auswahl am meisten einschränkt... also zb bei den Babyklappen in Deutschland sollte das prog natürlich erst mal alle Babyklappen suchen und erst später regional einschränken. http://osm.youseeus.de/osmolt/babyklappe/deutschland/ Bei Straßen würde man natürlich zuerst nach Gebiet einschränken. > Insgesamt ist das halt eine nicht ganz primitive Operation. > >> also eine Weiterentwicklung der XAPI? > > Oder eine Weiterentwicklung der API, koennte man genauso sagen. > >> die XAPI wurde von 80n entwickelt >> > Xapi source code uses GT.M a high-performance schemaless database. >> >> warum wurde keine geo DB genommen? > > Erstens ist eine "geo DB" nicht unbedingt besser (s.o.), zweitens gilt > bei OSM ja "wer das Programm schreibt, darf entscheiden", und 80n hat > sich fuer M entschieden, eine Datenbankprogrammiersprache aus dem > medizinischen Bereich, die deutlich aelter als SQL ist. älter ist ja nicht immer besser (bei Informatik eher andersrum ^^) > Die Programmiersprache ist dann egal, wenn genuegend Leute die gewaehlte > Sprache gut beherrschen *oder* der Programmierer auf absehbare Zeit > willens und in der Lage ist, jede Anpassung und sonstige Arbeit am Code > selbst vorzunehmen. MUMPS ist ja wirklich schwer zu lesen, und ich weiß nicht, ob sich wirklich später jemand findet den code zu warten. ^^ > Beim XAPI haben wir zum Beispiel genau das Problem - es gibt Engpaesse, > aber es gibt auf der ganzen Welt nur eine Person, die sich mit dem > Einsatz der Programmiersprache M speziell fuer OSM-Daten beschaeftigt > hat. Das ist knapp. ich würd ja Java vorschlagen, weil ich das sehr gut kann, und C++ nicht wirklich mag Skripsprachen scheinen mir nicht effizient genug (ich weiß Java auch nicht.) _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
