-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
Meinungsmache: OSM + Urheberdaten
- Ersteller stoerti
- Erstellt am
OP
stoerti
Geowizard
Von Perl nutze ich 5.8 - von 6 halte ich noch nicht so viel.
SQLite ist eine Variante, die ich bedenke. Ich muss nur irgendwie den richtigen Cluster zusammenzimmern.
Das Problem ist ja, dass man mit tonnenweise Daten hantieren muss.
Belgien zB, hat mit einer osm-Datei Grösse von 241MB 1.6 Millionen Node-Tags
Deutschlands osm Datei hat 6600MB ....
SQLite ist eine Variante, die ich bedenke. Ich muss nur irgendwie den richtigen Cluster zusammenzimmern.
Das Problem ist ja, dass man mit tonnenweise Daten hantieren muss.
Belgien zB, hat mit einer osm-Datei Grösse von 241MB 1.6 Millionen Node-Tags
Deutschlands osm Datei hat 6600MB ....
OP
stoerti
Geowizard
Nö, das sind alles nur aktuelle Ist-Daten.
OSM Gesamt 115GB
Das auf SQLIte zu verteilen ist schon ne Aufgabe - allerdings eine schöne, man könnte das so richtig cool clustern, wenn man da nen schicken Cloud-Computing Mechanismus für baut, könnte man seine 30 PCs zu Hause endlich mal gescheit vernetzen und auch mal Last aufs Lan bringen
OSM Gesamt 115GB
Das auf SQLIte zu verteilen ist schon ne Aufgabe - allerdings eine schöne, man könnte das so richtig cool clustern, wenn man da nen schicken Cloud-Computing Mechanismus für baut, könnte man seine 30 PCs zu Hause endlich mal gescheit vernetzen und auch mal Last aufs Lan bringen
extremecarver1
Geocacher
Waere es dir moeglich von geofabrik.de oder einer andere Sekundaerquelle die Daten zu ziehen?
Wenn jeder anfaengt direkt die Rohdaten von OSM zu ziehen, ist es kein Wunder wenn die Server zusammenbrechen, vor allem wenn du dann meinst auch noch die ganze Welt haben zu wollen.
Die OSM Api ist nicht dazu gedacht dass man sich komplette Worldfiles oder sogar nur Country Files zieht. Genau dafuer gibt es Geofabrik und andere.
Dicken Server hab ich leider nicht. Wird alles lokal auf Tripplecore berechnet, aber Domainbox.de stellt mir fuer das anbieten der fertigen Garmin Dateien, eben Shared Webspace zur Verfuegung (bisher ohne Downloadlimit - was natuerlich privat bezahlt recht teuer waere - bei +100GB Downloads die taeglich zusammen kommen).
Die neusten mkgmap Versionen laufen eh wahnsinning schnell, viel Spaß mit Perl. germany.osm.bz2 braucht bei mir 8 Minuten fuer einen Durchlauf - da musst noch viel optimieren in Perl und scripten um was brauchbares zu bekommen. Der Quellcode von mkgmap ist ja offen, also bedien dich und stelle deine Scripts unter dieselbe Lizenz, wenn du wirklich sicher bist es machen zu wollen.
Besser faende ich persoenlich wenn du deine Ressourcen in die Weiterentwicklung von mkgmap stecken wuerdest, da gibts noch einiges zu tun und Java ist ja auch fast ueberall lauffaehig.
Getrickst wird natuerlich bei openmtbmap.org Karten ohne Ende um vernuenftige Ergebnisse zu bekommen.
Zum Urheberrecht, dachte ich bisher es reicht wenn man die Lizenz angibt und auf Openstreetmap.org and Contributors verweist. Sehen zumindest alle die zurzeit Garmin.img Karten anbieten, oder Server wie Opencyclemap und Co so.
Ein Unterschied waere es, wenn man die Daten anreichert oder veraendert. Zurzeit werden sie aber ja nur umgewandelt und selektiert.
Wenn jeder anfaengt direkt die Rohdaten von OSM zu ziehen, ist es kein Wunder wenn die Server zusammenbrechen, vor allem wenn du dann meinst auch noch die ganze Welt haben zu wollen.
Die OSM Api ist nicht dazu gedacht dass man sich komplette Worldfiles oder sogar nur Country Files zieht. Genau dafuer gibt es Geofabrik und andere.
Dicken Server hab ich leider nicht. Wird alles lokal auf Tripplecore berechnet, aber Domainbox.de stellt mir fuer das anbieten der fertigen Garmin Dateien, eben Shared Webspace zur Verfuegung (bisher ohne Downloadlimit - was natuerlich privat bezahlt recht teuer waere - bei +100GB Downloads die taeglich zusammen kommen).
Die neusten mkgmap Versionen laufen eh wahnsinning schnell, viel Spaß mit Perl. germany.osm.bz2 braucht bei mir 8 Minuten fuer einen Durchlauf - da musst noch viel optimieren in Perl und scripten um was brauchbares zu bekommen. Der Quellcode von mkgmap ist ja offen, also bedien dich und stelle deine Scripts unter dieselbe Lizenz, wenn du wirklich sicher bist es machen zu wollen.
Besser faende ich persoenlich wenn du deine Ressourcen in die Weiterentwicklung von mkgmap stecken wuerdest, da gibts noch einiges zu tun und Java ist ja auch fast ueberall lauffaehig.
Getrickst wird natuerlich bei openmtbmap.org Karten ohne Ende um vernuenftige Ergebnisse zu bekommen.
Zum Urheberrecht, dachte ich bisher es reicht wenn man die Lizenz angibt und auf Openstreetmap.org and Contributors verweist. Sehen zumindest alle die zurzeit Garmin.img Karten anbieten, oder Server wie Opencyclemap und Co so.
Ein Unterschied waere es, wenn man die Daten anreichert oder veraendert. Zurzeit werden sie aber ja nur umgewandelt und selektiert.
OP
stoerti
Geowizard
Du brauchst die .osm Daten (das XML File) - woher Du das ziehst, ist vollkommen egal
Ich bediene mich derzeit auch irgendwo anders als bei den Core-Servern
Das Worldfile gibts ja sogar im Filesharing
Genau das war meine Entscheidung, selbst was zu machen.
Nachdem ich tagelang versucht habe, eine Karte zu erstellen, haben wir festgestellt, dass die Quelldaten nichts taugten, weil die Nodes zwar drin standen aber keine way- und relation-tags.
Die Daten hatte ich mir von irgendeinem Tile-Server gezogen.
Ich hatte zu dem Zeitpunkt einfach die Schnauze voll.
In meinen Augen ist Java eine Krücke. Viel zu grosser Overhead.
Man kann sich drüber streiten, ist aber meine persönliche Meinung.
Ich entwickle auch kein Java - nein, meine Suppe ess ich nicht
Und umfassend kommt noch dazu, dass mich annervt, dass ich jedesmal, wenn ich ein Update der Daten fahren will, immer das komplette File ziehen muss. Bei germany.osm.bz2 zB über 400MB.
Ich benötige aber, weil ich sehr viel reise, Norwegen, Schweden, Dänemark, Deutschland, BeNeLux, Spanien. Damit könnte ich auch fast schon europa.osm.bz2 ziehen - mit 1200MB.
Wenn ich nur monatsaktuell sein will, habe ich schon ein Problem.
Jeden Monat 1.2 Gig Daten lutschen, nur weil sich vielleicht 50MB wirklich geändert haben?
Mit meiner Lösung kann ich mir das wöchentliche diff file mit einigen wenigen MB ziehen, jage mein Perlscript drüber und bin up to date.
Und was die 8 Minuten angeht...abwarten...ich bin ja noch beim pre-pre-alpha release 0.0.0
Ich habe es jetzt geschafft, einen kompletten Datenimport hinzubekommen, ohne dass Fehler auftreten.
Jetzt kommt diff dran.
Und dann gucken wir weiter.
OP
stoerti
Geowizard
Jetzt hab ich hier so rumgetönt von wegen Diff Files....wo sind n die?
Die letzten Diffs sind vom 18. April diesen Jahres und danach nichts mehr.....
Die letzten Diffs sind vom 18. April diesen Jahres und danach nichts mehr.....
Code:
[~/work/perl/OSM]$ perl OSM_Import.pl belgium.osm
2009 06 08 20:41:33 4.07% (159860 lines) finished
2009 06 08 20:42:33 40.43% (1588714 lines) finished
2009 06 08 20:42:53 100.00%
jennergruhle
Geoguru
Naja, Perl ist immer dann toll, wen man das tun will, wofür Perl gemacht wurde: Textdateien (im weiteren Sine, also auch z.B. XML) lesen, verarbeiten und schreiben. Solche Aufgaben erledige ich auch immer am liebsten mit Perl. Aber sobald man Binärdateien verarbeitet bzw. erzeugt oder irgendetwas tut, bei dem es nicht mehr egal ist, ob eine Variable nun den Wert Leerstring, 0, false oder "garnix" hat, wird es knifflig...hcy schrieb:BTW: Perl rulez, zumindest bis jetzt. Was da in der 6er Version auf uns zu kommt ...
Es taugt eben nicht jede Programmiersprache für jede Aufgabe.
Aber zum Glück wird einem ja nichts vorgeschrieben (es sei denn, man muss Programme für irgendwelche Dinosaurier-Hardware schreiben).
OP
stoerti
Geowizard
Ich hole das mal nach vorne, weil ich gestern ein Release gemacht habe.
http://www.reisenetzwerk.net/importosm2sqlite/
http://www.reisenetzwerk.net/importosm2sqlite/