User talk:Panarchos

From OpenStreetMap Wiki
Jump to: navigation, search

phyghtmap and OSM v0.6 format

2011-09-17 -- Warum schreibt phyghtmap die OSM Daten per default im v0.5 Format? Es gibt eigentlich kein Tool mehr, was das einlesen kann, so das man immer mühselig konvertieren muß. Kann phyghtmap nicht gleich das v0.6 Format schreiben? Ausser der Versionsnummer müssen bei den Nodes und Ways nur noch die Attribute "version" sowie "timestamp" hinzugefügt werden. Ich würde ja gerne selber einen Patch machen, aber durch den Python Code steige ich noch nicht so ganz durch. Ansonsten gefällt es mir bisher sehr viel besser als Srtm2Osm, vor allem wegen den sehr viel geringeren Speicherbedarf. [kukuk]

Ich habe phyghtmap v0.6 beigebracht (bekommt man mit --osm-version=0.6). 0.5 würde ich gerne deswegen als default behalten, weil es Plattenplatz spart und zum Rechnen von Garmin-Images mit mkgmap ausreicht. Ich mache ansonsten nicht viel mit den Höhenlinien -- wozu verwendet Ihr sie noch?
Soweit ich das sehe, ist das "timestamp"-Attribut nicht zwingend, nur das "version"-Attribut ist ein Design-Feature von Version 0.6 der OSM-API. Bitte korrigiert mich, wenn ich das falsch sehe. --Panarchos 12:58, 12 December 2011 (UTC)


phyghtmap Windows installation

Hi I just went trough your windows insallation. To have it working one has to install setuptools separately. Also for the other downloads I would recommend you link to the following page, that has all windows python tools: [1] Also you have to omit "python" in the setup command. Running "setup.py install" after chdir in an elevated (run as admin) cmd.exe is enough. Have not tried using it yet under windows though. It it ain't work I don't mind and dualboot to Ubuntu... just wanted to give it a try.--Extremecarver 12:46, 13 December 2011 (UTC)

I added your recommendations to the installation instructions. I would appreciate any feedback on how it works under windows.--Panarchos 19:10, 27 December 2011 (UTC)
Besides the above mentioned it works perfectly I think. Just not sure anymore, if there were no other special packages I needed to install. In case I find something else, I think I will simply directly edit it to the description if you don't mind. But probabely I won't - cause my installation already works - and I don#t want to reinstall just to find out.--Extremecarver 16:31, 28 December 2011 (UTC)

maxnodes configurable & pbf support

