JOSM: Daten aus GPX in Nodes übernehmen

fx99 · 2012-08-08T19:22:24.000Z

Wenn Du schreibst, wie der OSM POI aussehen soll (keys mit tags), dann ist das mit sed / awk / perl keine große Sache.

EvanE · 2012-08-08T19:28:47.000Z

Lübeck:

ich will mal einen Test mit der Forschungsgruppe Meilensteine machen und hierzu habe ich eine GPX-Datei.

Die Daten sind für den POI wie folgt hinterlegt.

171.0000000
1003-Sonneborn
Meilenstein, lippisch, kleine Stele
Meilenstein, lippisch, kleine Stele
City (Large)
…

Kann mir einer sagen, ob man diese Daten irgendwie in OSM-Nodes konvertieren kann. Möglichst einfach. quick and dirty !

Hallo Jan

Am einfachsten geht es mit manuellem Eintragen.
In JOSM (z.B.) GPX-Track mit den Waypoints laden. Die Farbe des Tracks so ändern, dass man die Punkte auch sieht. Der Name der Waypoints wird dabei angezeigt. Die anderen (cmt, desc, sym und extension) siehts du nicht.

Wegpunkt-Tracks kannst du leider nicht in eine Datenebene konvertieren. Also dort wo ein Wegpunkt ist, per Hand die Meilensteine eintragen. Bei der Gelegenheit wo möglich die Lage anhand der umliegenden OSM-Daten und (soweit verfügbar) guter Luftbilder prüfen.

Die andere Methode wäre eine GPX-Datei mit einen Batch-Editor in eine für JOSM nutzbare OSM-Datei umzuschreiben.
Zu dem Zweck erstellst du in JOSM eine Ebene, die nur wenige neue Punkte mit/ohne Tags hat. Dies als .osm Datei speichern. So hast du ein Muster für dein Zielformat.

Die Zuordnung ist relativ klar:

171.0000000 wird ele=171
1003-Sonneborn wird name=1003-Sonneborn
cmt/desc wird zu note=* und desc=* (eventuell reicht eines von beiden)
für … und … gibt es
keine Entsprechung bei OSM. Das ist wahrscheinlich auch unnötig,
da nur für die Darstellung auf einem Garmin-Gerät wichtig.

Jetzt fehlen noch wichtige Informationen für OSM:

ID, Version, visible, …
user, user-id, …
timestamp, …
Deswegen brauchst du die vorher erstellte .osm-Datei um zu wissen, wie diese Informationen für ein neues Objekt aussehen sollen.

Deine Meilenstein-spezifischen Taggs muss du dir aus Description und Comment irgendwie zusammenbasteln.

Edbert (EvanE)

SunCobalt · 2012-08-08T19:41:49.000Z

User-ID, timestamp etc ? Ich dachte immer, man muss nur fortlaufende negative IDs vergeben. User-ID, timestamp, id, version etc wird doch vom Server vergeben afaik.

SunCobalt · 2012-08-08T19:51:16.000Z

yep, wusste ich es doch. Um ein Node zu erstellen, reicht im Minimalfall OSM-ID (negative), lat und lon. In Deinem Fall noch die Tags dazu und Du kannst es hochladen.

fx99 · 2012-08-08T19:51:31.000Z

So sieht ein node aus JOSM aus:

<?xml version='1.0' encoding='UTF-8'?>

SunCobalt · 2012-08-08T19:54:20.000Z

Action=modify wäre bei einer Änderung eines bestehenden Nodes angebracht (positive ID). Eine negative ID erzeugt immer einen neuen Node beim Hochladen. visible=‘true’ kannst Du auch weglassen. Es geht auch ohne

SunCobalt · 2012-08-08T20:06:19.000Z

also hier mal ein minimales Changeset. Speichere es als OSM, öffne es mit JOSM (wenn Du kein upload script hast) und lade es hoch. Lösche es aber hinterher bitte wieder.

EvanE · 2012-08-08T20:06:57.000Z

SunCobalt:

User-ID, timestamp etc ? Ich dachte immer, man muss nur fortlaufende negative IDs vergeben. User-ID, timestamp, id, version etc wird doch vom Server vergeben afaik.

Ich weiß das auch nicht 100% genau, deswegen soll er sich ja eine kleine Musterdatei mit neuen Punkten erstellen. Dann braucht er nicht zu raten.

Habe das grade mal geprüft. Zum Glück stehen die neuen Punkte am Anfang der Datei. (Müssen als erste hochgeladen werden.)

<osm version='0.6' upload='true' generator='JOSM'>
   <node id='-80461' action='modify' visible='true' lat='50.317444904928685' lon='7.790566449038073' />

Die Node-ID muss also fortlaufend negativ sein. Weiter muss action=‘modify’ visible=‘true’ gesetzt sein. Taggs ergänzt man mit .

timestamp, uid, user, version und changeset gibt es nur bei bestehenden/geänderten Objekten.

Das upload=‘true’ in der ersten Zeile <osm … ist gesetzt, sobald eine Änderung in den Daten enthalten ist.

Edbert (EvanE)

chris66 · 2012-08-08T20:18:50.000Z

