Relation runterladen?

[Sven Geggus]

Hallo zusammen,

man kann ja sowas in den Browser laden:
http://www.openstreetmap.org/?relation=1203264

Und da bekommt man dann die passende Relation angezeigt.

Auf die schnelle habe ich mit Firebug jetzt nicht rausgefunden
welches script die Relation selbst für Openlayers erzeugt.

Ziel ist es zum Beispiel Radfernwege und dergleichen als GPX-Datei
runterzuladen. Als Linienzug wird das ganze ja offenbar bereits für
Openlayers übertragen. Ein Export Knopf wäre schön aber vielleicht
könnte man ja auch ein Userscript für den Browser bauen.

Gruss

Sven

[aighes]

Hallo,
das kann der relation analyzer: http://ra.osmsurround.org/

Viele Grüße,
aighes

[Stefan Sandrock]

Post by aighes
Hallo,
das kann der relation analyzer: http://ra.osmsurround.org/
Viele Grüße,
aighes

habe ich gerade ausprobiert - aber wie bekomme ich die relation-id - für
z.b. den fernwanderradweg R 3 - bzw. wo bekomme ich die relations-nummer
her ?

htx s

[aighes]

Hallo Stefan,

Post by Stefan Sandrock
habe ich gerade ausprobiert - aber wie bekomme ich die relation-id - für
z.b. den fernwanderradweg R 3 - bzw. wo bekomme ich die relations-nummer
her ?

du kannst auch nach dem Namen suchen. Alternativ zeigen auch die Editoren
die ID an.

Viele Grüße,
aighes

[Sven Geggus]

Post by aighes
das kann der relation analyzer: http://ra.osmsurround.org/

Ach danke, das sieht ganz gut aus.

Sven

[Frederik Ramm]

Hallo,

Post by Sven Geggus
Auf die schnelle habe ich mit Firebug jetzt nicht rausgefunden
welches script die Relation selbst für Openlayers erzeugt.

Da gibts doch einen OSM-Layer direkt im OpenLayers, der das direkt aus
dem OSM-XML einliest.

Post by Sven Geggus
Ziel ist es zum Beispiel Radfernwege und dergleichen als GPX-Datei
runterzuladen. Als Linienzug wird das ganze ja offenbar bereits für
Openlayers übertragen.

Nein, das wird genauso uebertragen, wie es aus dem relation/full-Request
rauskommt, also als OSM-XML.

Bye
Frederik

[Sven Geggus]

Post by Frederik Ramm
Da gibts doch einen OSM-Layer direkt im OpenLayers, der das direkt aus
dem OSM-XML einliest.

Sowas?

http://www.openstreetmap.org/api/0.6/relation/1203264

Das reicht ja nicht zum zeichnen im Openlayers, das sind ja nur die refs auf
die verwendeten Wege.

Gruss

Sven

[André Joost]

Post by Sven Geggus

Post by Frederik Ramm
Da gibts doch einen OSM-Layer direkt im OpenLayers, der das direkt aus
dem OSM-XML einliest.

Sowas?
http://www.openstreetmap.org/api/0.6/relation/1203264
Das reicht ja nicht zum zeichnen im Openlayers, das sind ja nur die refs auf
die verwendeten Wege.

häng noch ein /full dran.

http://www.openstreetmap.org/api/0.6/relation/1203264/full

Dafür dauerts dann ein wenig länger...

Gruß,
André Joost

[Rainer Kluge]

In einer Zeit, als der Realtion Analyzer extrem langsam war, habe ich mal ein
Perl-Skript gebastelt, welches zu einer Relation-Id den GPX-Track erzeugt. Wenn
du nach "rel2gpx" googelst findest du eine Seite, von der man es herunterladen
kann.

Das Skript kann auch im Batch-Modus aufgerufen werden und arbeitet dann eine
Liste von Relationen ab.

Grüße
Rainer

[Carsten Gerlach]

Hallo,

Post by Rainer Kluge
In einer Zeit, als der Realtion Analyzer extrem langsam war, habe ich mal
ein Perl-Skript gebastelt, welches zu einer Relation-Id den GPX-Track
erzeugt.

