Pois für eigene Karte

Du solltest die Ausgangsdaten um deine Punkte im OSM-Format ergänzen. Dabei sind ausreichend hohe IDS zu verwenden.

Danke für den hinweiß.
Habe es gerade nochmals nachgestellt und es war die fehlermeldung "negative id".
Also habe ich id="-* ersetzt durch id="99875*.

Neuer versuch zu mergen, neue fehlermeldung 🤣
"The entity timestamp attribute is missing"
OK.. mit osmconvert die datei mit dem parameter "--timestamp=2011-08-01T23:50:00Z" convertiert.
Jedoch bekomme ich dieselbe Fehlermeldung.

Der Datei Header sieht folgendermasen aus

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version="0.6"␣generator="osmconvert␣0.8.8"␣timestamp="2011-08-01T23:50:00Z">
<bounds␣minlat="47.18741"␣minlon="7.37222"␣maxlat="49.80469"␣maxlon="10.52081"/>
<node␣id="989756163765"␣lat="48.5575002"␣lon="9.4054834"␣version="1">
<tag␣k="created_by"␣v="GPSBabel-1.5.4"/>
<tag␣k="natural"␣v="tree"/>
</node>
<node␣id="989756163767"␣lat="48.5580834"␣lon="9.4120833"␣version="1">
<tag␣k="created_by"␣v="GPSBabel-1.5.4"/>
<tag␣k="natural"␣v="tree"/>
</node>

Ich sehe gerade in der OSM XLM definition dass jedes node einen eigenen timestamp benötigt.
Gibt es ein Tool mit welchem man diesen nachtragen lassen kann, oder muss ich wirklich mit dem text editor ran??

Ja, jeder Punkt benötigt ein timestamp und diverse andere Daten.
Hier ein Beispiel eines realen Punktes aus OSM:

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣generator='JOSM'>
<bounds␣minlat='54.0770259'␣minlon='9.9895495'␣maxlat='54.0771581'␣maxlon='9.9898285'␣origin='CGImap␣0.6.1␣(20227␣thorn-01.openstreetmap.org)'␣/>
<node␣id='6020181081'␣timestamp='2018-11-08T19:51:54Z'␣uid='50299'␣user='Todeskuh'␣visible='true'␣version='2'␣changeset='64304857'␣lat='54.0771313'␣lon='9.9896595'>
<tag␣k='building'␣v='yes'␣/>
<tag␣k='name'␣v='Insanto␣Seniorenresidenz␣Klosterbad'␣/>
<tag␣k='social_facility'␣v='nursing_home'␣/>
</node>
</osm>

tags gekürzt.

OK, problem erkannt...
jetz frage ich mal ganz naiv 😎
Gibt es kein tool mit welchem man anhand von koordinaten eine korrekt formatierte osm xml datei erhält?
Oder wie wie würde euer workflow in soeinem fall aussehen?

Wie sehen denn deine Ausgangsdaten (POIs) aus?

Die größte Datenmenge liegt mir in einer CSV Datei in dieser Formatierung vor.

id,type,lat,lon,name,climbrate,climbseconds,climbmeters,windsourcedeg,windspeed,class,icon,createddatetime,altitude
350,0,47.8302,16.0462,TOF088,0,0,0,0,0,T,66,2012-03-24␣10:33:00,2884
349,0,47.6818,15.0921,EW1249,1,50,53,273,95,E,12,2012-03-24␣12:19:00,8173
348,0,47.7851,15.5047,EE1229,1,71,75,103,26,E,12,2012-03-24␣11:44:00,7520
347,0,47.7002,15.1422,EE1225,1,60,87,62,75,E,12,2012-03-24␣12:09:00,7382
346,0,47.6875,15.1016,EE1220,1,50,69,57,37,E,12,2012-03-24␣12:12:00,7231
345,0,47.8295,16.0486,EE1089,1,60,50,117,12,E,12,2012-03-24␣10:38:00,2913

Dann habe ich noch diverse andere in WPT.