Im Prinzip siehe Titel. Es wäre super wenn phyghtmap größere Tiles schreiben könnte (mir sind sie derzeit vor allem mit viefinders 1" deutlich zu klein - sprich zu viele. Dazu wäre es auch super wenn phyghtmap pbf als Ausgabeformat unterstützen würde - weil a) es spart deutlich Zeit bei der Weiterverarbeitung b) es ist viel schneller und besser komprimierbar c) es spart sogar unkomprimiert deutlich Platz. --Extremecarver 12:23, 4 January 2012 (UTC)

Den Gedanken aufgreifend würd' ich vorschlagen, einen Parameter "--single-file" einzuführen, durch welchen in zwei temporäre Dateien Nodes und Ways getrennt in richtiger ID-Reihenfolge abgelegt würden und am Schluß zur einer Datei konkateniert (Einsparung der "Konvertierungs-skripte" wie etwa process_phyghtmap_data.pl!). Dieses Resultat hätte dann das "richtige OSM-Format" für osmconvert, welches sehr schnell sowohl Polygone ausschneidet wie auch pbf erzeugen kann (pbf ist bei diesen "OSM-Höhendaten" noch platzsparender als gzipt!). --Kellerma 08:57, 8 January 2012 (UTC)
In Version 1.30 gibt es die --max-nodes-per-tile Option. Die tut genau, was man denkt. Für eine Ausgabe in einer einzigen Datei kann man --max-nodes-per-tile=0 sagen. Außerdem ist das ausgegebene XML jetzt richtig sortiert: zuerst ein Block mit allen Knoten, dann ein Block mit allen Wegen. Alle IDs sind pro phyghtmap-Aufruf einzigartig und fortlaufend.--Panarchos 19:01, 22 January 2012 (UTC)

bounding polygon support

Im Prinzip braucht man osm v6 ja nur um Die daten mit osmconvert/osmosis mit einem Bounding Polygon noch einmal genauer zu schneiden. Wenn phyghtmap schon bounding polygons anstelle einer bounding box verarbeiten würde, wäre das nicht mehr nötig. --Extremecarver 12:23, 4 January 2012 (UTC)

osmconvert arbeitet sehr schnell _wenn_ die nodes & ways richtig sortiert im osm-file vorliegen. Es würde für phyghtmap daher genügen, das Ergebnis als "singe-file" (siehe oben) abzulegen. --Kellerma 09:03, 8 January 2012 (UTC)

Patches by Kukuk

Wouldn't it be good to integrate these patches/diffs [2] - especially the -max-nodes patch is essential...--Extremecarver 12:31, 4 January 2012 (UTC)

Done in version 1.30. There is a --max-nodes-per-way option.--Panarchos 19:05, 22 January 2012 (UTC)

Phyghtmap under Opensuse 11.4 (minimal)

Note that phyghtmap also depends on python-xml. So additionally to what is listed on the dependancies you have to add zypper install python-xml everything else runs smooth (and much quicker to setup than under windows). I think python-xml should also be added to the dependancies list for linux. --Extremecarver 15:55, 4 January 2012 (UTC)

I don't think so because I only use simple string operations to create the XML output. I don't use the xml module.--Panarchos 19:07, 22 January 2012 (UTC)

Phyghtmap >= 1.24

Phyghtmap => 1.24 does only work with pyhton matplotlib < 1.0.0. With matplotlib >= 1.0.0, you will always get: "TypeError: 'points' is an invalid keyword argument for this function". https://build.opensuse.org/package/files?package=phyghtmap&project=home%3Akukuk contains a patch "matplotlib-1.0.0.diff" which fixes this problem. The output is identical to phyghtmap 1.23 --Kukuk 15:43, 10 January 2012

Integrated in phyghtmap version 1.30.--Panarchos 19:08, 22 January 2012 (UTC)

Erstellung einer Höhenlinienkarte für Gesamteuropa

2012-02-02
Ich versuche eine Karte für Europa zu erstellen. Der Area-Parameter ist folgender: -a -11:34:32:72
Dabei gibt es aber ein Problem. Da ich gerne für Bereiche, wo es genauere Daten gibt, diese auch haben möchte, benutze ich den Schalter --viewfinder-mask=1. Das hat aber zur Folge, dass ich zwar für den Bereich südlich des 60. Breitengrades das erhalte, was ich will. Nördlich davon erhalte ich aber fast nichts, da es ja von der NASA dafür keine Daten gibt und von ViewFinderPanoramas nur die Daten mit guter Auflösung geladen werden, und davon gibt es im Norden meines Wissens nur den Bereich am Nordkapp.
Dann habe ich versucht das Ganze in zwei Schritten mit folgenden Aufrufen zu erstellen:

c:\python27\scripts\phyghtmap.exe -a -11:34:32:61 -s 10 -c 100,20 --start-node-id=2000000000 --start-way-id=1000000000 --corrx=0.0005 --corry=0.0005 --max-nodes-per-tile=2000000 --viewfinder-mask=1 --gzip=7

c:\python27\scripts\phyghtmap.exe -a -11:61:32:72 -s 10 -c 100,20 --start-node-id=4000000000 --start-way-id=1100000000 --corrx=0.0005 --corry=0.0005 --max-nodes-per-tile=2000000 --viewfinder-mask=3 --gzip=7

Jetzt habe ich zwar Daten für das komplette Gebiet, allerdings wieder mit zwei Einschränkungen: Nördlich des 60. Breitengrades bekomme ich nur eine Auflösung von 3 Grad, hätte es aber so genau, wie Daten verfügbar sind. Das zweite Problem ist schwerwiegender, beim Erstellen der endgültigen Karte mit mkgmap, ergibt sich eine Lücken zwischen den beiden Bereichen (am 60. Breitengrad) von ca. 70 km, wo es keine Höhenlinien gibt (warum auch immer).
Gut wäre es, wenn man den Bereich in einem Schritt erstellen könnte.

Frage und Vorschlag:
Ist es möglich das Programm so zu erweiteren, dass es immer zuerst versucht Daten vom NASA-Server (in der angegebene Genauigkeit, Schalter --srtm) zu laden. Sollten für den Bereich keine Daten verfügbar sein, dann sollte versucht werden (automatisch oder über einen neuen Schalter) von ViewFinderPanoramas die Daten in der Auflösung von 3 Sekunden zu laden. Wurde zusätzlich der Schalter --viewfinder-mask=1 angegeben, dann wird eben noch versucht genauere Daten zu laden.


P.S.:
Muss dir noch für dein Programm ein Lob aussprechen. Ich habe vorher versucht die Karte mit srtm2osm zu erstellen. Das kommt damit aber überhaupt nicht zurecht und ist sehr langsam. Dein Programm leiste gute Arbeit in einer aktzeptablen Zeit.
Danke.
--AlexJoW 16:09, 2 February 2012 (UTC)

Einfach zwei Durchgänge. Durchgang eins: viewfindert3, dann die view3 Dateien die du benutzen willst, in den srtm3 Ordner schieben, und mit view1 einen neuen Durchgang starten. Es stimmt aber dass etwa "view1,view3,srtm3" als Angabe oder "view1,srtm1,srtm3" besser wären.--Extremecarver 02:12, 4 February 2012 (UTC)
Hallo, erst mal besten Dank für die schnelle Antwort. Ich hab das natürlich sofort ausprobiert. Hat aber leider nicht funktioniert. Vielleicht hab ich wieder was falsch gemacht. Den ersten Aufruf habe ich, nachdem die Daten herunter geladen waren, abgebrochen (gezippten Dateien wurden nicht komplett erstellt). Dann hab ich die heruntergeladenen Dateien wie beschrieben kopiert und den zweiten Aufruf gestartet, bevor ich die wenigen bereits erstellten gezippten Dateien gelöscht hatte. Das Ergebnis ist eine Karte, die nördlich des 61. Breitengrades nichts beinhaltet. Den ersten Aufruf habe ich abgebrochen, weil ich davon ausgegangen bin, dass es keinen Sinn macht, zwei Durchläufe komplett durchlaufen zu lassen, da meines Erachtens sich die Ergebnisse (gezippte Dateien) überschreiben würden und dann die Ids eventuell nicht mehr eindeutig sind. War das eventuell der Fehler? Oder müsste man nach dem Kopieren noch Anpassungen in den Index-Dateien vornehmen? --AlexJoW 13:30, 5 February 2012 (UTC)
Du kannst die Indexes löschen. Die Dateien müssen entpackt sein, dann werden sie nicht überschrieben. Aufpassen dass keine falschen Dateigrößen (gleich kaputte Downloads) vorkommen.--Extremecarver 08:35, 6 February 2012 (UTC)
Ich habe noch einmal einen Test durchgeführt:

HGT-Cache-Verzeichnis gelöscht.
1. Aufruf:
c:\python27\scripts\phyghtmap.exe -a -11:34:32:72 -s 10 -c 100,20 --start-node-id=2000000000 --start-way-id=1000000000 --corrx=0.0005 --corry=0.0005 --max-nodes-per-tile=2000000 --viewfinder-mask=3 --gzip=7
Dann die Dateien aus view3 nach srtm3 kopiert. Nichts gelöscht.
2. Aufruf:
c:\python27\scripts\phyghtmap.exe -a -11:34:32:72 -s 10 -c 100,20 --start-node-id=4000000000 --start-way-id=1100000000 --corrx=0.0005 --corry=0.0005 --max-nodes-per-tile=2000000 --viewfinder-mask=1 --gzip=7
Diesmal mit neuen Start-Ids, damit es keine Überschneidungen gibt
Wenn ich dann die Karte mit mkgmap erstelle, habe ich das Problem, dass es Bereiche gibt, für die z.B. Daten von view1 und srtm3 oder Daten von view3 und srtm3 vorliegen. Besonders der erste Fall ist nicht schön, da man in diesen Bereichen die Höhenlinien doppelt hat.
Also habe ich mir die Mühe gemacht und habe die von phyghtmap erstellten Dateien durchgesehen (ca. 2000 Stück). Dabei wurden alle "doppelten" manuell gelöscht und anschließend wieder die Karte erstellt. Diesen Durchlauf musste ich allerdings auch öfters machen, da ich immer wieder zu löschende Dateien übersehen hatte. Aber jetzt habe ich meine Höhenkarte von Gesamteuropa. War ein langer Kampf.

Deshalb auch noch mal meine Bitte an Panarchos das Programm zu erweitern, damit die manuelle Eingriffe nicht mehr nötig sind.--AlexJoW 16:17, 8 February 2012 (UTC)

In Version 1.43 gibt es die --source-Option: phyhtmap --source=view1,view3,srtm3 sollte das gewünschte Ergebnis erzielen. Das Problem der Lücke bei 60° nördlicher Breite kann ich allerdings leider nicht lösen.--Panarchos 09:34, 23 March 2012 (UTC)
Vielen Dank für die Erweiterung. Hab das natürlich gleich ausprobiert und muss sagen, dass es wunderbar funktioniert.


Mein Aufruf lautet nun:
phyghtmap.exe -a -11:34:32:72 -s 10 -c 100,20 --start-node-id=2000000000 --start-way-id=1000000000 --corrx=0.0005 --corry=0.0005 --max-nodes-per-tile=10000000 --source=view1,view3,srtm3 --gzip=7
Damit funktioniert es mit einem Aufruf, das Ergebnis ist eine Höhenlinienkarte für Gesamteuropa mit der besten Auflösung für jeden Bereich und eine Lücke am 60. Breitengrad gibt es auch nicht.
Nochmal vielen, vielen Dank.
--AlexJoW 16:59, 31 March 2012 (BST)

SRTM1 und USA funktioniert nicht

Mit den srtm1 Daten gibts in den USA noch größere Probleme bei phyghtmap. Hab kein einziges der geofabrik boundaries durchrechnen lassen können. Abbruch meist schon sehr schnell (und i.e. N38W077.hgt hab ich extra ein zweites mal runtergeladen um sicherzugehen dass es korrekt runtergeladen ist).:

Aufruf: phyghtmap --jobs=1 --osm-version=0.6 --step=20 --output-prefix=usne --line-cat=500,100 --srtm=1 --polygon=/home/contourlines/bounds/us-northeast.poly --max-nodes-per-tile=0 --max-nodes-per-way=250 --pbf (bzw mit --gzip=5 anstelle von --pbf was aber den selben Fehler bringt) ...... downloading .... hgt file hgt/SRTM1/N38W075.hgt: 3601 x 3601 points, bbox: (-75.00000, 38.00000, -74.00000, 39.00000) hgt file hgt/SRTM1/N38W076.hgt: 3601 x 3601 points, bbox: (-76.00000, 38.00000, -75.00000, 39.00000) hgt file hgt/SRTM1/N38W077.hgt: 3601 x 3601 points, bbox: (-77.00000, 38.00000, -76.00000, 39.00000) Traceback (most recent call last):

 File "/usr/local/bin/phyghtmap", line 9, in <module>
   load_entry_point('phyghtmap==1.41', 'console_scripts', 'phyghtmap')()
 File "/usr/local/lib/python2.7/site-packages/phyghtmap-1.41-py2.7.egg/phyghtmap/main.py", line 437, in main
   timestampString=output.timestampString))
 File "/usr/local/lib/python2.7/site-packages/phyghtmap-1.41-py2.7.egg/phyghtmap/main.py", line 272, in processHgtFile
   return ways # needed to complete file later

