KMLImporter

[maierkurt]

Ich werde noch bekloppt! Ich habe im KMLImporter ein Problem mit dem parse(r). Unter Eclipse arbeitet das Programm ganz normal, die Koordinaten werden aus dem kml-file importiert. Versuche ich das aber mit der Staticlinked-Version oder auf dem PDA, so wird eine Exception geworfen: java.lang.NumberFormatException: 51.1254
Wie kann ich herausbekommen, woran es liegt?

Gruß, maierkurt

 

[MiK]

Willkomen in der wunderbaren Welt der EWE-Bugs...
KMLImporter? Das ist was Neues oder? Für die Routen?

 

[maierkurt]

KMLImporter? Das ist was Neues oder? Für die Routen?

Ganz genau. Unter Eclipse sah es schon ganz gut aus.

Gruß, maierkurt

 

[pfeffer]

na, das klingt nach dem Klassiker: wahrscheinlich muss ein .replace(notDisSeperator, DigSeperator) an passender Steller erfolgen.

Istr nicht unbedingt ein ewe-Bug - habe das noch nicht erforscht, wie das zusammenhängt mit der Locale (aber die Vermutung geht schon auch in diese Richtung).

Gruß,
Pfeffer.

 

[maierkurt]

Ich habe die Sache umgangen, anstatt Convert.parseDouble() habe ich jetzt Common.parseDouble() genommen, die Punkte werden jetzt (scheinbar] richtig eingelesen.
Etwas ganz seltsames bleibt aber noch:
Die for-Schleife in Filter.java ab Zeile 194 läuft in Eclipse ganz hervorragend durch, bei der Static Linked Version bekomme ich den Eindruck, da rechnet einer per Hand im Computer.
Woran kann das denn nun wieder liegen?

Ewe = Entwicklung wird erschwert ;-)


Gruß, maierkurt

 

[MiK]

Dann passiert in der Schleife wohl etwas, was unter EWE wesentlich länger dauert als unter Java. Reden wir von dem unveränderten SVN-Code?

 

[MiK]

Reden wir von dem unveränderten SVN-Code?

Anscheinend nicht. dort beginnt nämlich keine for-Schleife. Aber was mir bei diesen Schleifen aufgefallen ist: Es werden immer wieder neue CWPoint-Objekte angelegt. Ich habe irgendwie in Erinnerung, dass das Anlegen von Objekten unter EWE sehr lange dauert.

Außerdem wird durch die Unterfunktion, die den Abstand von Punkt zu Segment berechnet unnötig oft von Grad in Radiant umgerechnet. Das müsste man ja eigentlich pro Segment nur einmal für den Start- und Endpunkt machen.

 

[maierkurt]

Reden wir von dem unveränderten SVN-Code?

Was die Schleife betriff: Ja.

Gruß, maierkurt

 

[MiK]

Reden wir von dem unveränderten SVN-Code?

Was die Schleife betriff: Ja.

Aber sie ist anscheinend nicht mehr in der gleichen Zeile. Ich nehme an es geht um den Code, der hiermit anfängt:

// for each segment of the route...
for(int z=0;z<wayPoints.size()-1;z++){

Und eben um die Funktion DistToSegment(). Dann fällt mir erst einmal nur das oben erwähnte ein. Man sollte wohl auf jeden Fall das Erzeugen der CWPoints aus der Schleife herausziehen. Wenn man sie überhaupt verwenden will und man nicht besser gleich mit in Radiant umgerechneten doubles arbeitet.

 

[maierkurt]

Aber was mir bei diesen Schleifen aufgefallen ist: Es werden immer wieder neue CWPoint-Objekte angelegt. Ich habe irgendwie in Erinnerung, dass das Anlegen von Objekten unter EWE sehr lange dauert.

Genau das war es! Super, jetzt muss ich noch sehen, wie ich die Sache elegant aus der Schleife herausbekomme.

Und eben um die Funktion DistToSegment().

Die benutze ich nicht, ist zu rechenaufwändig.

Gruß, maierkurt

 

[MiK]

Genau das war es! Super, jetzt muss ich noch sehen, wie ich die Sache elegant aus der Schleife herausbekomme.

Naja, einfach die drei Punkte vor der äußeren Schleife anlegen und dann innen an den Stellen, an denen vorher ein neues Objekt erstellt wurde, nur die Koordinaten neu setzen. Natürlich möglichst direkt oder mit Funktionen, die nicht wieder ein neues Objekt anlegen.

Und eben um die Funktion DistToSegment().

Die benutze ich nicht, ist zu rechenaufwändig.[/quote]
Dann kann es auch nicht mehr die gleiche Schleife sein ;-) Wie machst Du es jetzt?

 