G␣␣WGS␣84
U␣␣1
W␣␣AE1006␣A␣52.846901°N␣12.8196°E␣D␣T␣0␣0
W␣␣AE1009␣A␣51.996101°N␣12.968°E␣D␣T␣0␣0
W␣␣AE1010␣A␣51.9958°N␣12.9706°E␣D␣T␣0␣0
W␣␣AE1010␣A␣51.996201°N␣12.9743°E␣D␣T␣0␣0

Steffen_J wrote:

Die größte Datenmenge liegt mir in einer CSV Datei in dieser Formatierung vor.

CSV kann man mit demOpendata-Plugin nach JOSM laden und dann als OSM XML speichern. Der Feldtrenner muss ";" sein. Es sollte auch mit gpsbabel gehen. Das hätte den Vorteil, dass man das automatisiert aus der Kommandozeile machen kann.

Fake-Metadaten wie Timestamp und User kann man mit osmfilter hinzufügen.

rainerU wrote:

Fake-Metadaten wie Timestamp und User kann man mit osmfilter hinzufügen.

Für timestamp braucht man gar keine fake-Daten - man braucht nur createddatetime in timestamp umzubenennen.
Dann noch altitude in ele und name in ref, dann kommt das Ergebnis von gpsbabel dem OSM-Format gleich viel näher.

Steffen_J wrote:

ich möchte mir eigene Karten aus den OSM Daten generieren.
Das Endergebnis soll eine sehr abgespeckte Karte sein welche zur Orientierung aus der Luft herangezogen wird.

"Karte" ist ein sehr weitreichender Begriff - von einem Stück Papier zum Falten bis zu Anzeige auf einem mobilen Gerät.

Wie, womit und wo soll deine Karte dargestellt werden?

Gruss
walter

Also für eine gedruckte Karte im ICAO Maßstab 1:500.000 dürften 200.000 Punkte eventuell zu viel sein. Also gehe ich jetzt einfach mal von einer Anwendung/Anzeige auf einem Tablet aus.

mapsforge = android oder pc

Harald Hartmann wrote:

Also gehe ich jetzt einfach mal von einer Anwendung/Anzeige auf einem Tablet aus.

Ich gehe bei solchen Fragen von nix mehr aus 😉

Gruss
walter

@toc-rox, Harald Hartmann
Exakt! Genauer gesagt geht es um Katen welche in XCTrack, ein tacktischer Flugcomputer für Gleitschirmflieger welcher auf Android läuft, dargestellt werden sollen. Es gibt hier zwar Themes welche nicht den vollen Katenumfang darstellen, jedoch wird das ganze bei älteren geräten auf grund der Kartengröße sehr träge.
Um genau zu sein liegen mir nur für Deutschland ca. 1Mio Punkte vor welche jedoch, wie man im csv ev. erkennen kann, nach wertigkeit gefiltert werden können. Die Daten wurden mit Track2Thermik aus dem DHV-XC generiert.
Wieviel schlussendlich auf die Karte kommen muss ich noch genau prüfen, denke es werden etwas weniger als 200.000.

@wambacher
Kann ich navolziehen, mir geht es manchmal bei den dingen wo ich mich auskenne ähnlich 😉

Ich bedanke mich jedenfalls bei allen wo einem Laie wie mir auf die sprünge helfen und auf dem Weg zum Ziel erheblich weiterbingen. 🙂

Ich hatte ja schon mal versucht, eine icao.render.xml für OsmAND zu schreiben, bin da aber auch eher gescheitert und nicht wirklich weitergekommen. Vielleicht versuche ich die Tage mal zumindest mit Maperitive ein entsprechendes Ergebnis hinzubekommen ... ich denke ich werde mich da zunächst mal an Kosmos ICAO Map Germany Rules halten.

@Steffen_J: kannst du uns oder mir per PN noch verraten, um was es sich genau bei diesen 200.000 Punkte handelt? Ich meine wir haben in Deutschland doch keine 200.000 Start und Landeplätze, oder? Oder sind es Peaks von Thermiken/Hausbärten? - ja, hätte ich mal die letzten Antwort nochmal durchgelesen, scheint ja fast so, als möchtet du so eine Art "HeatMap" nachstellen, oder?