UnboundLocalError: local variable 'ways' referenced before assignment

Ist gefixt in Version 1.42.--Panarchos 09:23, 23 March 2012 (UTC)

Nich möglich SRTM1 und SRTM3 in einer Karte zu verwenden

Etwas ähnlich wie bei obiger Frage nach viewfinder1 und 3 Daten für eine Karte - was aber manuell lösbar ist, hier nochmal die bitte, den Aufruf etwas differenzierter zu gestalten. Für Kanada sind für einige Teile noch SRTM1 Daten verfügbar, für andere nicht. Leider ist es derzeit nicht möglich die SRTM1 Daten gleichzeit mit SRTM3 Daten zu benutzen (das umbenennen des Folders srtm1 in view1 und Aufruf mit viewfinder-mask=1 bringt nichts - die Daten werden einfach ignoriert).--Extremecarver 15:27, 20 February 2012 (UTC)

Ich habe jetzt die --source Option eingebaut (Version 1.43): phyghtmap --source=srtm1,srtm3 sollte das gewünschte Ergebnis erzielen.--Panarchos 09:25, 23 March 2012 (UTC)

Asien Output lässt sich nicht splitten mit mkgmap splitter.jar

phyghtmap --jobs=1 --osm-version=0.6 --step=25 --output-prefix=as2 --line-cat=1000,200 --source=view1,view3,srtm1,srtm3 --area=80:-11.01192:129.99999:83.20162 --max-nodes-per-tile=0 --max-nodes-per-way=250 --pbf java -Xmx5000m -jar splitter.jar --max-threads=4 --max-nodes=9000000 --mapid=75400000 --mixed --overlap=4000 as2*.osm.pbf Der Splitter erstellt nur ein einziges Output File, egal wie klein ich die max-nodes einstelle. Phyghtmap läuft sauber durch (braucht gut 6GB RAM, da 8 vorhanden sind aber keine Problem).--Extremecarver 12:32, 26 March 2012 (BST)