[maierkurt]

Wie machst Du es jetzt?

Zuerst werden die Koordinaten aus dem kml-file drastisch reduziert.
Erfolg nach folgendem Schema: Berechen Abstand Punkt zu Punkt[i+1], ist er geringer als distance / 2, so fliegt Punkt[i+1] aus der Liste. Je größer der Divisor, desto "exakter". Hier kann man noch etwas probieren.
Zu den übriggebliebenen Punkten wird dann der Abstand zu jedem einzelnen Waypoint berechnet und entsprechend gefilter.
Das Ergebnis ist zwar nicht ganz so genau wie distToSegmend, dafür aber rechenmäßig zumutbar.

Gruß, maierkurt

 

[MiK]

Du berechnets nur den Abstand zu den Punkten und nicht zu dem Streckenabschnitt? Das führt dann aber zu seltsamen Ergebnissen, wenn es nur ein einfacher grober Linienzug mit wenigen Stützstellen ist.

 

[maierkurt]

Das führt dann aber zu seltsamen Ergebnissen, wenn es nur ein einfacher grober Linienzug mit wenigen Stützstellen ist.

Da hast Du Recht, darüber habe ich mir schon Gedanken gemacht. Aus diesem Grund hatte ich http://www.geoclub.de/viewtopic.php?f=40&t=25182 aufgemacht um herauszubekommen, ob ein einfacher grober Linienzug überhaupt erstellbar ist. Wenn man die Standard-Routen-Funktion von GoogleEarth benutz, sind automatisch unzählige Stützpunkte vorhanden, mir ist keine Straße bekannt, die über einen größeren Streckenabschnitt exakt geradeaus verläuft.


Gruß, maierkurt

 

[MiK]

Es kommt dann stark auf das Verhältnis von Segmentlänge und gewünschtem Abstand von der Route an. Wenn man zum Beispiel wirklich nur Caches direkt an der Straße möchte und deswegen nur 50m Abstand angibt, wird es bei Segmentlängen mehr als 50m schon kritisch und bei 100m geht einem schon einiges durch die Lappen.

 

[maierkurt]

Hier mal ein Bild zu meiner Vorgehensweise:

Cacheabstand 100m zur Route.
Die schwarze Freihandlinie stellt die Route aus GoogleEarth dar, welche aus unzähligen Koordinatenpaaren besteht. Diese Linie wird jetzt auf Koordinatenpaare reduziert, welche einen Luftlinienabstand von Cachedistanz / 2 haben. Dargestellt durch die roten Striche. Jedes Paar (= jeder rote Strich) wird jetzt überprüft, ob sein Abstand zu einem Wegpunkt weniger als 100m beträgt. D. h., alle Caches, die sich innerhalb der grünen Kreise (= Radius 100m) befinden, werden nicht ausgefiltert. Sooo ungenau ist das doch gar nicht.

Gruß, maierkurt

 

[MiK]

Sooo ungenau ist das doch gar nicht.

Wenn der Abstand der Punkte auf der Linie nicht größer als Cacheabstand/2 wird, sieht das einigermaßen genau aus. Über den Divisor kann man, wie Du schon erwähnt hast, ja nochmal diskutieren.