Tolle Sache, gefällt mir, vorallem das verschachtelte Relationen komplett
runtergeladen werden. :-)

Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei (z.B.
germany.osm) verwenden kann, aus der die Relation extrahiert wird?

Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.

Wäre super wenn das umsetzbar wäre. :-)


Gruß, Carsten

[Rainer Kluge]

Hallo,

Post by Carsten Gerlach
Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei (z.B.
germany.osm) verwenden kann, aus der die Relation extrahiert wird?

Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer Relation aus einer
solchen Datei auslesen, dann muss man die komplette Datei lesen.

Ein XML-Parser, den ich für die sauberste Lösung halte, stößt da schon bei
Bundesland-Dateien an Speichergrenzen, von der Rechenzeit ganz zu schweigen.
Dieses Verfahren habe ich probeweise implementiert, und es funktioniert bei
kleinen osm-Dateien für ein Gebiet mit etwa 20x20 km Seitenlänge gut. Aber schon
bei der baden-wuerttemberg.osm.bz2 bekomme ich einen out-of-memory-Fehler.

Als Alternative könnten die Daten mit dem Perl-Modul OSM::osm ausgelesen werden.
Da die Knoten, Wege und Relationen in dieser Reihenfolge in der osm-Datei
liegen, müsste die Datei dreimal durgegangen werden, einmal, um die Relation(en)
zu finden, dann die zugehörigen Wege und zuletzt die zugehörigen Knoten. Das
wäre wohl speichermäßig unproblematisch aber ebenfalls sehr zeitaufwendig.
Ausserdem müsste ich die gesamte Programmlogik ändern.

Beim Online-Zugriff über das API werden immer nur genau die Daten abgerufen, die
benötigt werden. Die übertragenen Datenmengen sind daher sehr gering. Außerdem
garantiert diese Methode die höchstmögliche Aktualität der Daten.

Aber wenn mir jemand ein überzeugendes Argument für das extrahieren einzelner
Relationen aus einer lokalen osm-Datei liefert, denke ich nochmals über eine
Implementierung mit OSM::osm nach.

Post by Carsten Gerlach
Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.

Da ich mich weder mit dem OSM-XML-Format noch mit der Erstellung von XML aus
Perl auskenne, sieht es da noch schlechter aus als beim ersten Wunsch. Aber auch
hier würde mich der Anwendungsfall interessieren.

Gruß
Rainer

[Andre Joost]

Post by Rainer Kluge
Aber wenn mir jemand ein überzeugendes Argument für das extrahieren einzelner
Relationen aus einer lokalen osm-Datei liefert, denke ich nochmals über eine
Implementierung mit OSM::osm nach.

Man würde die api bzw den Relation Analyzer schonen, wenn man in einem
Rutsch alle Wanderwege, Rad- oder Busrouten; Grenzen oder
Hochspannungsleitungen seines Bundeslandes als einzelne gpx haben
möchte. Xapi und osmosis bieten da ja leider nur eingeschränkte
Unterstützung.

Post by Rainer Kluge

Post by Carsten Gerlach
Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.

Da ich mich weder mit dem OSM-XML-Format noch mit der Erstellung von XML aus
Perl auskenne, sieht es da noch schlechter aus als beim ersten Wunsch. Aber auch
hier würde mich der Anwendungsfall interessieren.

Anwendungsfall wäre z.B.Rendern als lokale transparente Tiles, die man
als Layer separat in OL einblenden kann. GPX ist da ab einem gewissen
Datenvolumen zu langsam.

Die OSM-Ausgabe ist dagegen ziemlich einfach. Gpx ist ja auch XML; halt
mit anderen keys als OSM. Man müsste nur die tags der Objekte zusätzlich
zwischenspeichern.

Das ganze lässt sich natürlich auch in osmosis einbauen. Ich weiß nur
nicht, ob es da zwischen java und perl (oder ggf C) nenneswerte
Performancevorteile bei der Verarbeitung großer Datenmengen geben würde.
Hat da jemand mal Vergleichstest gemacht?

Bietet denn das neue Binärformat der Geofabrik-Extrakte hier Vorteile
bei der Verarbeitung?

[Hanno Hecker]