Problem liegt am mkgmap splitter. Es gibt einen Patch auf der Mailingliste der das Problem behebt.

Performance 1.43

While the initial check is much much faster, the actual work for me now takes about 5-10times longer. Is there a problem with my setup, or can other people verify this? It only happens if a polygon file is used. If giving coordinates speed/performance is unchanged. Extremecarver 17:09, 30 March 2012 (BST)

Ups seems to be strongly related to the polygon file. The bigger the worse. Could there be some bug related to larger polygon files sind 1.42?--Extremecarver 21:57, 1 April 2012 (BST)
Processing of large polygon files will be much faster in phyghtmap 1.44. I found a way to move the polygon membership test from the output data to the input data (i. e. the polygon membership test is done only in a few cases compared to the prior behaviour).--Panarchos 22:51, 11 September 2012 (BST)

other data sources?

Is there any way to process data from other sources? I have very good DEM data for the Piedmont from [3]. The data are in UTM32N and the resolution is 10X10m. I am a QGIS user and I've made very nice contours using QGIS, but the resulting contour data are in ESRI shapefiles, and so far I've found no easy way to get the shapefiles all the way to a garmin gmsupp.img file. So I was hoping to be able to go via OSM, but it's not so easy... I managed to convert the shapefiles to osm with ogr2osm, but I'm not sure what to do with the resulting osm file - when I run mkgmap with it, the resulting gmapsupp.img has nothing in it; obviously I would have to add attributes to it classifying the lines as contours, but so far I haven't worked out how to do that. Your tool looks like just the right thing, but it only takes SRTM data. And if I convert my data to mimick SRTM data, I sacrifice the detail I have.