Interessant welche Infos du zum gestalten einer ICAO Karte zusammengefasst hast!
Vielleicht wird das ja mal noch ein Projekt für unserer Homepage 😉
Willst du die erzeugte Karte in der Luft oder zum Planen am Boden nutzen?

Passt schon auch hier..
Ja das sind alles potenzielle Thermik Abrissstellen wo aus ca. 20000 Flüge über 50km aus dem DHV-XC berechnet wurden. Für die Berechnung wurde aus den Kreißen beim kurbeln ein Vektor gebildet und dieser mit der Erdoberfläche geschnitten. Ebenso wurde die Windrichtung Thermikstärke und Höhengewinn berechnet. Du kannst dir ja vorstellen, dass die Abrissstellen nicht sonderlich genau sind unter anderem durch die unterschiedlichen Windrichtungen in den Luftschichten.
Und da ja jeder Tag durch die meteorologischen Einflüsse anders ist dienen die Informationen vor allem im Flachland lediglich dazu in der Luft zu erkennen welche Gebiete Potential haben könnten. Also vielleicht 20% Entscheidungshilfe…
Die Haubärte werde ich eher herausschneiden da sonnst in den fluggebieten nichts mehr vom rest zu sehen ist.

Steffen_J wrote:

Interessant welche Infos du zum gestalten einer ICAO Karte zusammengefasst hast!
Vielleicht wird das ja mal noch ein Projekt für unserer Homepage

https://www.openflightmaps.org existiert 🙂

--ks

kreuzschnabel wrote:

https://www.openflightmaps.org existiert

--ks

Kenne ich 😉
Ich dachte ein paar Nummern kleiner..
Eine Übersichtskarte mit Fluggebietsrelevanten Infos.

Ich habe gestern nun die erste Karte erzeugt, erstmal nur ein Bundesland.
Entspricht schon annehernd dem was ich mir vorstelle, naja mal vom feintunig abgesehen.
Dann wolte ich gesamt Deutschland erzeugen bekomme jedoch den fehler "BufferOverflowException" beim erzeugen der *.map.
Die Einzeldaten, Karte oder Punkte laufen vor dem mergen durch.
Hat jemand eine Idee wo ich ansetzen muss um den Fehler zu beseitigen?

D:\osm\Karten\mapsforge\deutschland>C:\Windows\System32\cmd.exe␣/k␣"osmosis"␣--rx␣file=D:\osm\Karten\OSM-gefiltert\germany-latest_Filter_V1_thermik-dhv.osm␣outPipe.0=1␣--log-progress␣inPipe.0=1␣outPipe.0=2␣--mw␣file=germany-latest_Filter_V1_thermik-dhv.osm.map␣tag-conf-file=D:\osm\Programme\osmosis\Mapsforge-Tag\Tag-Mapping_V2.xml␣inPipe.0=2
VM␣settings:
Max.␣Heap␣Size:␣10.00G
Ergonomics␣Machine␣Class:␣client
Using␣VM:␣Java␣HotSpot(TM)␣64-Bit␣Server␣VM