On Wed, 06 Oct 2010 17:18:18 +0200

Post by Andre Joost
Das ganze lässt sich natürlich auch in osmosis einbauen. Ich weiß nur
nicht, ob es da zwischen java und perl (oder ggf C) nenneswerte
Performancevorteile bei der Verarbeitung großer Datenmengen geben würde.
Hat da jemand mal Vergleichstest gemacht?
Bietet denn das neue Binärformat der Geofabrik-Extrakte hier Vorteile
bei der Verarbeitung?

geringfügig... OK, der XML-Code is übel, aber viel besser wird's nur,
wenn man es speziell fuer eine Sache schreibt...

Extrahieren aller "amenity=fountain" aus NRW als .osm:
$ time ./osm-extract -P -t amenity -v fountain \
../data/nordrhein-westfalen.osm.pbf > /dev/null
parsing relations done: 0, 0.
parsing ways done: 63, 609.
all parsing done.

real 0m23.109s
user 0m22.521s
sys 0m0.452s
$ time ./osm-extract -X -t amenity -v fountain \
../data/nrw.osm > /dev/null starts: node=93, ways=1389651673,
rel=1948737482 not a <node ...

real 2m7.827s
user 1m28.582s
sys 0m14.805s

... Source folgt irgendwann in den nächsten Tagen

Hanno

[Sven Geggus]

Post by Andre Joost
Anwendungsfall wäre z.B.Rendern als lokale transparente Tiles, die man
als Layer separat in OL einblenden kann. GPX ist da ab einem gewissen
Datenvolumen zu langsam.

Solche Overlay Tiles hätte ich auch gerne, aber leider ist unsere
Serverkapazität für sowas zu begrenzt.

Sven

[André Joost]

Post by Sven Geggus

Post by Andre Joost
Anwendungsfall wäre z.B.Rendern als lokale transparente Tiles, die man
als Layer separat in OL einblenden kann. GPX ist da ab einem gewissen
Datenvolumen zu langsam.

Solche Overlay Tiles hätte ich auch gerne, aber leider ist unsere
Serverkapazität für sowas zu begrenzt.

Wenn man die leeren Tiles gleich nach dem rendern wieder wegwirft, ist
das Datenvolumen erträglich. Transparente Tiles mit ein paar Linien und
Text drauf sind erheblich schlanker als "normale" Tiles.

zum Vergleich NRW in Zoomstufe 13:
Mapnik: 6000 Tiles in 98 MB : 16,4 kB/Tile
Lonvias Wanderwege: 3194 Tiles in 14 MB : 4,4 kB/Tile
Hochspannungsleitungen: 2353 Tiles in 8 MB : 3,8 kB/Tile

Gruß,
André Joost

[Sven Geggus]

Post by André Joost
Wenn man die leeren Tiles gleich nach dem rendern wieder wegwirft, ist
das Datenvolumen erträglich. Transparente Tiles mit ein paar Linien und
Text drauf sind erheblich schlanker als "normale" Tiles.

Teuer an Tileservern ist nicht etwa der Plattenplatz oder die CPU-Last des
renderns selber sondern das tile expire!

OK, zugegeben, wenn man leere Tiles erst gar nicht abspeichert was man in
Tirex aber AFAIK erst einbauen müsste sind das deutlich weniger aber ich
denke nicht dass das angesichts der dichte von Wanderwegen Fahrradwegen oder
ÖPNV Linien wirklich relevant viele leere Tiles sein werden.

Gruss

Sven

[Werner Hoch]

Hallo Rainer,

Post by Rainer Kluge

Post by Carsten Gerlach
Lässt sich das so erweitern, daß man als Quelle eine lokale
osm-Datei (z.B. germany.osm) verwenden kann, aus der die Relation
extrahiert wird?

Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer
Relation aus einer solchen Datei auslesen, dann muss man die
komplette Datei lesen.

Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.

Post by Rainer Kluge
Ein XML-Parser, den ich für die sauberste Lösung halte, stößt da
schon bei Bundesland-Dateien an Speichergrenzen, von der Rechenzeit
ganz zu schweigen. Dieses Verfahren habe ich probeweise
implementiert, und es funktioniert bei kleinen osm-Dateien für ein
Gebiet mit etwa 20x20 km Seitenlänge gut. Aber schon bei der
baden-wuerttemberg.osm.bz2 bekomme ich einen out-of-memory-Fehler.