Any hints? I've been looking for days now, and the fact that everyone seems to assume that anyone who wants to create contour lines would want to make them from SRTM data is driving me nuts. I think the cleanest way would be to import shapefiles and so leave users to create contours any way they like if they don't want to use the automatic creation from SRTM data. --Kfj 13:05, 28 May 2012 (BST)

I've found a way to pull shapefiles in so that I can use them in custom maps for my garmin. Ive described my bit of trickery in the wiki, maybe this can serve as inspiration:

http://wiki.openstreetmap.org/wiki/Contour_lines_from_other_Sources --Kfj 08:11, 4 June 2012 (BST)

Bugs in Debian Package phyghtmap_1.43-1_all.deb

Hi Panarchos,

I just now installed phyghtmap_1.43-1_all.deb at my Debian Testing and found two issues with it:

1.)

   File "/usr/bin/phyghtmap", line 5, in <module>
   from pkg_resources import load_entry_point
   ImportError: No module named pkg_resources

Problem: Dependency to python-pkg-resources is missing

Workaround: aptitude install python-pkg-resources

Will be fixed in phyghtmap 1.44.--Panarchos 22:51, 11 September 2012 (BST)


2.)

   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve
   raise DistributionNotFound(req)
   pkg_resources.DistributionNotFound: phyghtmap==1.43