Mõr␣03,␣2019␣11:55:25␣AM␣org.openstreetmap.osmosis.core.Osmosis␣run
INFORMATION:␣Osmosis␣Version␣0.47
Mõr␣03,␣2019␣11:55:25␣AM␣org.openstreetmap.osmosis.core.Osmosis␣run
INFORMATION:␣Preparing␣pipeline.
Mõr␣03,␣2019␣11:55:25␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣<init>
INFORMATION:␣mapfile-writer␣version:␣mapsforge-map-writer-0.10.0
Mõr␣03,␣2019␣11:55:25␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣<init>
INFORMATION:␣mapfile␣format␣specification␣version:␣3
Mõr␣03,␣2019␣11:55:25␣AM␣org.openstreetmap.osmosis.core.Osmosis␣run
INFORMATION:␣Launching␣pipeline␣execution.
Mõr␣03,␣2019␣11:55:25␣AM␣org.openstreetmap.osmosis.core.Osmosis␣run
INFORMATION:␣Pipeline␣executing,␣waiting␣for␣completion.
Mõr␣03,␣2019␣11:55:25␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣process
INFORMATION:␣start␣reading␣data...
Mõr␣03,␣2019␣11:55:30␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Node␣158780187,␣222361.7276544691␣objects/second.
Mõr␣03,␣2019␣11:55:35␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Node␣487312437,␣426138.3723255349␣objects/second.
Mõr␣03,␣2019␣11:55:40␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Node␣1693565140,␣396550.2899420116␣objects/second.
Mõr␣03,␣2019␣11:55:46␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Node␣3357084205,␣322065.97057427623␣objects/second.
Mõr␣03,␣2019␣11:55:51␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Way␣26469986,␣340619.676064787␣objects/second.
Mõr␣03,␣2019␣11:55:56␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Way␣146034226,␣86913.4173165367␣objects/second.
Mõr␣03,␣2019␣11:56:01␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣process
INFORMATION:␣Processing␣Way␣321462786,␣77387.1225754849␣objects/second.
Mõr␣03,␣2019␣11:56:04␣AM␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger␣complete
INFORMATION:␣Processing␣completion␣steps.
Mõr␣03,␣2019␣11:56:04␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣complete
INFORMATION:␣completing␣read...
Mõr␣03,␣2019␣11:56:04␣AM␣org.mapsforge.map.writer.RAMTileBasedDataProcessor␣complete
INFORMATION:␣handle␣relations...
Mõr␣03,␣2019␣11:56:05␣AM␣org.mapsforge.map.writer.RAMTileBasedDataProcessor␣complete
INFORMATION:␣handle␣ways...
Mõr␣03,␣2019␣11:56:15␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣complete
INFORMATION:␣start␣writing␣file...
Mõr␣03,␣2019␣11:56:15␣AM␣org.mapsforge.map.writer.osmosis.MapFileWriterTask␣complete
INFORMATION:␣overwriting␣file␣D:\osm\Karten\mapsforge\deutschland\germany-latest_Filter_V1_thermik-dhv.osm.map
Mõr␣03,␣2019␣11:56:16␣AM␣org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager␣waitForCompletion
SCHWERWIEGEND:␣Thread␣for␣task␣1-rx␣failed
java.nio.BufferOverflowException
at␣java.nio.HeapByteBuffer.put(Unknown␣Source)
at␣java.nio.ByteBuffer.put(Unknown␣Source)
at␣org.mapsforge.map.writer.MapFileWriter.processPOI(MapFileWriter.java:515)
at␣org.mapsforge.map.writer.MapFileWriter.processTile(MapFileWriter.java:862)
at␣org.mapsforge.map.writer.MapFileWriter.writeSubfile(MapFileWriter.java:978)
at␣org.mapsforge.map.writer.MapFileWriter.writeFile(MapFileWriter.java:376)
at␣org.mapsforge.map.writer.osmosis.MapFileWriterTask.complete(MapFileWriterTask.java:113)
at␣org.openstreetmap.osmosis.core.progress.v0_6.EntityProgressLogger.complete(EntityProgressLogger.java:82)
at␣org.openstreetmap.osmosis.xml.v0_6.XmlReader.run(XmlReader.java:92)
at␣java.lang.Thread.run(Unknown␣Source)

Mõr␣03,␣2019␣11:56:16␣AM␣org.openstreetmap.osmosis.core.Osmosis␣main
SCHWERWIEGEND:␣Execution␣aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException:␣One␣or␣more␣tasks␣failed.
at␣org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
at␣org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
at␣org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
at␣sun.reflect.NativeMethodAccessorImpl.invoke0(Native␣Method)
at␣sun.reflect.NativeMethodAccessorImpl.invoke(Unknown␣Source)
at␣sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown␣Source)
at␣java.lang.reflect.Method.invoke(Unknown␣Source)
at␣org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at␣org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at␣org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at␣org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at␣org.codehaus.classworlds.Launcher.main(Launcher.java:47)