Das ist nur der Fall wenn du versuchst ein ganzes XML-File im Speicher
zu halten. Mit einem Streaming-Parser muss man nur die nötigsten Infos
im Speicher halten.

Post by Rainer Kluge
Als Alternative könnten die Daten mit dem Perl-Modul OSM::osm
ausgelesen werden. Da die Knoten, Wege und Relationen in dieser
Reihenfolge in der osm-Datei liegen, müsste die Datei dreimal
durgegangen werden, einmal, um die Relation(en) zu finden, dann die
zugehörigen Wege und zuletzt die zugehörigen Knoten. Das wäre wohl
speichermäßig unproblematisch aber ebenfalls sehr zeitaufwendig.
Ausserdem müsste ich die gesamte Programmlogik ändern.

Hier wäre wie vorher beschrieben ein Programm toll, das einen Stream in
umgekehrter Reihenfolge erzeugt (Relationen, Ways, Nodes).

Grüße
Werner

[Rainer Kluge]

Hallo Werner,

Post by Werner Hoch

Post by Rainer Kluge
Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer
Relation aus einer solchen Datei auslesen, dann muss man die
komplette Datei lesen.

Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.

Das funktioniert leider nicht bei bz2-komprimierten osm-Dateien.

Gruß
Rainer

[Peter Körner]

Post by Rainer Kluge
Hallo Werner,

Post by Werner Hoch

Post by Rainer Kluge
Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer
Relation aus einer solchen Datei auslesen, dann muss man die
komplette Datei lesen.

Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.

Das funktioniert leider nicht bei bz2-komprimierten osm-Dateien.

Doch das geht schon, ich hab sogar mal einen Algorithmus hier auf der
Liste gesehen. bz2 ist Blockweise strukturiert. Man kann ungefähr so
vorgehen:

1. setze $anfang = 0 and $ende länge der Datei

2. fseek zur mitte zwischen $anfang und $ende
3. lesen bis zum nächsten block-header
4. lesen & entpacken des nächsten blocks
5. gucken ob <node, <way oder <rel vorkommt, abhängig davon weiß man
in welchem Bereich der Datei man gelandet ist. Wenn man z.B. einen
<way tag sieht aber eine node sucht, muss man weiter nach vorne. Hat
man schon den richtigen Entitäten-Typ gefunden, muss man noch nach
der ID schauen
6a. wenn man weiter nach vorne will setzt man $ende = $mitte
6b. wenn man weiter nach hinten will setzt man $anfang = $mitte
7. springe zu 2.

Lg

[Rainer Kluge]

Hallo Peter,

Post by Peter Körner

Post by Rainer Kluge

Post by Werner Hoch
Nein. Geht man davon aus, dass die Objekte in der osm-Datei sortiert
sind, dann kann man per binärer Suche die richtigen Objekte raussuchen.

Das funktioniert leider nicht bei bz2-komprimierten osm-Dateien.

Doch das geht schon, ich hab sogar mal einen Algorithmus hier auf der
Liste gesehen. bz2 ist Blockweise strukturiert.

Ich verwende für den Zugriff auf die osm-Datei das Perl-Modul OSM::osm von
gary68. Die ganzen Zugriffe für meinen Bedarf neu zu schreiben, halte ich nicht
für sinnvoll. Wenn Gary diesen Algorithmus einbaut, dann kann ein breites
Punblikum davon profitieren, z.B. die Nutzer seines Skripts checkrelation.pl.

Grüße
Rainer

[Carsten Gerlach]

Hallo,

Post by aighes
Hallo,

Post by Carsten Gerlach
Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei
(z.B. germany.osm) verwenden kann, aus der die Relation extrahiert wird?

