Höhenangaben werden nicht geladen

[routeconverter]

ich denke mal, es ist jetzt soweit, dass ich dir
die Änderungen (bzw. Neuerungen) schicken kann.

Anbei sind zwei neue Dateien (Klassen), ElevationHelper.java (vielleicht
wäre ElevationService besser?) und die ElevationTile.java.

Dann noch die leicht geänderte PositionAugmenter.java.

Hallo Robert,

das sieht gut aus. Ich würde Deine Klassen gerne integrieren und hätte da einige Fragen:

• Hast Du in der Zwischenzeit noch weiter dran gearbeitet?
  
• Gibt es Unittests?
  
• Stellst Du die Quellen unter der GPL zur Verfügung wie der Rest von RouteConverter auch?
  
• Hast Du etwas dagegen, daß ich die Quellen an den übrigen Standard, was Benennung und Formattierung angeht, anpasse?
  
• Will man als Nutzer eigentlich alternativ geonames.org oder HGT-Dateien nutzen?
  

[robekras]

Hallo Christian,

1) Nein, hab da nicht mehr dran weitergearbeitet. Der Punkt der bezüglich
der Höhenkacheln noch zu bearbeiten wäre, wäre das mit den Lücken.
Da hätte ich schon eine Idee, wie man das lösen könnte, aber die Zeit...
Vor allem weil mir noch eine andere Idee im Kopf herumschwirrt, welche
gerade eine etwas höhere Priorität hat (auch bezügl. RouteConverter).

2) Unittest hab ich keine. Hatte daran auch schon mal gedacht. Ich
habe aber noch keine gemacht, und wiederum, die Zeit...

3) GPL, aber natürlich, selbstverständlich.

4) Benennung und Formatierung anpassen: Frag nicht so viel.
Das ist dein Projekt, der Code gehört jetzt zu RouteConverter.
Man wird ihn hoffentlich danach noch lesen können, oder?
Falls ich ihn überhaupt noch mal lesen muss (weil er funktioniert ja, oder?
Außer das mit dem Lückenfüllen, aber dass ist dann einfach eine
zusätzliche Methode).

5) Geonames und HGT Dateien?
Mir persönlich natürlich egal, weil ich ja weiß was das Bessere ist.
Von dem Standpunkt aus, dass der User eine Entscheidung treffen
muss, mit was er arbeiten möchte, eher schlecht.
Wenn dann allerhöchstens ein automatisches Zurückfallen auf Geonames
falls die HGT-Dateien nicht herunterladbar sind.
Geonames bietet eigentlich fast keinen Vorteil. Allerhöchstens für den Fall,
dass man nur wenige Höhen abfragen möchte, und dann auch nur für den
Fall, dass die Höhenkachel noch nicht auf dem heimischen Computer liegt.

Übrigens fallen die Unterschiede bei den Höhenprofilen zwischen Geonames
und HGT besonders im Gebirge auf.

Servus
Robert

[routeconverter]

4) Benennung und Formatierung anpassen: Frag nicht so viel.
Das ist dein Projekt, der Code gehört jetzt zu RouteConverter.
Man wird ihn hoffentlich danach noch lesen können, oder?

Hoffentlich besser als je zuvor ;-)

Falls ich ihn überhaupt noch mal lesen muss (weil er funktioniert ja, oder?
Außer das mit dem Lückenfüllen, aber dass ist dann einfach eine
zusätzliche Methode).

Ich habe nicht genau verstanden, was das Problem ist. Es gibt also Lücken in den HGT-Datensätzen - berechnen kann man da nichts, also muß man es von einem anderen Dienst holen, oder?

5) Geonames und HGT Dateien?
Mir persönlich natürlich egal, weil ich ja weiß was das Bessere ist.

Du meinst HGT-Dateien ist besser? Ich dachte eigentlich, hinter http://www.geonames.org/export/web-services.html#srtm3 lägen dieselben Daten und der Vorteil von HGT ist, daß sie auf dem lokalen Rechner liegen. Oder ist die Qualität der Daten bei HGT-Dateien auch besser?