D:\osm\Karten\mapsforge\deutschland>

Steffen_J wrote:

Max. Heap Size: 10.00G

So wie es aussieht, reicht das nicht.

seichter wrote:

Steffen_J wrote:

Max. Heap Size: 10.00G

So wie es aussieht, reicht das nicht.

Der Prozess nutzt nicht mal ganz 4gb vor dem abbruch. Mit dem Parameter type=hd, gleicher fehler.
Dem Gesamtsytem stehen 16gb zur verfügung.
Die ausgans- *.osm hat 1.8gb.

Bin das Problem jetzt erst mal umgangen indem ich in der "tag-mapping.xml" den zoom-appear=* meiner Punkte von 6 auf 8 erhöht habe.
Hier muss ich eh noch schauen welche Werte sinnvoll sind.

Eine Frage hätte ich nun aber noch:
Gibt es festgelegte Nummernkreise für die id's der Notes, Ways etc.?
Hatte das Phänomen das Railways gradlinig von einigen meiner Notes durch die Karte verliefen.
Nachdem ich den Nummernkreis meiner Notes änderte war alles wieder korrekt.

Und gibt es eine Möglichkeit überprüfen zu lassen ob id's doppelt vergeben sind?

Du kannst mit osmconvert für jede Gruppe (nodes, ways, rels) die jeweils höchste ID für eine pbf-Datei ermitteln. Deine eigenen IDs wählst du dann einfach deutlich größer.

Steffen_J wrote:

Gibt es festgelegte Nummernkreise für die id's der Notes, Ways etc.?

Nein, da jeder Typ in einer eigenen Tabelle mit eigener ID gespeichert wird, ganz vereinfacht haben alle mal bei 1 angefangen, und deswegen ist es eben wichtig neben der ID immer den Typ zu nennen.

Steffen_J wrote:

Gibt es festgelegte Nummernkreise für die id's der Notes, Ways etc.?

Jain.

Jeder Objekttyp (Node, Way und Relation) hat sowas wie einen eigenen Nummernkreis.

OSM-Objekte werden auf dem Zentralserver in einer PostgreSQL-Datenbank in drei separaten Tabellen gespeichert. "Damals" starteten alle Ids mit "1" und jedes neues Objekt erhält eine um 1 erhöhte Id (Typ "serial" in SQL), wobei die Ids nicht wiederverwendet werden, falls das Objekt gelöscht wurde.

Derzeit liegen die Ids bei 6.315.507.175 (Nodes), 674.359.628 (Ways) und 9.370.910 (Relationen) - wobei die Werte jetzt schon veraltet sind.

Addiere einfach zu "deinen" Objekten eine ausreichend große Zahl (z.B. 100.000.000.000 bei den Nodes), dann solltest du für mehrere Jahre Ruhe haben.

Gruss
walter

Perfekt 🙂
Solche Infos sind goldwert um zu verstehen und prüfen zu können.

Ich danke euch!

wambacher wrote:

Derzeit liegen die Ids bei 6.315.507.175 (Nodes), 674.359.628 (Ways) und 9.370.910 (Relationen) - wobei die Werte jetzt schon veraltet sind.

Bei den Nodes sind wir schon über 32 Bit hinaus (Da gab es doch mal was?). Bei 64 Bit sind es schon 19 Zehnerstellen (16 EiB), da darf man schon weit über die vorgeschlagenen 100 Mrd hinaus. Ganz sicher ist man allerdings nicht: Der DB-Administrator könnte theoretisch auf die Idee kommen, aus irgend einem Grund das Hochzählen irgendwo weiter oben im Zahlenraum neu anzufangen. Aber selbst bei diesem unwahrscheinlichen Fall hat man gute Chancen, dass der Startwert weit oberhalb oder weit unterhalb des eigenen Nummernraumes liegt.