Problem: Distribution files are missing below /usr/lib/python2.7/dist-packages

Workaround:

    cd ../../python2.7/dist-packages/
    sudo ln -s ../../python2.6/dist-packages/phyghtmap
    sudo ln -s ../../python2.6/dist-packages/phyghtmap-1.43.egg-info/
This problem emerges from the fact that the current Debian stable (squeeze) doesn't come with python 2.7. When wheezy gets stable (which should soon be the case, the freeze is some time ago now), the package will be fixed.--Panarchos 22:51, 11 September 2012 (BST)

When possible can you fix the DEB package, or should I try to come up with a patch myself?

Thanks for the great tool, better than Monos :-)

Patch to phyghtmap 1.43-1 for support of hgt cache directory by command line option

I did not liked the way that the cache ./hgt/ directory is always created in the local directory, thus I implemented the command line option --hgtdir to specify the hgt file cache directory. Now I can use one directory across my file system.

Find the patch here: http://wiki.openstreetmap.org/wiki/User:Edamame/PatchPhyghtmapHgtDir

(Other formats I can of course create)

I also now created me a locally fixed deb package of the above mentioned errors. Let me know if you want to get the files.

BTW: Would you mind to move your source code to github.com or other collaboration platform? This would make it much easier to contribute patches.

Cheers! Edamame

Thanks alot. I will integrate the patch in 1.44.--Panarchos 22:51, 11 September 2012 (BST)

phyghtmap on Python 3.3

I'm trying to get phyghtmap to run on Python 3.3 (on Windows 7). So far, the only major problem I have discovered is in pbfUtil.py. In Python 3, binary and string data can no longer be mixed. I am fairly new to Python, but as far as I understand, pbfUtil will have to be converted to use bytearray instead of string. Do you have plans for such a conversion?

Best regards and thanks for the effort -- wolfbert

I just realized that the script will also output xml, and I can run it this way. -- wolfbert 17:25, 29 March 2014 (UTC)

Wunschliste: Option --download-only

Hallo,