Von dem Standpunkt aus, dass der User eine Entscheidung treffen
muss, mit was er arbeiten möchte, eher schlecht.

Wenn dann allerhöchstens ein automatisches Zurückfallen auf Geonames
falls die HGT-Dateien nicht herunterladbar sind.

Das sehe ich auch so.

Geonames bietet eigentlich fast keinen Vorteil. Allerhöchstens für den Fall,
dass man nur wenige Höhen abfragen möchte, und dann auch nur für den
Fall, dass die Höhenkachel noch nicht auf dem heimischen Computer liegt.

Übrigens fallen die Unterschiede bei den Höhenprofilen zwischen Geonames
und HGT besonders im Gebirge auf.

Ok, ich hätte weiterlesen sollen... welchen der 3 Geonames Höhendienste nimmst Du da als Referenz für den Vergleich SRTM3, Aster Global Digital Elevation Model oder GTOPO30?

[robekras]

Hallo Christian,

gut das ich nochmal hier reingeschaut habe.
Seltsamerweise habe ich wieder keine Benachrichtigung erhalten,
obwohl ich mir diesmal sicher bin, dass ich
den Haken richtig gesetzt habe.

Das mit den Lücken:
Ich bin mir ziemlich sicher, dass auch Geonames Lücken hat, und
sonst habe ich nirgends was gefunden, dass ohne diese Lücken ist.

Es gibt ja dieses Programm SRTMFill, dass diese Lücken in den HGT-Dateien
per Interpolation füllen kann. Ich hab das auch mal ausprobiert mit dem
frei erhältlichen SRTMFill, dass funktioniert auch so weit.
Wobei ich mir über die Qualität der Interpolation nicht ganz klar bin.
Ich dachte eigentlich dass ich bei der Rumprobiererei mal gesehen hatte,
dass er gut interpoliert, dann hatte ich nur so 08/15 Interpolationen gesehen.
Um eine bessere SRTMFill Version zu bekommen, muss man sich registrieren,
und ich glaub, das kostet was. Bin da aber nicht ganz schlau draus geworden.

Wenn ich mich nicht irre gibt es zwar irgendwo interpolierte Höhendateien,
aber ich glaube, dass die viel gröber aufgelöst sind (also nicht in 1/1200°).

Selber interpolieren (und eventuell extrapolieren) lässt sich da auf jeden
Fall was, muss man halt schauen mit welchem Algorithmus man auf ein
anständiges Ergebnis kommt.

Der Unterschied HGT zu Geonames:
So wie ich das sehe, benutzt Geonames auch die HGT-Dateien. Was
anderes gibt es glaub ich auch nicht. Man sieht das ja auch an den Lücken,
die sind meiner Erinnerung nach auch an den selben Stellen.
Nur Geonames macht unabsichtlich (oder absichtlich?),
bei der Berechnung der Höhe etwas falsch. Entweder die interpolieren
nicht, oder sie interpolieren falsch, oder sonst was.
Ich bin mir eigentlich ziemlich sicher, dass 'meine' Interpolation richtig ist.

Den Vergleich beziehe ich auf die Daten, die mit der bisherigen Methode
erzielt worden sind (also Geonames) und die neue Methode.
Ich hatte dazu Screenshots von Höhenprofilen mit Geonames und
mit der neuen Methode gemacht, und miteinander verglichen.
Und ich nehme an, dass Geonames auch die SRTM3 benutzt.

Servus und noch einen schönen Feiertag
(was kann man wohl bei diesem Wetter machen?
Vor RouteConverter sitzen )
Robert

[routeconverter]

Seltsamerweise habe ich wieder keine Benachrichtigung erhalten,
obwohl ich mir diesmal sicher bin, dass ich
den Haken richtig gesetzt habe.

Der vermaledeite qmail-Server gibt täglich den Geist auf und versendet keine Mails mehr... keine Ahnung, warum.

So wie ich das sehe, benutzt Geonames auch die HGT-Dateien.

Für den SRTM3 Webservice klingt das nach der Beschreibung so.