Das wäre machbar aber äußerst ineffizient. Die osm-Dateien sind reine
Textdateien im XML-Format. Will man die Wege und Knoten einer Relation aus
einer solchen Datei auslesen, dann muss man die komplette Datei lesen.
Ein XML-Parser, den ich für die sauberste Lösung halte, stößt da schon bei
Bundesland-Dateien an Speichergrenzen, von der Rechenzeit ganz zu
schweigen. Dieses Verfahren habe ich probeweise implementiert, und es
funktioniert bei kleinen osm-Dateien für ein Gebiet mit etwa 20x20 km
Seitenlänge gut. Aber schon bei der baden-wuerttemberg.osm.bz2 bekomme ich
einen out-of-memory-Fehler.
Als Alternative könnten die Daten mit dem Perl-Modul OSM::osm ausgelesen
werden. Da die Knoten, Wege und Relationen in dieser Reihenfolge in der
osm-Datei liegen, müsste die Datei dreimal durgegangen werden, einmal, um
die Relation(en) zu finden, dann die zugehörigen Wege und zuletzt die
zugehörigen Knoten. Das wäre wohl speichermäßig unproblematisch aber
ebenfalls sehr zeitaufwendig. Ausserdem müsste ich die gesamte
Programmlogik ändern.
Beim Online-Zugriff über das API werden immer nur genau die Daten
abgerufen, die benötigt werden. Die übertragenen Datenmengen sind daher
sehr gering. Außerdem garantiert diese Methode die höchstmögliche
Aktualität der Daten.
Aber wenn mir jemand ein überzeugendes Argument für das extrahieren
einzelner Relationen aus einer lokalen osm-Datei liefert, denke ich
nochmals über eine Implementierung mit OSM::osm nach.

Wie Andre schon schrieb, man schont die API. Ich habe zum Beispiel alle
Relationen mit admin_level=2 über die XAPI runtergeladen (zur Zeit ca. 700
MB). Wenn ich jetzt alle diese Relationen nochmal über die API hole, lade ich
vielleicht ca. 1 GB runter, weil ja viele Wege in zwei Relationen drin sind.

Post by aighes

Post by Carsten Gerlach
Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.

Da ich mich weder mit dem OSM-XML-Format noch mit der Erstellung von XML
aus Perl auskenne, sieht es da noch schlechter aus als beim ersten Wunsch.
Aber auch hier würde mich der Anwendungsfall interessieren.

Ich möchte gern jede Relation für sich als Bild rendern, und das kann z.B.
mapgen.pl sehr gut.


Als generell andere Idee hatte ich schon, die 700-MB-Datei in eine Datenbank
zu packen. Wenn ich dann "Gib mir Relation 1234 mit allen Knoten und Wegen als
osm-Datei raus." sagen kann, wäre ich auch zufrieden. In der Datenbank
(PostgreSQL mit Postgis) hab ich die Daten schon (nach der Anleitung im Wiki),
bloß mit der Abfrage weiß ich noch nicht weiter. Oder kann man der lokalen
Mapnik-Installation sagen, das er nur Relation XYZ rendern soll?

Gruß, Carsten

[Rainer Kluge]

Danke für die nützlichen Hinweise. Ich habe jetzt einen Ansatz gefunden, mit dem
ich beide Erweiterungsvorschläge von Carsten erledigen kann. Ich melde mich hier
wieder, wenn es funktioniert.

Grüße
Rainer

[Carsten Gerlach]

Hallo,

Post by Rainer Kluge
Danke für die nützlichen Hinweise. Ich habe jetzt einen Ansatz gefunden,
mit dem ich beide Erweiterungsvorschläge von Carsten erledigen kann.

Super, freut mich, daß du das umsetzt. :-)

Gruß, Carsten

[Werner Hoch]

Post by Carsten Gerlach

Post by Rainer Kluge
In einer Zeit, als der Realtion Analyzer extrem langsam war, habe
ich mal ein Perl-Skript gebastelt, welches zu einer Relation-Id
den GPX-Track erzeugt.

Tolle Sache, gefällt mir, vorallem das verschachtelte Relationen
komplett runtergeladen werden. :-)
Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei
(z.B. germany.osm) verwenden kann, aus der die Relation extrahiert
wird?

Vor einiger Zeit gabs dazu mal einen Thread:
http://www.mail-archive.com/talk-***@openstreetmap.org/msg71643.html
(lokaler Webserver, der OSM-ähnliche API-Zugriffe auf eine lokale OSM-
Datei zulässt). Der Webserver

