Sehr schön.
Warum du allerdings gerade zu C# greifen möchtest und damit quasi .net vorraussetzt ist deine Entscheidung.
Schön ist auf jeden Fall was dabei herauskommt. Vielleicht solltest du perspektivisch auch daran denken das es veraltete Kacheln geben kann, bzw. das auch mehrere Kacheln in eine Warteschlange gestellt werden können. Solltest du mal Deutschland rendern wollen, magst du sicher nicht davor sitzen um alle 10 Minuten die nächste Kachel auszuwählen. Wäre also vielleicht ein schönes Fetuare.
…ganz einfach. Weil ich das ein wenig kann und für andere Dinge einsetze. Hintergedanke ist aber wenn was brauchbares rauskommt das Ergebnis dem MOBAC Autor zu präsentieren und das Ganze nach JAVA umzusetzen und in MOBAC zu integrieren. Hat sich in der Vergangenheit schon bewährt.
also diesen Schluß verstehe ich nun uberhaupt nicht. In Mobac kannst du ja viele,viele Kacheln selektieren (! das ist ja das Problem der Massendownloads) und die Zwischenlogik muß das vernünftig händeln. Eben wie ein Massendownload nur eben lokal. In Maperitive tut sich da ja auch was bezüglich der Rendergröße. Was die Aktualisierung angeht heißt das nichts anderes, wie von der Geofabrik im gewünschten Zeitraster die entsprechenden bpf’s runterzuladen.
Ich nutze das ausschließlich zur Planung von Wanderungen (Erstellung von geplanten GPX-Routen) und Darstellung meiner archivierten GPX-Routen… Deshalb sind auch die Nebenstrassen/tracks/Pfade so hervorgehoben (Schnitzel_03).
MfG
Achim
Hast du es mit dem MinGW-Komplettpaket versuch, das PA94 empfohlen hat?
http://forum.openstreetmap.org/viewtopic.php?pid=162140#p162140
http://nuwen.net/mingw.html
So klappts bei mir sogar mit dem Pseudo-Windows “Wine” unter Linux.
Natürlich habe ich das versucht:
F:\convert>gcc osmconvert.c
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x1e00): undefined reference to `gzdopen'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x1e19): undefined reference to `gzbuffer
'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x1e41): undefined reference to `gzopen'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x1e8c): undefined reference to `gzbuffer
'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x1f44): undefined reference to `gzclose'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x2070): undefined reference to `gzread'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x477f): undefined reference to `inflateI
nit_'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x47bb): undefined reference to `inflate'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x47d5): undefined reference to `inflateE
nd'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x47ee): undefined reference to `inflateE
nd'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x8d23): undefined reference to `deflateI
nit_'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x8d5f): undefined reference to `deflate'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x8d73): undefined reference to `deflateE
nd'
D:\Temp\ccKO5MDU.o:osmconvert.c:(.text+0x8d99): undefined reference to `deflateE
nd'
collect2: ld returned 1 exit status
So sah es auch damals aus.
Allerdings wenn ich wie in dem verlinkten Thread empfohlen das Übersetzen und das Linken trenne, dann bekomme ich ohne Fehlermeldung eine exe.
Die Ergebnisse möchte ich Euch nicht vorenthalten:
http://vkw.bplaced.net/osm/osmconvert_new.exe und
http://vkw.bplaced.net/osm/osmconvert.exe
Edit: wäre jemand so nett mir diese Dinge zu erläutern, damit ich sie verstehe? Und vielleicht auch Hinweise für eine 64Bit Version zu geben. Diese würde ich dann ebenfalls gerne übersetzen.
Bei mir klappts unter Linux und unter Windows nur, wenn ich die Bibliothek “zlib” per Option “-lz” mit angebe. Z.B. für Windows:
gcc osmconvert.c -lz -o osmconvert.exe
Mit der zusätzlichen Option “-O3” wird das Programm etwas schneller. Dafür dauert das Compilieren länger, und es kommen diverse Meldungen.
Hi
ich glaube ich habe noch ein Problem entdeckt. Wenn man mit MOBAC eine Kachelboundingbox selektiert und diese mit osmconvert ausschneidet steht zwar im Header
<?xml version='1.0' encoding='UTF-8'?> ...die ausgewählte Boundingboxparameter, aber wenn man in Maperitive die “set geo-bounds” ohne Parameter setzt, wird dort eine größere BoundingBox gesetzt. Wird wohl nach dem wirklichen Inhaltsdaten gesetzt und nicht vom Bounding Tag <bounds… Bei -complete-ways ist es noch mehr.
Man muss dann da die Bounds explizit setzen slso zB: set-geo-bounds 8.4375,48.74894556450047,8.525390289723873,48.80686346108517 so dass das mit MOBAC und den Tilegrenzen stimmt.
MFG
Achim
Klingt plausibel. Aber wertet Maperitive den Header gar nicht aus? Ist die Option wirklich notwendig?
Falls dem so ist, wäre das vielleicht einsinnvoller Ergänzungsvorschlag für Maperitive.
Du kannst mal versuchen, dem gc den Parameter
-m64
beim Compileren mitzugeben. Weiss allerdings nicht, ob bei Dir
die benötigten Bibliiotheken auch 64Bit-tig vorliegen.
Also mit der bei mir übersetzten Version sieht das Ergebnis unter winXP 32 Bit so aus:
F:\convert>osmconvert_new.exe -v=2 --complex-ways --out-pbf -b=8.7,49.75,9.75,50.5 G:\europe.osm.pbf > G:\Testplex.pbf
osmconvert Parameter: --complex-ways
osmconvert Parameter: --out-pbf
osmconvert Parameter: -b=8.7,49.75,9.75,50.5
osmconvert Parameter: G:\europe.osm.pbf
Read-opening: G:\europe.osm.pbf
Read-opening: increasing gzbuffer.
osmconvert: zlib 1.2.5 flags: 00000055
Write-opening: stdout
Tempfiles: osmconvert_tempfile.2332.*
osmconvert: changing dependencystage from 0 to 11.
osmconvert Error: could not jump in file: G:\europe.osm.pbf
osmconvert: Last processed: relation 1851916.
osmconvert Exit: 28
Read-closing: G:\europe.osm.pbf
Das Ergebnis ist 1KB groß. Vielleicht hilft das ja bei der Fehlersuche!
…habe ich schon angeregt. Dieses Problem besteht eben an den Schnittstellen wenn man viele Gebiete zu einer großen Gebiet zusammenfügt. Wenn man das explizit seitz kommt ne nahtlose plausible Karte raus. Leider kann man diese Parameter nicht bis ins Maperitive Script durchreichen. Deshalb werde ich mal ein “kleines” Zwischenprogramm dranhängen. Ansonsten sieht das gut aus.
MfG
Achim
Ps: So sieht jetzt die Schnittstelle der Wege zwischen 2 getrennt gerendererten Kacheln aus (mittlere schwache Linie). Je nach Zoomstufe wird der Text zB.:Kentheimer Berg nur halb dargestellt und an der Kachelgrenze abgeschnitten. So kann ich mit ner automatisierten Generierung beliebig große Karten generieren
Kachelgrenze (osmconvert mit --completeways) ==> http://augilabs.de/osm/bild/Schnitzel_04.png
so sieht dder abgeschnittene Text aus http://augilabs.de/osm/bild/Schnitzel_05.png aber mit dem kann ich leben…
@Markus: Nochmals vielen Dank für osmconvert!!!
Genau der Grund warum ich immer bis zu 0,3 Grad größere Bereiche ausschneide - da bekommt man eine perfekte Karte!.
Übrigens ohne --complex-ways gibts dabei immer noch Probleme mit den MP’s (fehlende Flächen) --complete-ways reicht da nur im ersten Guck !
Hi,
die 0.3 Grad größer ausschneiden bringt in diesem Fall nichts, da man genau die Kachelgrenzen einhalten muß um die “verschiedenen” Teilgebiete zu einer GANZEN Tilestruktur zusammenzubauen.
Mit dem größer Ausschneiden ist das aber ok, wenn man nur einen Ausschnitt betrachtet! Ich möchte aber ein große Map aus einzelnen Kacheln zusmmenbauen.
MfG
Achim
Falsch bein Ausschneiden muß ich nicht die Kachelgrenzen einhalten - sondern nur in Maperitive wenn ich das rendere
osmconvert --complex-ways --drop-version --drop-author --emulate-osmosis --out-pbf -b=8.237,48.722,10.044,50.038 G:\PBF\ausschnitt.pbf > “G:\PBF\8-8,44-9,84-48,9-49,8.pbf”
Schneidet eine Zoom 8 Kachel aus mit 0,2 Grad Rand
In Maperitive darft ich aber nur
set-geo-bounds 8.43751,48.92251,9.84374,49.83797
haben um nur die komplette Kachel zu bekommen.
Wenn ich das mit den Nachbarkacheln ganauso mache bekomme ich die Kacheln ohne Überganseffekte (abgeschnittener Text usw.).
Nur stellt sich das Problem das ich eine Batchdatei mit osmconvert-Auschnitt-aufruf und Maperitive-aufruf erstellen muß und auch noch das Script erstellen muß mit der genauen BBOX für die Kachel!
MOBAC übergibt ja “nur” die bbox und in der batch kann man nicht Gleitkomma rechnen.
Ich bastel mir grad ein MortScript zurecht das dies alles Erledigt - was ja nicht besonders Schwer ist da nur recht einfache Rechnungen und ein bischen schreiben in Datein gefordert ist.
Ich hatte nur gehofft das osmconvert die europe.pbf direkt schneiden kann - bevor ich da großes in das MortScript stecke und es dann doch ändern muß (sollte schon etwas flexibel sein!)!
Hallo und erstmal danke fürs Danke sagen. 
Braucht ihr aber nicht, mir macht es ja Spaß. Jeder von uns leistet seinen Beitrag zum Kuchen “OSM”, einer programmiert, andere generieren super Karten und viele Mappen einen Quadratkilometer nach dem anderen.
Vielleicht kriegst du das auch per Integer-Berechnung hin. osmconvert rechnet inter ja auch (fast) nirgends mit Fließkommazahlen, sondern nur mit Festkommazahlen. 49 Grad nördliche Breite werden intern als 490000000 gespeichert. Das PBF-Format macht das übrigens auch so.
Also… man könnte den Dezimalpunkt irgendwie rauswerfen und wenn man ihn dann braucht, wieder einfügen. Das bedeutet natürlich einiges an geschickter Stringmanipulation, aber dafür sollten die Windows-Bordmittel reichen.
das ist richtig, aber dann wird doch beim rendern in einigen Zoomstufen der Text an der Kachelgrenze halbiert (aber noch nicht verifiziert). Aber es gibt da wohl ein neues Feature in Maperitive laut Igor
…aber die Syntax ist mir noch nicht klar. http://groups.google.com/group/maperitive/browse_thread/thread/3cece3f792687317
Das mit dem generieren der Batchfiles ist aber auch kein Problem via C#. Das werde ich machen so bald die Randbedingungen klar sind.
MfG
Achim
Jepp und wo ist da das Problem!
In der später gerenderten Nachbarkachel tauch durch den Rand ja der Text der über die Kachelgrenzen geht ja auch auf und das fehlende wird ergänzt!
- währe auch schlimm wenn ich die Nachbarkachel rendere und Maperiative verschieb den Text weil an Kachelgrenzen (set-geo-bounds ) gelegen!
Klappt bei mir recht gut nur Ludwighafen und Mannhein ist da ein Problem zwischen Zoom 8 und 11 je nach Zoomstufe kommt mal Ludwigshafen oder Mannheim und das in der jewiligen Kachel verschieden.
Wo ist eigentlich der Unterschied zwischen gcc und g++ Es sind beide Dateien vorhanden aber haben eine unterschiedliche Größe.
Tja, es gibt C und C++.
Und was gehört zu wem 
Der Versuch wird mit
F:\convert>gcc -c -m64 osmconvert_new.c
osmconvert_new.c:1:0: sorry, unimplemented: 64-bit mode not compiled in
abgebrochen. Jetzt ist die Frage ob das am Quellcode liegt (hier sind die Windows Ausnahmen ja immer mit win32 ausgeführt) oder aber am gcc compiler oder gar den Bibliotheken.
Ok wenn du so sagst, dann soll es so sein. Osmconvert ist also in c geschrieben. Da g++ immer auf Fehler hinweist.
Inzwischen hatte ich auch noch andere Erklärungen gefunden. gcc sei für alle Sprachen zuständig. Auch Java und Fortran. Allerdings hat mich verwundert das g++ den Virenscanner herausfordert und außerdem noch mit 4 Fehlern abbricht.