Servus und noch einen schönen Feiertag
(was kann man wohl bei diesem Wetter machen?
Vor RouteConverter sitzen )

Ich bin statt Moped ein bißchen Rad gefahren und dann in die warme Wanne gestiegen... nicht perfekt, aber geht ;-)

[robekras]

Hallo Christian,

Ich bin statt Moped ein bißchen Rad gefahren und dann in die warme Wanne gestiegen... nicht perfekt, aber geht ;-)

Moped fahren...?
Abgesehen davon, dass das Wetter dafür ja überhaupt nich taucht,
machen das nicht so alte Männer mit 50+?
Also zumindest kommt es mir so vor, wenn ich mit Mopped unterwegs bin .

Tja und Rad fahren sollte ich eigentlich auch, weil in zwei Wochen geht's
über die Alpen.
Aber momentan bei dem Wetter bei uns... .

Übrigens meine Andeutung woran ich gerade arbeite...
Nun, nachdem ich jetzt die ersten Erfolge habe, kann ich's ja mal sagen:
Also das Problem ist ja eine Trackliste (mit sehr vielen Punkten),
einzudampfen auf eine Route mit wenigen Punkten (für's Navi).
Da gibt es ja so einen Algorithmus (auch bei dir im Programm), weiß aber
gerade den Namen nicht.

Meine Idee ist aber eine Andere, und zwar so, wie man das auch
manuell machen würde, nur in diesem Fall automatisch per Programm.
Das Verfahren ist folgendermaßen:
Wichtig sind bei einer Route eigentlich immer die Punkte an einer
Straßenkreuzung, und gleich der nächste in der Straße in die man
einbiegen muss.
Wenn man der Straße folgt sind eigentlich alle Punkte bis zur nächsten
Einmündung oder Abzweigung unwichtig. Wobei man manche Punkte
stehen lassen kann, um immer eine einigermaßen richtige Richtung
angezeigt zu bekommen.

Wie funktioniert's:
Meine Tracks habe ich von OpenRouteService.org berechnen lassen.
Und die benutzen openstreetmap Daten.
Im RouteConverter habe ich jetzt die gpx-Datei eingelesen, und hole
mir jetzt von OSM für jeden Trackpoint die entsprechende Wegeinformation.
So kriege ich heraus, wo Kreuzungspunkte sind.
Als Abfallprodukt bekommt man dann auch noch den Wegtyp (also z.B.
asphaltiert, Schotter usw.) mit. Diese Info könnte man dann z.B. in das
Höhenprofil mit einbauen. So wie ich es aus einigen Büchern kenne.
Dort wird im Höhenprofil mit angegeben ob es Straße, oder Schotterweg ist.

Servus und ein schönes Wochenende
Robert

[routeconverter]

Abgesehen davon, dass das Wetter dafür ja überhaupt nich taucht,
machen das nicht so alte Männer mit 50+?

Mit Harley unterm Hintern?

Nun, nachdem ich jetzt die ersten Erfolge habe, kann ich's ja mal sagen:
Also das Problem ist ja eine Trackliste (mit sehr vielen Punkten),
einzudampfen auf eine Route mit wenigen Punkten (für's Navi).
Da gibt es ja so einen Algorithmus (auch bei dir im Programm), weiß aber
gerade den Namen nicht.

Douglas-Peucker?

Meine Idee ist aber eine Andere, und zwar so, wie man das auch
manuell machen würde, nur in diesem Fall automatisch per Programm.
[..]

Interessante Idee, wenn Du da etwas lauffähiges hast... das interessiert mich.

[routeconverter]

Funktionieren tut das ganze weltweit (also auch mit Süden und Westen),
ich hab's anhand von Küstengebieten mal getestet (ob an der richtigen
Stelle Meereshöhe ist).

Hallo Robert,

ich habe mal angefangen, Deinen Code zu integrieren und stecke nun vor dem Problem, daß

ElevationTile#getElevationFor(Double longitude, Double latitude)

für recht viele Werte, mit denen ich Geonames teste, NullPointerExceptions oder java.io.IOException: Negative seek offset erhalte.

Der Code liegt unter http://www.routeconverter.de/svn/RouteCo...trunk/hgt/ mit einem Testcase http://www.routeconverter.de/svn/RouteCo...lesIT.java

Hast Du diese Fehler auch gesehen?

[robekras]

Hallo Christian,

ich weiß, dass an den Stellen, für die keine Höhen vorhanden sind
in den hgt-Dateien eine negative Zahl steht (das ist irgendwo
beschrieben).
Aus meiner Erinnerung kann ich nur sagen, dass ich der Meinung bin,
dass Geonames an den selben Stellen (oder annähernd an den selben)
Lücken hat, wie ich es auch in den hgt-Dateien gefunden habe.
Wenn über Geonames keine Lücken kommen, und über die hgt-Dateien
schon, kann es vielleicht sein, das Geonames in dem Fall, dass eine
einzelne Lücke auftaucht, einfach einen benachbarten Punkt nimmt, und
erst bei größeren Lücken nicht mehr kann.
Oder die Unterschiede auch dadurch herrühren, dass ja meiner Meinung
nach, Geonames beim Bestimmen der Höhe was anders (falsch?) macht.

Was kommt den von Geonames zurück, wenn bei denen eine Lücke ist?

Meiner Beobachtung nach gibt es vor allem in gebirgigen Regionen Lücken,
im Flachland eher weniger (oder sogar keine).

Bei meiner Implementierung ist es momentan auch so, dass ich eine Höhe
nicht bestimmen kann, falls ein Eckpunkt (der vier notwendigen) eine Lücke
(Negativwert) hat.

Servus
Robert

[routeconverter]

Was kommt den von Geonames zurück, wenn bei denen eine Lücke ist?

Konkrete Werte... die Lücken sind gar nicht so entscheidend sondern die Stabilität des Codes - wenn 100000 RouteConverter-Nutzer irgendwo auf der Erde die HGT Dateien benutzen dürfen da keine Exceptions auftreten.

Folgende Tests verdeutlichen das vielleicht: Das kommt bei Geonames zurück

public void testElevationFor() throws IOException {
assertEquals(40, service.getElevationFor(11.2, 59.0).intValue());
assertEquals(120, service.getElevationFor(11.2, 60.0).intValue());
assertEquals(648, service.getElevationFor(11.2, 61.0).intValue());

assertEquals(77, service.getElevationFor(-68.0, -54.0).intValue());
assertEquals(455, service.getElevationFor(-68.0, -55.0).intValue());
assertEquals(null, service.getElevationFor(-68.0, -56.0));
assertEquals(null, service.getElevationFor(-68.0, -56.1));
assertEquals(null, service.getElevationFor(-68.0, -57.0));
}

Und das bei HGT:

public void testElevationFor() throws IOException {
assertEquals(40, files.getElevationFor(11.2, 59.0).intValue());
assertEquals(190, files.getElevationFor(11.2, 60.0).intValue());
assertNull(files.getElevationFor(11.2, 61.0));

// TODO: java.io.IOException: Negative seek offset
// assertEquals(77, files.getElevationFor(-68.0, -54.0).intValue());
// TODO: java.io.IOException: Negative seek offset
// assertEquals(455, files.getElevationFor(-68.0, -55.0).intValue());
assertEquals(null, files.getElevationFor(-68.0, -56.0));
assertEquals(null, files.getElevationFor(-68.0, -56.1));
assertEquals(null, files.getElevationFor(-68.0, -57.0));
}

Hast Du das mal mit negativen Longitude/Latitude-Werten getestet?

Meiner Beobachtung nach gibt es vor allem in gebirgigen Regionen Lücken,
im Flachland eher weniger (oder sogar keine).

In der angehängten Datei
  MIT_HOEHEN_Track_Planung_Lodrone-Riva_del_Garda.zip (Size: 25.78 KB / Downloads: 718) von Dir habe ich in den Kommentar die Höheninformation von

• geonames.org
  
• earthtools.org
  
• HGT
  

geschrieben.