Im Angebot habe ich nur den Zugriff auf einzelne OSM-Objekte, keinen
rekursiver Zugriff auf Objekte, wie für komplette Relationen
erforderlich wäre.

Den Zugriff auf unkomprimierte osm-Dateien wollte ich auch mal einbauen,
Im Moment würde mir das aber nichts bringen, weil ich nicht genug
Plattenplatz für einen unkomprimierten planet habe.

Post by Carsten Gerlach
Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei ensteht.
Wäre super wenn das umsetzbar wäre. :-)

Hier sollte man den umgekehrten weg gehen. Relation zuerst aus der OSM-
Datei extrahieren und dann in GPX umwandeln.


Weitere Idee:
Ein Tool, dass die OSM-Datei in umgekehrter Form direkt aus einer bz2-
Datei streamt. (Relationen, Ways, Nodes)

Den Stream kann man dann mit einem Streaming-Parser (SAX)
weiterverarbeiten ohne das man massenhaft Speicher benötigt.
Für alle Probleme bei denen man zuerst die Relationen benötigt muss man
die Datei nur noch einmal parsen.

Link zu meinem Repo:
http://github.com/werner2101/python-osm

Grüße
Werner

[Rainer Kluge]

Hallo,

Post by Carsten Gerlach
Lässt sich das so erweitern, daß man als Quelle eine lokale osm-Datei (z.B.
germany.osm) verwenden kann, aus der die Relation extrahiert wird?

Ich habe eine neue Version zum Download bereitgestellt:
http://mr-unseld.de/?q=de/node/170

Man kann jetzt eine lokale osm-Datei als Datenquelle nutzen. Allerdings ist der
Zugriff sehr zeitintensiv, vor allem bei bz2-codierten Dateien. Der Zugriff
erfolgt über das Modul osm.pm von Gary68. Hierzu muss die neueste Version dieses
Moduls installiert sein.

Post by Carsten Gerlach
Der zweite Wunsch wäre, das als Ergebnis wieder eine osm-Datei entsteht.

Auch das habe ich eingebaut, allerdings funktioniert es nur, wenn die Quelle
eine lokale osm-Datei ist.

Die wichtigste Beschränkung des Skripts betrifft Routen mit zwei Fahrtrichtungen
(role=forward/backward, oneway). Diese Routen werden nur eingeschränkt
unterstützt. Insbesondere wird nur der GPX-Track für eine der beiden
Fahrtrichtung erzeugt, die Segmente für die andere Richtung werden als Schnipsel
in den Track aufgenommen.

Das ganze hat Beta-Status. Für Hinweise auf Fehler bin ich dankbar, ebenso für
Änderungs- und Verbesserungsvorschläge.

Grüße
Rainer

[Carsten Gerlach]

Naabend,

Post by Rainer Kluge
http://mr-unseld.de/?q=de/node/170

Super, vielen Dank.

Post by Rainer Kluge
Das ganze hat Beta-Status. Für Hinweise auf Fehler bin ich dankbar, ebenso
für Änderungs- und Verbesserungsvorschläge.

Beim ersten Test mit der osm-Ausgabe habe ich festgestellt, daß JOSM die Datei
anmeckert: Ein Zeilenumbruch in der ersten Zeile ist falsch und das <osm>-
Objekt wird zweimal erstellt.

$ diff test_falsch.osm test_richtig.osm
1,2c1,2
< <?xml version="1.0" encoding="UTF-8"?>\n<osm version='0.6' enerator='JOSM'>
< <osm>
---

Post by Rainer Kluge
<?xml version="1.0" encoding="UTF-8"?>
<osm version='0.6' generator='JOSM'>

Gute Nacht, nächste Woche teste ich weiter. :-)

Gruß, Carsten

[Walter Nordmann]

<?xml version="1.0" encoding="UTF-8"?>\n<osm version='0.6' enerator='JOSM'>
moin moin,

hier noch ein fast ungebrauchtes "g" zum einbauen, damit aus dem enerator
wieder ein generator wird. ;)
lg
walter

-----
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg