Bild1 code wie in Zeile 30
im Bild 2 hab ich das " --complex-ways --complete-ways " aus den Code genommen
gruss
Ah, okay, jetzt verstehe ich. Das Programm wirft halt die Punkte ausserhalb des Polygons weg, daduch bleiben teils lange gerade Linien stehen.
Also unten ist besser.
Die Artefakte könnte man vielleicht mit einem sehr kleinen -maxwaynodes Wert in srtm2osm (z.B. 2) deutlich verringern, aber letzlich hättest Du dann immer noch die großen Wald-Polygone oder andere längere Linien, die aus dem Polygon “rausragen”.
Stört es Dich nur optisch oder entstehen dadurch irgendwelche anderen Probleme?
es geht wirklich nur um die Optik und um die Technik wie das bewerkstelligt werden könnte das alles sauber am Polygon zurechtgeschnitten wird !
mit meiner Excel Oberfläche , die hast ja bestimmt auch schon gesehen , kann definiert werden ob nach Koordinaten , nach Polygonen oder ob eine Karte ohne ausschneiden also aus den Kompletten Rohdaten erstellt werden soll . Und das sollte halt so perfekt wie möglich sein .
gruss
was ich vielleicht noch erwähnen sollte , diese wirren Höhenlinien sind nicht überall so , an manchen Stellen der erzeugten Karte werden die genau am Polygon sauber geschnitten !
gruss
Hi,
ich sehe den Link nicht, sondern nur
bitte schreib vor und hinter dem Image-Link die dafür vorgesehenen Tags
(img) … (/img) Klammern durch eckige Klammern ersetzen, da die Forensoftware beim normalem Posten nicht mitspielt.
siehe https://forum.openstreetmap.org/help.php#img
Gruss
walter
ps: mein Image ohne IMG-Tags https://wambachers-osm.website/images/osm/snaps_2019/tn_img_link.png
Hab ich , so steht es im Beitrag und so hab ich es auch verfasst die Bilder sind auch zu sehen .
gruss
Hallo Wambacher,
jetzt bin ich irritiert. Ich habe immer nur die eingebettete Variante gesehen und sehe auch jetzt die img drum rum?
Bei mir werden die Bilder automatisch geöffnet und im Beitrag angezeigt!
auch das was ich jetzt einstelle hat die Tags
gruss
nö
@hakuch: Könnte das ein Bug der Forensoftware sein?
Shame on me: FF Plugin Ghostery funkt dazwischen. 
Sorry für die unnötige Verwirrung, muttu aber erst mal drauf kommen.
Gruss
walter
ps: Mail schon gelesen? Antwort bitte auch privat.
Ich seh die in Klammergesetzte img nur im Edit Modus da die Bilder ja automatisch geöffnet werden .
also ich hab das so im Beitrag geschrieben .
die Punkte stehen für den Pfad zu den Bildern der zwischen den img steht, so wie im Beitrag 40!
gruss
mea culpa. “Ghostery Tracking Filter” siehe oben.
hab bis jetzt keine Mail erhalt !
Ich hab mir mal selbst eine geschickt die ist angekommen !
gruss
Ich möchte nochmal das Thema zum Erzeugen einer voll funktionierenden osmconvert64.exe für Windows64 aufgreifen
Ich hatte das gleiche Problem mit der Alps-latest.osm.pbf (2,532 GB) unter Windows10 64-Bit
beim Ausschnitt erzeugen mit Option --complete-multipolygons
Fehlermeldung : Osmconvert Error could not rewind file
oder Ergebnisdatei nur 205 Bytes groß bei kleinerer Eingangsdatei: italy-nord-est-latest.osm.pbf (486,8 MB)
beim Ausschnitt erzeugen mit Option --complete-multipolygons
Grund für --complete-multipolygons: z.B. Gardasee Nord ergibt ohne die Option weissen See wenn der abgeschnitten
wird oder auch andere weisse Flächen/Gebirge beim Kartenerzeugen wenn Polygone nicht geschlossen sind.
Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 64 bit (see Limitations)” funktioniert also in vielen Fällen nicht.
----- weitere Tests von mir ---------
Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 32 bit” funktioniert überhaupt nicht mit Windows10 64-bit. 16GB Memory
Die auf der Osmconvert-Wiki Seite verlinkte Version “binary for Windows 32 bit” funktioniert überhaupt nicht mit Windows7 32-bit. 4GB Memory
osmconvert Error: PBF write: not enough memory
Source Dateien Alps-latest.osm.pbf(2,532 GB) und alps_tirol_obb_mid.pbf(132 MB) mit und ohne Option --complete-multipolygons
Unter Linux64 funktioniert die auf der Osmconvert-Wiki Seite verlinkte 64-bit Linux Version einwandfrei.
Unter Linux64 und Linux32 funktioniert die auf der Osmconvert-Wiki Seite verlinkte 32-bit Linux Version einwandfrei.
Lange Inet-Recherchen zu diesem Thema ergaben folgenden Sachverhalt:
Unter Linux64 erfolgt die Source-File Compilierung von osmconvert.h + zlib automatisch mit voller 64-Bit Unterstützung auch für File-Adressvektoren
Für Windows egal ob 32-Bit oder 64-Bit werden bei der Compilierung automatisch immer 32-Bit für File-Adressvektoren benutzt (aktuelle zlib für Windows)
(-> Limit 2,147 GB bei 512Bytes/Sector Festplattenformatierung), 64-Bit File-Adressvektoren erfordern spezielle Maßnahmen.
Die Angaben dazu auf der Osmconvert-Wiki Seite zum LargeFileSupport sind durchaus richtig aber leider nicht selbsterklärend zum selbst compilieren des Source-Codes.
Daher hier eine Kurzanleitung wie ich unter Linux64 mit dem Cross-compiler System MinGW-w64 erfolgreich ein voll funktionierendes Windows Executable erzeugt habe.
(viele der Compiler-Optionen stammen aus langem Ausprobieren mit Inet-Recherchen)
Alle Meine Compile-Versuche wurden mit folgendem Linux-System gemacht (da ich unter Windows keinen Compiler eingerichtet habe):
Compile System : Ubuntu 18.04 bionic (x86-64)
komplett Installation von MinGW-w64 (Version 5.0.3-1)
(Cross-compiler für Windows z.B. gcc-mingw-w64 ver.7.3.0-11 ) ;
z.B. mit Synaptic-Paketverwaltung nach mingw suchen → alles installieren!
Download zlib sourcecode von https://sourceforge.net/projects/libpng/files/zlib/1.2.11/ :
https://sourceforge.net/projects/libpng/files/zlib/1.2.11/zlib-1.2.11.tar.gz/download
entpacken in neues Verzeichnis z.B. zlib1211
Download osmconvert sourcecode von http://m.m.i24.cc/osmconvert.c
kopieren auch ins Verzeichnis zlib1211
Command-Shell in Verzeichnis zlib1211 öffnen
Dort folgende Komandos ausführen (ohne die Kommentare → !):
→ sorgt für z_off64_t = __int64 in der config Datei zconf.h.in
sed -i "s,define z_off64_t off64_t,define z_off64_t __int64," zconf.h.in
→ sorgt für z_off64_t = __int64 in der config Datei zconf.h.in
sed -i "s,define z_off64_t z_off_t,define z_off64_t __int64," zconf.h.in
→ versetzt Verzeichnis in Ursprungszustand für Neukompilierung
make distclean
→ versetzt Verzeichnis in Ursprungszustand für Neukompilierung
make clean -f win32/Makefile.gcc
→ konfiguriert zum Compilieren für Windows64
CHOST=x86_64-w64-mingw32 ./configure --static
→ compiliert zlib neu für Windows64 mit 64-Bit File-Adressing
make -f win32/Makefile.gcc CC=x86_64-w64-mingw32-gcc RC=x86_64-w64-mingw32-windres IMPLIB=libz.dll.a CFLAGS="-O2 -s -pipe -D_LFS64_LARGEFILE=1 -D_LARGEFILE64_SOURCE=1 --param=ssp-buffer-size=4"
→ compiliert osmconvert für Windows64 mit neuer zlib und Optimierung-Stufe (-O2) und ohne Debugging Symbols (-s)
x86_64-w64-mingw32-gcc osmconvert.c -static ./libz.a -O2 -s -o osmconvert64_lfs.exe
→ erzeugt wird folgendes Windows Executable: osmconvert64_lfs.exe
DOS/Windows-Programmdatei (application/x-ms-dos-executable) 222,2 kB (222208 Bytes)
http://www.muenchen-surf.de/rohyman/osmconvert/osmconvert64_lfs.exe
Es wäre super wenn jemand das File mit seinen osmconvert Optionen testen könnte und bei Erfolg ins Osmconvert-Wiki verlinkt.
Eine funktionierende Version für Windows32 mit LargeFileSupport oder für die problematischen Optionen --complete-multipolygons etc. ist mir bisher nicht gelungen
Ob die auf der Osmconvert-Wiki Seite (binary for Windows 64 bit (with large file support)) verlinkte Version
https://yadi.sk/d/Vnwc4kut3LCBFm → osmconvert64-0.8.8p.exe vertrauenswürdig ist weiss ich auch nicht, Virenscan ist nicht alles!
Wie kann es sein daß ein nicht OSM registrierter User einen Link auf externe Dateien auf der Osmconvert-Wiki Seite erzeugt?
Auf jeden Fall ist die dort verlinkte osmconvert64-0.8.8p.exe wesentlich grösser : 312,0 kB (311997 Bytes)
und erzeugt auch immer grössere Ergebnisdateien als meine bei gleichen osmconvert Optionen???
Ich habe auf jeden Fall keine Compileroption gefunden die eine gleiche Dateigrösse erzeugt.
Hallo zusammen,
ich möchte dieses Thema einmal aufwärmen und dabei auch gleich die Frage im letzten Post einigermaßen beantworten.
Ich habe auf Windows 10 mingw von nuwen (https://nuwen.net/mingw.html) und ein msys installiert.
Damit habe ich eine eigene zlib mit 64-bit Filesupport und 64-bit Fileoffset kompiliert und damit ein eigenes osmconvert64 gebaut.
Nun habe ich vier Versionen gegeneinander antreten lassen:
osmconvert64-0.8.8p - das legendäre Kompilat seltsamer Herkunft
osmconvert_mingw - mein eigenes Kompilat
osmconvert64_lfs - das Kompilat aus dem obigen Post
osmconvert64 - das fehlerhafte 64-bit-Kompilat aus dem Wiki
Hier das Ergebnis:
E:\CreateIMG>osmconvert64-0.8.8p -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 662 dependencies.
Interrelational hierarchy 2: 63 dependencies.
Interrelational hierarchy 3: 7 dependencies.
Interrelational hierarchy 4: 1 dependencies.
Interrelational hierarchy 5: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 4 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>osmconvert_mingw -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_mingw.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 41 dependencies.
Interrelational hierarchy 2: 1 dependencies.
Interrelational hierarchy 3: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 2 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>osmconvert64_lfs -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_lfs.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 41 dependencies.
Interrelational hierarchy 2: 1 dependencies.
Interrelational hierarchy 3: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 2 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>osmconvert64 -b=8.39,52.8,8.5,53 --complete-ways -o=OSM-Data\extract_64.o5m OSM-Data\germany+jordan.o5m -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
osmconvert Warning: unexpected end of input file: OSM-Data\germany+jordan.o5m
E:\CreateIMG>
Schon in der Ausgabe der unterschiedlichen Kompilate kann man sehen, daß da unter der Haube etwas anders läuft. Das legendäre Kompilat ist deutlich “redseliger”.
Hier die erzeugten Ausgabedateien:
02.05.2021 12:52 9.008.195 extract.o5m
02.05.2021 12:56 2.467.191 extract_mingw.o5m
02.05.2021 13:00 2.467.191 extract_lfs.o5m
02.05.2021 13:02 35 extract_64.o5m
02.05.2021 02:42 5.881.000.652 germany+jordan.o5m
Interessanterweise funktionieren sowohl mein eigenes, als auch das Kompilat aus dem vorigen Post anscheinend einwandfrei und erzeugen auch exakt das gleiche Ergebnis. Leider sind ihre Ergebnisse aber deutlich kleiner als das Ergebnis des legendären Kompilats. Was macht diese 0.8.8p-Version anders?
Außerdem kann man auch gut das Scheitern der fehlerhaften 64-bit-Version von der Wiki-Seite sehen.
Hat sonst noch Jemand eine Idee oder weiß irgendwelche “geheimen” Zutaten, die ich eventuell vergessen habe?
Weitere interessante Beobachtung:
Ich schneide aus einem großen Datensatz einen identischen Ausschnitt, einmal mit meinem Kompilat und einmal mit mit der 0.8.8p-Version.
E:\CreateIMG>osmconvert_mingw.exe --drop-version "OSM-Data\germany+jordan.o5m" -o="OSM-Data\germany.o5m" -B=germany.poly -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 13896 dependencies.
Interrelational hierarchy 2: 72 dependencies.
Interrelational hierarchy 3: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 2 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>osmconvert64-0.8.8p.exe --drop-version "OSM-Data\germany+jordan.o5m" -o="OSM-Data\germany_.o5m" -B=germany.poly -v
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Interrelational hierarchy 1: 49261 dependencies.
Interrelational hierarchy 2: 231 dependencies.
Interrelational hierarchy 3: 2 dependencies.
Interrelational hierarchy 4: 0 dependencies.
osmconvert: File timestamp: 2021-05-02T00:00:00Z
Relation hierarchies: 3 of maximal 12.
osmconvert: Last processed: relation 12657386.
E:\CreateIMG>
Mit ziemlich unterschiedlichen Ergebnissen, das Ergebnis von 0.8.8p ist wesentlich größer:
02.05.2021 13:44 5.003.327.237 germany.o5m
02.05.2021 13:49 5.837.020.484 germany_.o5m
02.05.2021 02:42 5.881.000.652 germany+jordan.o5m
Speziell die “Interrelational hierarchy”-Ausgabe ist deutlich anders, eine ganze Ebene mehr! 
Welches Ergebnis stimmt denn?
Ich mache aus den Ergebnisse danach mit mkgmap Garmin-Images, wobei ich interessanterweise nichts Fehlendes bemerke.
Das irritiert mich ja so. Ich mache jede Nacht kumulative Updates mit osmconvert und befürchte, irgendwelche Daten zu verlieren, wenn ich nicht 0.8.8p verwende. Andererseits bläst sich der Datensatz immer mehr auf. Außerdem hätte ich gerne eine funktionierende neuere Version als 0.8.8.
BTW: Bist Du der Gerd aus der Mkgmap-Development-Mailliste? 
Jo.
Wenn Du mit dem Vergleich der Dateien nicht weiterkommst, dann kann ich das gerne machen.