wir verwenden phyghtmap um die Höhenlinien für die Freizeitkarte (http://freizeitkarte-osm.de/) zu bauen. Zusätzlich hole ich mir dann meistens noch die hgt Dateien aus dem entsprechenden Verzeichnis um für Qlandkarte GT und andere Applikationen die DEM Daten für Hillshading zusammenzustellen. Oft wäre ich froh, wenn ich phyghtmap verwenden könnte um

  1. die hgt Dateien für ein poly (*.poly) runterzuladen
  2. anzuzeigen welche hgt Dateien nötig sind für das gewünschte poly
  3. das ganze ohne wirklich Höhenkurven zu rechnen (das läuft in einem anderen Schritt ab)

Im Moment behelfe ich mir so, dass ich als output file ein directory/file angebe, das nicht existiert und phyghtmap mit einem stack trace umfällt.... ist aber unschön. Optimaler wäre es (nicht nur für mich, denke ich), wenn man mit einer Option --download-only den Download Prozess (Netzwerkintensiv) und den Höhenkurven-Berechnungsprozess (CPU intensiv) voneinander trennen könnte. ... und ich hätte so die Möglichkeit phyghtmap ein klein wenig zweckentfremdet für meine zusätzliche Anwendung einzusetzen.

Gruss und danke im Voraus

keenonkites

ENGLISH (short version): I'd like to have a new option --download-only that doesn't process any contour lines but just prepares all needed hgt files to cover a specific given poly file. This way the network intensive download can be separated from the calculations and it's easy to use phyghtmap also for downloading and preparing hgt files for hillshading for applications like QLandkarte GT and similar.

Ist implementiert in Version 1.61. --Panarchos (talk) 17:42, 22 February 2015 (UTC)
Bin etwas spät dran aber trotzdem vielen Dank... super -- keenonkites 13.4.2015

ERROR Messages

I am getting the following RuntimeError: maximum recursion depth exceeded while calling a Python object
with the following Parameters under Windows 7 with Python 2.7 - 64 bit

  • phyghtmap.exe --area=6:43:7:46 --source=view1,srtm1
  • phyghtmap.exe --area=7:43:8:44 --source=view1,srtm1
  • phyghtmap.exe --area=19:49:21:50 --source=view1,srtm1
  • phyghtmap.exe --area=-25:63:-13:64 --source=view3

I'm not getting any error with srtm1 or srtm3 data. The last area is north than 60°, so there is no srtm3 data here.
Can somebody please try to reproduce these errors under Windows since they are not reproduceable unter Linux. --WalterSchloegl (talk) 22:49, 12 February 2015 (UTC)

I suppose that this problem arises from the fact that the default recursion limit in python is platform-dependent. On my linux installation it's 1000. What is it on a Windows machine? (in a python shell, say: "import sys; sys.getrecursionlimit()") This basically happens because there is much data in these areas and phyghtmap recursively tries to chop the areas into smaller pieces until a maximum number of nodes per each tile is not exceeded. This can actually be circumvented by either setting this number to a higher value using the --max-nodes-per-tile option (see the output of phyghtmap.exe --help for more info) or by splitting the phyghtmap calls like e. g. phyghtmap.exe --area=6:43:6.5:46 --source=view1,srtm1 and phyghtmap.exe --area=6.5:43:7:46 --source=view1,srtm1. --Panarchos (talk) 17:19, 22 February 2015 (UTC)

Wunschliste: Geotiff input

Hallo, Vielen Dank für das nützliche Tool. Momentan erzeugen wir mit phyghtmap die Höhenlinien für die Garmin-Karte der OpenTopoMap. Die Höhenlinien der Rasterkarte entstehen derzeit mit gdal_contour als einzelne Shapefiles. Das ist alles andere als praktisch und im Zuge der Vorbereitung auf weltweite Abdeckung möchten wir eine bessere Toolchain entwickeln. Da selbst die SRTM-Daten von viewfinderpanoramas noch Fehlpixel besitzen, jagen wir diese erst durch gdal_fillvoids.py und mergen sie zu einer großen Geotiff. Von dieser ausgehend erzeugen wir eine Umprojektion (mit Interpolation), ein Relief und die Schummerung. Perfekt wäre es nun, wenn phyghtmap auch Geotiffs lesen könnte. Die Ausgabedatei als pbf lässt sich nun leicht in eine Datenbank importieren und für die Zukunft abspeichern.

Wäre es möglich, dass phyghtmap eine geotiff-Eingabe bekommt?

Vielen Dank und schöne Grüße

Stefan von OpenTopoMap --Derstefan (talk) 11:50, 8 March 2015 (UTC)


SRTM1 v3 Europe not downloading

Hi Parnarchos - phyghtmap is not able to download the SRTM1 v3 data for Europe as I tried it out - are you sure it grabs the right sources? As to my understanding except for the middle east/Northeast Africa worldwide SRTM1 data is now available (<60°N of course).--Extremecarver (talk) 08:40, 13 May 2015 (UTC)

Wunschliste: lokale hgt files kombiniert mit Schnitt via Polygon

Im Moment werden hgt files, die auf der Kommandozeile mitgegeben werden, ignoriert, sobald ich ein polygon für den korrekten Zuschnitt angebe. Hat das einen speziellen Grund oder könnte das in einer nächsten Version angepasst werden ? Jegliches spätere Zuschneiden von den generierten Höhenlinien führt zu Problemen wie Artefakte und ähnliches. Grund dieser Anfrage/dieses Wunsches: es gibt für immer mehr Gegenden/Länder höherauflösende freie Geländemodelle als die direkt unterstützten Quellen (view1 view3 srtm1 srtm3), meistens in Form von hgt Dateien. Um diese einfach und direkt verarbeiten zu können, wäre diese Kombination von Argumenten und Optionen nötig.

At the moment manually feed hgt files are ignored as soon as a polygon is given for precise cutting of the contour lines. Is there a special reason for this or could this be a possible combination for a future version ? If I have to cut contour lines after generation it always leads into troubles like artefacts. Reason for this request is that there are more and more sources providing hgt files with higher precision than the directly supported sources. To have the same easy and direct workflow the combination of manually feed hgt files and a cutting polygon would be needed.

Nachfrage / Inquiry (2016-11-30)

Gibt's eine chance, dass das in die nächste Version implementiert wird ? Wäre super...

Any chance that this request gets implemented into the next version ? Would be absolutely great