Ich hatte das auch mit der Version 1.43 an der gleichen Stelle. Ab Version 1.44 scheint das behoben zu sein - Weiterverarbeitung wie vorher. (Aber mein Merge-Script musste ich anpassen, Node-Refs und Tags werden nicht mehr zusammen mit ID und Version in eine komplette Zeile geschrieben.)
Auflösen der Relationen mit eigenen Perl-Programmen
Land/Sea tiles via land_polygons.shp / ogr2ogr / polyshape2osm
Kartenerstellung: Mapsforge Android Mapwriter (Osmosis Plugin)
Christian hat neue Karten für Österreich erzeugt. Die Verwendung von phyghtmap 1.44 alleine behebt das Problem nicht.
Erst wenn auch die Daten neu geladen werden, also nicht aus einem (alten) Cache kommen, ist der Defekt korrigiert.
Fazit: Der Defekt war möglicherweise in den Ausgangsdaten vorhanden, welche inzwischen korrigiert sind …
Die neue Karte mit Phyghtmap144 läuft gerade durch, wird in 2 Tagen online sein.
Was die Höhendaten selbst betrifft so war es bis dato durchaus hilfreich ab und zu den hgt-cache
oder zumindest die viewfinderHgtIndex_3.txt zu löschen um das downloaden korrigierter
View3-Daten zu erzwingen.
Also, die Fehler sind bei --source=view1,view3,srtm1,srtm3 noch vorhanden. Die sind definitiv in den view1 Dateien drinnen. Hab extra den Ordner view1 gelöscht (nachdem reines Indexlöschen nichts bringt, wenn die Daten schon vorhanden sind, das Indexlöschen bewirkt nur, dass wenn Daten vorher nicht am Sever existierten, sie dann runtergeladen werden - es werden jedoch keine älteren Dateien, wenn schon vorhanden ausgestauscht) und mit 1.44 durchlaufen lassen. Die view3 Daten sind okay, allerdings halt von der Qualität in den Alpen schon deutlich schlechter.
Fehler:
Traceback (most recent call last):
File “/usr/bin/phyghtmap”, line 5, in
from pkg_resources import load_entry_point
File “/usr/lib/python2.7/dist-packages/pkg_resources.py”, line 2819, in
parse_requirements(requires), Environment()
File “/usr/lib/python2.7/dist-packages/pkg_resources.py”, line 588, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: phyghtmap==1.44
Die beiden phyghtmap-Ordner befinden sich in /usr/lib/python2.7/dist-packages.
bist du sicher, dass sich phyghtmap-1.44.egg-info im “dist-packages” befindet und nicht noch phyghtmap-1.43.egg-info von der letzten Installation/manuellen Kopie? War nämlich eine Falle, in die ich selbst getappt bin.
Ich habe die Austria (und einige Andere Karten) jetzt neu generiert, mit komplett gelöschten HGT-Cache
UND
habe die Start ID’s sowohl von Node als auch Way auf 10.000.000.000 gesetzt (wie auch im Phyghtmap man so empfohlen)
Damit ist der Fehler definitiv eliminiert.
Die neue Karte (auch mit einigen Verbesserungen bez. der Zoomstufen und mit zuverlässig gerenderten Berghütten) wird ist of sofort online.
Also in AT gibt es wenn man view1 benutzt, definitiv weiterhin zwei Fehler (der horizontale ist weg, die vertikalen weiterhin), benutzt man nur view3, dann gibts keine Bugs:
Hier 1.44 und so erstellt: phyghtmap --jobs=1 --osm-version=0.6 --polygon=/home/contourlines/bounds/austria.poly --step=20 --no-zero-contour --output-prefix=at --line-cat=500,100 --start-node-id=10000000 --start-way-id=10000000 --source=view1,view3,srtm1,srtm3 --max-nodes-per-way=230 --max-nodes-per-tile=0 --pbf
Das ganze auf einem nagelneuen Hetzner Root Server…
ACHTUNG: Jonathan hat bei seinen viewfinderpanoramas.org scheinbar die Struktur geändert, unbedingt auf phyghtmap-1.45 updaten sonst werden die Karten ein Mischmasch aus srtm3/view3, mit der V1.45 funktioniert wieder alles.
@Extremcarver: Die beiden Fehler kann ich bestätigen, sind mir letzte Woche auch aufgefallen.
Die Fehler liegen daran, dass da ein paar Zeilen Code verrutsch sind aus einem in das nächste File. Wenn ich die verschiebe - werde ich die Fehler los, aber hab anderswo stattdessen dann so Linien. Vielleicht kann es ja jemand fixen?
Ok, westlich von Oberammergau liegt die kaputte Stelle auf E11° 00.000
Damit handelt es sich um eine Kachelgrenze.
Beides sind View1 Daten.
Werde mal mit den verschiedenen Daten spielen, aber für mich sieht es bald so aus als wenn da Wege am Kachelrand geschlossen würden, die nicht geschlossen werden sollten.
also der Fehler ist schon in den hgt Dateien vorhanden, Wenn man sich die an der entsprechenden Stelle ansieht, sieht man dort einen schwarzen Balken. Da kann kein Tool etwas retten.
Einzige Möglichkeit, solange die *.hgt Dateien nicht gefixt sind, ist die entsprechenden Dateien nicht zu verwenden und mit anderen (view3, srtm3) zu ersetzen, auch wenn man den Übergang deutlich sieht.
Den Verantwortlichen habe ich mal angemailt, mal sehen was er sagt.
Vielleicht können wir hier ja alle kaputten Dateien sammeln? Oder zumindest posten, an welchen Koordinaten solche “Artefakte” auftauchen, dann kann ich auch selber nachsehen.
Also ich habe N47E010.hgt (view1) gefunden, welche definitiv defekt ist.
Ich schreibe äusserst selten und ungern solche Antworten aber der “”“Verantwortliche”“” heisst Jonathan und da er seit fast 10 Jahren unermüdlich daran arbeitet der OSM-Welt ein ordentliches hgt-Dataset zur Verfügung zu stellen hat er sich den Respekt Ihn ordentlich beim Namen zu nennen wohl redlich verdient !
Bei allen Respekt…
Leute, die ich mit Namen kenne, nenne ich auch so. Von Leuten, wo ich nur eine E-Mail Adresse habe, aber keinen Namen, vermeide ich es anhand der Adresse auf den Namen zu schließen. Das kann nämlich so richtig peinlich werden. Vor allem, wenn ich nicht weiß ob das der Vor/Nachname oder ein Fantasie-Account-Name ist. Und Leute, die ich nicht kenne, noch nie etwas mit zu tun hatte und rein gar nichts von weiß rede ich auch sehr ungern einfach so mit Vornamen an. Das hat rein gar nichts mit fehlendem Respekt zu tun, sondern genau das Gegenteil.