ich habe mich die letzten Tage daran versucht das pbf-format OL-tauglich zu machen. Leider mit wenig Erfolg…
Als Ansatz habe ich die proto-files aus dem “application-generic part” (https://github.com/scrosby/OSM-binary) genommen. Als “Decompiler” wollte ich das protobuf-js verwenden (http://code.google.com/p/protobuf-js/).
Nur bekomme ich dabei immer den Fehler, dass er den “Tag” nicht kennt. D.h. egal mit welcher Block-Definition ich es auch versuche. Vl. verstehe ich ja auch nur den Aufbau des Dateiformates nicht richtig…
Hat sich jemand von Euch schon mal daran versucht eine OL-Format-Definition für pbf zu entwickeln?
Oder vl. hat ja wer zumindest einen Ansatz für mich
Hi, also ich bin mir nicht sicher ob PBF unbedingt das richtige Dateiformat für JavaScript ist, da es (meiner Meinung nach) doch recht leistungshungrig ist und seine Vorteile aufgrund der geringen Datenmengen, die mit OL in Browsern darstellbar sind, auch nicht ausspielen kann. Was spricht denn gegen JSON?
für pbf würde einfach die einfache Datenextrahierung mittels osmosi aus einem osm-xml oder osm-pbf sprechen.
Gegen json spricht (für mich im Moment) das Problem, dass ich noch keine vernünftige Möglichkeit bzw. Tool gefunden habe aus einem osm-file das entsprechende geojson-objekt heraus zu bringen.
Und ich will mir das Datenbank-Backend mittels PostGIS sparen.
Hintergrund der ganzen Angelegenheit:
Aus einem Planet-Extrakt werden mit Hilfe von osmosis bestimmte POIs (z.B. Campingplätze) für eine bestimmte Region extrahiert. Das resultierende File wird dann - mit entsprechndem “Regionsnamen” - als Datei am Server hinterlegt.
Wenn nun der entsprechende Layer in OL geladen wird, soll der Server aus dieser vorbereiteten Regions-POI-Datei die angezeigte bbox extrahieren und an den Browser liefern.
Das Konzept funktioniert soweit auch ganz gut und ich gehe im Moment den Weg über mod_deflate um die transportierten Datenmengen zu reduzieren.
Fazit:
Wenn es einen einfachen Weg gibt um aus dem osm-file ein geojson-objekt heraus zu bringen wäre das natürlich eine durchaus interessante Variante.
Das soll aber eben zumindest vorerst mal ohne den Umweg über eine Datenbank laufen, weil ich nur für ein paar pois nicht gleich ein komplettes postgis-backend aufstellen will.
Und deswegen wollte ich das eben mal über pbf probieren, weil eben die datenmenge klein ist und sich die Daten mittels osmosis schnell verarbeiten lassen (um einiges schneller als die xml-daten). Dann wäre natürlich die pbf-performance auf dem client mittels js interessant.
Du solltest dir ganz dringend überlegen wo du die Performance brauchst.
So wie ich dich verstanden habe geht es dir darum die Daten schnell und einfach aufzubereiten. Du könntest also das pbf Format runter laden und mittels osmosis in ein xml der gewünschten POIs verwandeln. Es ist ja nicht erforderlich wieder ein pbf zu schreiben.
Das Problem ist etwa so als wenn du eine Textdatei im Internet bereits stellen willst und um die Downloadzeit zu verkürzen das Ganze als Zip und dann nochmal Rar verpackst. Jetzt musst du einfach schauen ob die kürzere Downloadzeit die Zeit des Entpackens aufwiegt.
Aber wenn es nur um Campingplätze geht, dann würde ich dir eher Lösungen wie die von netzwolf.info nahe legen. Er verabeitet die Daten mittels php zu CSV Dateien, welche auch eine Menge Einträge haben. Dennoch bauen sich die Karten ganz annehmbar auf denke ich. Schneller wird es sicher nur wenn du die Bereiche kleiner machst.
Ob das mit der Datenbank so schwierig ist, weiß ich nicht. Denn die Datenbank ist immer noch das einfachere als die daraus resultierende Anwendung. Mittels Osmosis kannst du dann auch die gefilterten Daten dort einlesen und läßt dir via Openlayers die BBox liefern und ließt dann aus der Datenbank nur den angezeigten Bereich aus. Mehr sparen kann man dann eigentlich nicht mehr.
die variante “pbf lesen” > “xml ausgeben” ist eh genau der weg den ich im Moment gehe. Und durch die Verwendung von mod_deflate halten sich - zumindest derzeit - auch die Datenmengen noch in Grenzen.
Vl. wird auch irgendwann das DB-Backend aufgebaut, aber damit habe ich mich einfach noch nicht (genug) beschäftigt - also was PostGIS im speziellen angeht. DB’s sind ja jetzt nicht prinzipiell das Problem
Es hat mich ja eigentlich einfach mal prinzipiell interessiert. Habe da ja auch noch nicht wochenlang meine Freizeit dafür investiert.
Die Idee mit dem CSV ist nicht schlecht. Werde ich mir auch mal ansehen.
Muss aber auch dazu sagen, dass ich mit OL erst vor Kurzem begonnen habe und da sicher noch einiges an “Entwicklungszeit” investieren werde, bis das so lauft, wie ich mir das vorstelle. gg
War aber auf alle Fälle ein interessanter Ideenaustausch, der hoffentlich noch weiter geht
So long…
Also mir sind auch nur CSV, JSON oder KML Ansätze bekannt. Wenn es wirklich zuviele Objekte werden, ist eine DB wirklich eine bessere Lösung. Da hast du einen zentralen Punkt den du nur aktualisieren und ggF. umbauen musst.
moin moin,
ich kann hier aus eigener Erfahrung den Kollegen nur zustimmen. Eine “eigene” DB ist Gold wert.
Kein Stress mit der API, Daten sind ständig aktuell und man ist flexibel.
Nur den Vorschlag “Mittels Osmosis kannst du dann auch die gefilterten Daten dort einlesen…” würde ich nicht in Erwägung ziehen.
Definiere dein Interessensgebiet (Gegend), benutze eine etwas grössere BBOX oder ein etwas grösseres Polygon und lade dann mit Osmosis alle Daten rein - nicht da schon filtern.
Dadurch bleibst du flexibel und kannst schon mal ganz was anderes machen, ohne gleich die DB neu aufsetzen zu müssen.
Postgresql bietet genug Möglichkeiten an um Abfragen zu optimieren.
Natürlich ist man flexibler, aber es muss auch eine Kosten Nutzen Abwägung getroffen werden. Wenn er jetzt für ganz Europa die Campingplätze sucht, halte ich eine Datenbank mit allen Daten von Europa für sehr übertrieben. Außerdem gibt es ja auch noch Speicherprobleme, wenn man den Server wirklich irgendwo hosten lassen möchte und nicht auf seinem Privatrechner irgendwie spielt.
Das ganze soll irgendwann auf einem virtual-server laufen (den server gibt es bereits, denn dort lauft schon meine homepage )
Ist im prinzip auch jetzt schon dort, aber in einer “development-umgebung” und nicht auf dem produktiv-system-bereich.
DB-System ist prinzipiell ja auch vohanden (via MySQL) aber eben noch nicht für GIS-Anwendungen bzw. OSM-Daten vorbereitet (DB-Schema, etc.)
Der Speicherplatz ist so eine Sache… gg
Das ganze System wird voraussichtlich mal irgendwann auf die DB umschwenken, aber ich will eine “Baustelle” nach der anderen bearbeiten und mir nicht 5 parallel aufreißen
Es wird daher vorerst mal bei der osmosis-lösung mittels “pbf lesen” > “xml liefern” bleiben, da vorher mal das ganze OL mal so laufen soll, wie ich das haben will.
Die Daten werden sowieso per bbox-strategy dynamisch aus einem php-skript geladen (das im Moment eben die osmosis-ausgabe liefert). Das kann dann später an eine entsprechende andere Datenquelle (DB) angepasst werden.
P.S. die Campingplätze waren ein Beispiel, weil das ganze eben für unsere Reiseberichte dienen soll. Und der nächste anstehende Urlaub wird eben ein Camping-Urlaub ^^
Was ich aber sicher nicht brauchen werde sind Straßen, etc. da es sich rein um POI-Layer handeln wird.
mysql ist keine gute Wahl. Es sind bisher mehrere Versuche gescheitert, ein GIS-System auf mysql aufzusetzen.
wir sprechen uns nächstes Jahr wieder
Wenn du aber wirklich nur alle Campingplätze als POI darstellen willst (da gab es doch ein Projekt letztes Jahr wo jemand mehrere 1000 pois spenden wollte?), dann brauchst du noch nicht mal ne DB.
Gruss
Walter
Das ist schon mal eine wichtige Info!
Aber da es sich ja um einen vserver handelt, kann ich prinzipiell problemlos eine postgre-db zusätzlich aufbauen. Aber das hat ohnehin noch Zeit.
lach
Wie gesagt, habe ich mit der Kartendarstellung was bestimmtes vor (Infos zu unseren Reisen und Wanderungen). Dazu benötige ich eben einerseits ein paar POI-Sets und andererseits die Darstellung von gpx-tracks (das funzt mit den entsprechenden gpx-dateien auch schon problemlos)
Genau deswegen werde ich es eben daweil auch mit dem DB-Backend bleiben lassen