Hi Jan,
ich weiss nicht ob Dir das hilft (ich glaube Du sprichst perl), aber mit folgendem PROGRESS Programm habe ich immer
meine GPX Files mit Hydranten POIs konvertiert:


/* gpx2osm */

def var ein-name as char format "x(60)". /* Eingabedateiname */
def var aus-name as char format "x(60)". /* Ausgabedateiname */
def var anz      as int no-undo.         /* Zaehler */

def temp-table t no-undo  /* Temporaere Tabelle */
   field t-nr     as int  format "->>>>>>9"   label "nr"
   field t-name   as char format "x(15)"      label "name"
   field t-lat    as dec  format "->9.999999" label "lat"
   field t-lon    as dec  format "->9.999999" label "lon"
   index i1 is primary t-nr.

form /* Eingabe Formular */
   skip(1)   
   ein-name colon 10
   aus-name colon 10
   skip(1)
with frame a width 80 side-labels three-d.

session:numeric-format = "AMERICAN".
session:data-entry-return = yes.

ein-name = "/users/cs/downloads/test.gpx".

aus-name = replace(ein-name,".gpx",".osm").

if aus-name = ein-name then aus-name = aus-name + ".gpx".

update  /* Eingabe der Dateinamen */
   ein-name
   aus-name
with frame a.

anz = 0.

run read-gpx(ein-name).
  
run write-osm(aus-name).

quit.

/*********************************************************/

procedure write-osm.
   def input param fname as char.
   
   output to value(fname).

   put "<?xml version='1.0' encoding='UTF-8'?>" skip.
   put "<osm version='0.6' generator='JOSM'>" skip.
   put "<bounds minlat='51.73' minlon='7.35' maxlat='51.80' maxlon='7.50' />" skip.

   for each t break by t-nr descending :

      put unformatted "<node id='" t-nr "' action='modify' timestamp='2012-01-09T17:15:00Z' visible='true' lat='" t-lat "' lon='" t-lon "'>" skip.

      put unformatted " <tag k='emergency' v='fire_hydrant' />" skip.
      put unformatted " <tag k='fire_hydrant:diameter' v='" t-name "' />" skip.
      put unformatted " <tag k='fire_hydrant:type' v='underground' />" skip.

      put unformatted "</node>" skip.
   end.

   put "</osm>" skip. 
   
   output close.
end procedure.

/*********************************************************/

procedure read-gpx.
   def input param fname as char.
   def var li    as char no-undo.
   def var s     as char no-undo.
   def var i     as int  no-undo.
   def var lat   as dec  no-undo.
   def var lon   as dec  no-undo.
   def var name  as char no-undo.
   
   input from value(fname).

   repeat:
      import unformatted li.
      li = trim(li).
      if li = "" then next.
      
      if li begins "<wpt " then do:

         i = index(li, 'lat="') + 5.
         s = substr(li,i).
         s = entry(1,s,'"').
         lat = dec(s).

         i = index(li, 'lon="') + 5.
         s = substr(li,i).
         s = entry(1,s,'"').
         lon = dec(s).
      end.

      if li begins "<name>" then do:
         s = substr(li,7).
         s = replace(s,"</name>","").
         if name = "" then name = s.
      end.

      if li matches "*</wpt>" and lat <> 0 then do: 
         anz = anz + 1.

         create t.

         assign 
            t-nr = -1000 - anz
            t-name = name
            t-lat = lat
            t-lon = lon.

         lat = 0.
         lon = 0.
         name = "".
                 
      end.
   end.
   input close.
end procedure.

SunCobalt · 2012-08-08T20:31:11.000Z

EvanE:

[Weiter muss action=‘modify’ visible=‘true’ gesetzt sein.

Nein, habe ich schonmal gesagt. Versuch doch mein Mini-Changeset, wo das nicht drin ist.

Cobra · 2012-08-08T20:40:37.000Z

Wenn ihr spielen wollt, nehmt einfach die dev-api: http://master.apis.dev.openstreetmap.org/ (braucht einen 2. account dort)

EvanE · 2012-08-08T21:11:50.000Z

SunCobalt:

EvanE:

Weiter muss action=‘modify’ visible=‘true’ gesetzt sein.

Nein, habe ich schonmal gesagt. Versuch doch mein Mini-Changeset, wo das nicht drin ist.

Das ist das Verhalten von JOSM, was der für den Upload daraus macht oder was die API als Minimum erfordert, ist eine andere Frage. Der Vorteil, das JOSM-kompatible zu machen, ist die Möglichkeit die Lage vor dem Upload prüfen zu können.

Man sollte immer daran denken, dass Consumer-GPS-Geräte nur eine begrenzte Genauigkeit haben. Auf freiem Feld mag das mal drei Meter sein, in schwierigeren Empfangssituationen kann das bei 10 Meter oder schlechter liegen. Zehn Meter heißt dann durchaus mal die falsche Straßenseite.

Edbert (EvanE)

SunCobalt · 2012-08-08T21:22:02.000Z

Cobra:

Wenn ihr spielen wollt, nehmt einfach die dev-api: http://master.apis.dev.openstreetmap.org/ (braucht einen 2. account dort)

Richtige Männer schreiben die Changesets nur mit einem Text-Editor und laden das zu osm.org hoch, nicht zu einer dev-api

wambacher · 2012-08-08T22:02:27.000Z

ich sehe da -mal wieder- ein ganz anderes Problem: Eigentlich ist das hier doch ein Import ungeprüfter Daten nach OSM - wobei mich das “ungeprüft” erheblich mehr stört als der Import an sich.
Anstelle da mal nachzuhaken, wird kräftig mitgeholfen. Find ich nicht so doll.

@jan:

Was ist mit den Formalien bezüglich Imports nach OSM?
Wieviele Punkte sind es?
Wie ist die rechtliche Lage?
Wie sollen die generierten Daten übernommen werden?
Wie sieht es mit der Genauigkeit aus? Nachher stehen die Grenzsteine mitten auf einer Straße oder Kreuzung, im Fluß oder gar in einem Building.
Möglicherweise weil “unsere” Daten leicht daneben liegen und die Fremddaten sehr genau sind? Auf jeden Fall “unpassend”.
Welche Nachbearbeitung ist geplant?
Wird es Sammelrelation “Alle Grenzsteine in …” geben?

Gruss
Walter

Lübeck · 2012-08-09T03:58:42.000Z

Moin !

es geht derzeit nicht um einen Import !

Nur ers5 einmal um eine gpx - osm Konvertierung !

Jan

PS - jetzt mal nicht vom Smarty

Was ist mit den Formalien bezüglich Imports nach OSM?

→ es geht nur um einen Test und da meine Tools auf dem OSM-Format aufbauen suchte ich nach einer Lösung

Wieviele Punkte sind es?

→ es muss wohl teilmanuell erfolgen wenn es denn dazu kommt

Wie ist die rechtliche Lage?

→ alles noch im Gespräch

Wie sollen die generierten Daten übernommen werden?

Wie sieht es mit der Genauigkeit aus? Nachher stehen die Grenzsteine mitten auf einer Straße oder Kreuzung, im Fluß oder gar in einem Building.
Möglicherweise weil “unsere” Daten leicht daneben liegen und die Fremddaten sehr genau sind? Auf jeden Fall “unpassend”.

Welche Nachbearbeitung ist geplant?

… offen

Wird es Sammelrelation “Alle Grenzsteine in …” geben?

von mir nicht angedacht - dafür würde ich sowieso nur Schälte ernten!

gruß Jan

wambacher · 2012-08-09T07:17:26.000Z

Lübeck:

es geht derzeit nicht um einen Import !

Nur ers5 einmal um eine gpx - osm Konvertierung !

moin moin, jan

naja, warten mer mal ab.
obwohl eine Klärung der Formalien - insbesonders mit den Datenlieferanten - ja vor der Programmierung nicht schlecht wäre. Nachher sagt die NEE und das war’s dann.

Gruss
walter

ps: es handelt sich bei deinem Problem um eine einfache Konvertierung vom einer XML-Datei in eine andere. Sowas macht man mit einem XSLT-Programm. XALAN wäre eines davon.

Lübeck · 2012-08-09T07:40:58.000Z

Hi !

ich dachte nur es gibt einen einfachen Weg von dem ich nichts weiß !

gruß Jan .-)

SunCobalt · 2012-08-09T07:46:40.000Z

Global Mapper (kostet einiges, obs die Trail Version kann, weiß ich nicht) macht aus gpx


...........
<wpt lat="45.12518995" lon="21.29834822">
		<ele>139.0</ele>
		<time>2012-05-19T10:41:22Z</time>
		<name><![CDATA[einbahn kommend 2 Strassen weit]]></name>
		<sat>9</sat>
	</wpt>

OSM-xml


<osm version="0.6" generator="Global Mapper">
  <bounds minlat="45.125160" minlon="21.298328" maxlat="45.125207" maxlon="21.298356"/>
  <node id="-1" lat="45.1251899500" lon="21.2983482200">
    <tag k="name" v="einbahn kommend 2 Strassen weit"/>
    <tag k="elevation" v="139.0"/>
    <tag k="time" v="2012-05-19T10:41:22Z"/>
    <tag k="sat" v="9"/>
  </node>

wambacher · 2012-08-09T08:01:52.000Z

SunCobalt:

<tag k="name" v="einbahn kommend 2 Strassen weit"/>

Tolles GiGo-Beispiel - daher auch meine Bedenken zu den Imports.
Allein schon die Umsetzung des Way-Point-Namens in name=*, toll.

Gruss
walter

SunCobalt · 2012-08-09T08:07:29.000Z

Walter,

jeder hier, auch Jan weiß, dass man am ersten Baum vorm Stadttor aufgehangen wird, wenn man einen Import macht. Die Stolpersteine sollten eh fast alle drin sein daher ist an einen Import nicht zu denken. Ich verstehe nicht warum Du verhindern willst, dass man über technische Details redet. Das Beispiel war ein Survey-Waypoint, so mache ich mir Notizen. Jeder weiß, dass man “einbahn kommend 2 Strassen weit” nicht als Name in OSM einspielen sollte