Neue Version 0.85 von Map Composer

...und hier noch der Link zum Download: http://composer.waldpfa.de/index.php/MC/Download

Super, vielen vielen Dank!
Jetzt klappt's und wir sind bereit für Tansania!! :-)

aighes wrote:

...und hier noch der Link zum Download: http://composer.waldpfa.de/index.php/MC/Download

Wußte doch das irgendwas fehlt... :-)

aighes wrote:

...und hier noch der Link zum Download: http://composer.waldpfa.de/index.php/MC/Download

Hallo Henning,

ich hab Deinen post aus der 084 gesehen bei dem es um den Batchmodus geht. Ich hab jetzt schon viel probiert aber irgendwie komme ich nicht zum Start meiner Jobs. Aus der knappen Anleitung werde ich leider auch nicht schlauer. Kannst Du mir ein Muster oder einen kurzen Tipp zum Start geben?

Danke und viele Grüße
Frank

Klar:
C:\Programme\Java\jre6\bin\java.exe -Xmx7000M -cp map_composer.jar;ndsc15.jar;nop.jar;stax-1.2.0.jar;colorpicker.jar;bzip2.jar nop.osmc.MapComposer -job Denmark

Dieser Aufruf berechnet bei mir den Job mit dem Namen Denmark. Das ist der normale Aufruf aus der start.bat ergänzt um {Leerzeichen}-job{Leerzeichen}[Jobname]

aighes wrote:

Klar:
C:\Programme\Java\jre6\bin\java.exe -Xmx7000M -cp map_composer.jar;ndsc15.jar;nop.jar;stax-1.2.0.jar;colorpicker.jar;bzip2.jar nop.osmc.MapComposer -job Denmark

Dieser Aufruf berechnet bei mir den Job mit dem Namen Denmark. Das ist der normale Aufruf aus der start.bat ergänzt um {Leerzeichen}-job{Leerzeichen}[Jobname]

Danke Henning!
Das Leben kann so einfach sein... Man muß nur wissen wie!
Alles bestens, ich bin über die "Klammern" in der Anleitung gestolpert, das ist sicher für IT-Cracks klar aber nicht für den normalen Composer-Verbraucher.

Besten Dank
Frank

osmFrank wrote:

Das Leben kann so einfach sein... Man muß nur wissen wie!
Alles bestens, ich bin über die "Klammern" in der Anleitung gestolpert, das ist sicher für IT-Cracks klar aber nicht für den normalen Composer-Verbraucher.

Hast Du eine allgemeinverständliche Formulierung dafür? Dann nehme ich sie gerne in die Anleitung auf.

bye
Nop

Wie wäre es mit einem Beispiel? Die spitzen Klammern sind ja ansonsten die übliche Nomenklatur.

Nop wrote:

osmFrank wrote:

Das Leben kann so einfach sein... Man muß nur wissen wie!
Alles bestens, ich bin über die "Klammern" in der Anleitung gestolpert, das ist sicher für IT-Cracks klar aber nicht für den normalen Composer-Verbraucher.

Hast Du eine allgemeinverständliche Formulierung dafür? Dann nehme ich sie gerne in die Anleitung auf.

bye
Nop

Das war nicht bös gemeint... Sicher wäre aber das Muster welches Henning mir im Klartext gezeigt hat als Beispiel verständlicher. Evtl. auch kurz die Datei nennen in der die Ergänzung erfolgen muss (start.bat) würde bestimmt hilfreich für Einsteiger sein. Das sollte dann schon reichen denke ich.

Danke nochmals, jetzt geht es einwandfrei!
Frank

PS: Zusätzlich hatte ich auch noch wie bei den anderen *.jar aufrufen eine Semikolon als Trennung vor den -job gesetzt. Da konnte es wohl auf keinen Fall gehen.

Hallo,
ich versuche mich gerade in den Map Composer einzuarbeiten und habe einmal die Beispielkarte durchlaufen lassen. Leider wird für die Beispielkarte kein Garminkarte (zip) erzeugt.
Ich bekomme die Fehlermeldung:

Build the garmin maps
calling mkgmap
mkgmap call failed!
Generation finished

In der Datei Commands.log steht dann folgende Fehlermeldung:

rem Build the garmin maps

java -Xmx1100M -jar C:\Programme\OSM\MapComposer\Tools\mkgmap.jar --gmapsupp --family-name=OSMC Beispiel --family-id=79 --product-id=1 --description="OSMC Beispielkarte" 79990001.img 79990002.img 79990000.TYP

Could not open file: Beispielkarte
Exception in thread "main" java.lang.NullPointerException
at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:136)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:369)
at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:122)

Leider kann ich damit nichts anfangen.
Was mache ich falsch?

Für Hilfe wäre ich dankbar.

Grüße
surveyor54

Hi!

Das wird durch einen Fehler in mkgmap verursacht. Normalerweise sollte es die Anweisung --description="OSMC Beispielkarte" verstehen, tut es aber neurdings nicht mehr.

Abhilfe:
- Den Beispiel-Job in Map Composer öffnen
- Auf den Reiter "Parameter" gehen
- Das Leerzeichen in "OSMC Beispielkarte" entfernen, z.B. "OSMC_Beispielkarte"

Dann sollte es laufen.

bye
Nop

Hat funktioniert, danke für die Hilfe und Grüße

surveyor54

Hi,
ich hätte eine generelle Frage zur Funktionalität vom Map Composer (V.085).

Ich würde gerne eine Overlay erzeugen, welches ausschließlich die Routenmarkierungen incl. Wegsymbole enthält um dieses über eine Rastertopo zu legen. Wege als solche möchte ich nicht haben.
Leider gelingt es mir nicht Route_outlines(und/oder route_marker=marker_black etc.) zu erzeugen welche den Wegnamen des Ursprungsweges + Routensymboltext beinhalten(Bsp:STEINBRUCHSWEG [X22] [<5] [A1] [A3]).
Diese erhalte ich jedoch nur in Verbindung mit den "richtigen" Wegobjekten.

Nach etlichen Stunden der Probiererei vermute ich im Moment, ds dies mit dem Composer nicht geht.
Die Routenmarkierungsobjekte werden wohl in dem Datenaufbereitungsprozess erzeugt und eine Kopie des Namens ist nicht vorgesehen und kann später auch nicht mehr erzeugt werden.
Dies ist im Gesamtkonzept einer vollständigen Karte ja auch nicht notwendig, da die Namen ja in den eigentlichen Wegobjekten vorhanden sind.

Gibt es vielleicht doch eine Vorgehensweise wie ich mein obiges Anliegen(Marlierungslinie der Routen incl. der ursprünglichen Wegnamen) realisieren kann.?

Dank i.v für Tips oder auch ein klares No geht nicht.

Gruss
Gert

Hi!

Habe sowas noch nie probiert. Wegemarkierungen werden immer zusäztlich erzeugt, da kann man nichts dazutexten.

Was ich mal probieren würde, ist die Originalwege samt Text drin zu lassen, aber die Darstellung des Wegetyps optisch unsichtbar zu machen. Das sollte den gewünschten Effekt haben.

bye
Nop

Mit dem Composer fällt mir nur der Weg ein, transparente png's für die Wege zu nutzen. Das ändert dann aber nichts an der Datenmenge.

Mit mkgmap geht zumindest das Rendern der Wege zu selektieren. Hier istanders als im Composer eine Verknüpfung von Relationen und Linien möglich (Vererbung). Hier wird man aber Problmem bei den Symbolen für die Wege haben. Da fällt mir gerade kein Weg ein.

Hallo NOP, Hallo Henning
danke für eure Tips, deren Inhalt mir aber leider schon bekannt ist.
Das transparentmachen für unerwünschte Objekte hatte ich erstmal verworfen.
Die Datenmengen sind für mich da einfach grenzwertig Gründe: altersschwacher Rechner (Pentium 4 2,6 GHZ 1GB RAM), und die IMG sind nur Zwischenprodukt um via MP in ein TwoNav taugliches MPVF-Format weiterverarbeitet zu werden.
Auf die Namensinformation würde ich ungern verzichten, auch wenn es letztlich die einfachste Lösung wäre.

Dann werde ich wohl doch mal schauen müssen, wie hoch der Aufwand wird um die Relationen via mkgmap rauszufiltern und diese dann im 2ten Schritt mit den via Composer erstellten Symbolen zu vereinen.
In mkgmap gibt es afaik keinen Weg Symbole entsprechend wie Composer es macht, zu generieren.

Trotzdem vielen Dank für eure Antworten
Gert

Hallo Gert
Ich bin mir nicht sicher, ob folgendes zum von Dir gewünschten Effekt führt:
- In der Maske "Route-Eintrag" im Feld "Textmarkierung" eine von Dir gewählte Bezeichnung des Wanderweges eintragen.
- für Textfarbe das leere Feld auswählen
Dadurch wird der Text nicht mehr auf das Schildchen sondern als Name an den Weg geschrieben (so war es jedenfalls noch in Composer 0.84).
Ist der Weg mit mehreren Routen verknüpft, werden alle Routennamen hintereinander an den Weg geschrieben und wenn dieser ein Name-Tag hat, steht dieser am Anfang des "Wurms".

Die "Schildchen" sind dann allerdings ohne Text. (!!!)
Um dieses Manko auszugleichen, erstellte ich mir für einen überschaubaren Bereich Wanderwegsymbole mit Buchstaben und Zahlen. Auf diese Weise sehe ich nun beides auf der Karte: Die Schildchen mit Symbolen, Buchstaben und Zahlen und an den Wegen die mitlaufenden Routenbezeichnungen.

Für den Fall, daß es möglich ist, alle Wege ohne Wanderroutenrelation per Renderregel auszusieben, könnte man alle verbleibenden "Routen-Wege" ohne Unterschied mit einer 1Pixellinie darstellen lassen. Wählt man dafür dieselbe Farbe, wie für die Wanderwegmarkierung, verschwindet sie optisch darin und die Nutzung einer transparenten Weg-Grafik wäre überflüssig.

Viele Grüße
tippeltappel

Mir fällt gerade noch folgendes ein:

Im Output-Ordner des Composers ist der mkgmap-Style Ordner. Hier erzeuge eine neue Datei mit dem Namen: relations

In diese Datei schreibst du folgende Regel:

( route=hiking | route=foot ) { apply { set foo=bar } }

Im Composer musst du nun gründlich Aufräumen. Alle Regeln weg außer denen, die du für die Symbole etc. benötigst. Anschließend erstellst du dir eine Transparente png-Grafik mit 32*1px udn erzeugst daraus ein Weg-Kartenobjekt und damit eine Renderregel für foo=bar.

Ich hoffe mal, dass der Composer die relations-Datei nicht löscht. Allerdings wird der Composer immer noch alle Daten verarbeiten, in der Karte tauchen sie dann aber nicht emhr auf.

@Nop: Wie bekommst du denn die Symbole auf die Wege? Fügst du da Nodes für ein?

aighes wrote:

@Nop: Wie bekommst du denn die Symbole auf die Wege? Fügst du da Nodes für ein?

Ja.

tippeltappel wrote:

- In der Maske "Route-Eintrag" im Feld "Textmarkierung" eine von Dir gewählte Bezeichnung des Wanderweges eintragen.
- für Textfarbe das leere Feld auswählen
Dadurch wird der Text nicht mehr auf das Schildchen sondern als Name an den Weg geschrieben

Ja, das hatte ich dann irgendwann per trial und error auch schon herausgefunden.

tippeltappel wrote:

Ist der Weg mit mehreren Routen verknüpft, werden alle Routennamen hintereinander an den Weg geschrieben und wenn dieser ein Name-Tag hat, steht dieser am Anfang des "Wurms".

Hm, das war bei mir nicht der Fall. Ist aber auch nicht das ,was ich erreichen möchte.
Ich möchte ja die Namen der Wege( und NICHT die Langbezeichnung der Route) + die Textmarkierung s.o.

tippeltappel wrote:

Die "Schildchen" sind dann allerdings ohne Text. (!!!)

Das war mir aufgefallen, ist mir in dem Fall aber egal.
Allerdings kann man die auch wiederbekommen, wenn man zu den Routen Einträge vom Typ "route_text" erzeugt. Wenn diese auf einen Labeltyp (0x2800)verweisen erhält das Symbolobjekt ein Label!!!. Es wird dann kein Extraobjekt erzeugt.

aighes wrote:

Ich hoffe mal, dass der Composer die relations-Datei nicht löscht.

Sie wird nicht gelöscht allerdings anscheinend auch anderweitig völlig ignoriert.
So wie ich das im Moment sehe ist das wesentliche der Verarbeitung mit der Aufbereitung der Input-Daten erledigt.
Hiernach ist z.B. die Textmarkierung ins Namensfeld des Weges(nicht Route) übernommen.
Die Styles werden dann nur noch für die Erstellung der Garmin-Karte benötigt.

Im Moment sehe ich nur folgenden Weg:
- Input-Datei vorbereiten durch externe Hinzufügung eines Tags zu jedem Weg, der Bestandteil einer Route ist
So lassen sich diese Wege dann einfach identifizieren und das Erstellen der Routenmarkierung kann entfallen.
Es übersteigt meine Fähigkeiten mit akzeptablen Aufwand eine Skript zu schreiben,
welches dieses bewerkstelligt.
Nachteil ist auch, das die Inputdatei weiter aufgebläht würde.
- Diese Datei dann mit Composer verarbeiten

Nochmals Danke für eure Ideen
Gert

Sagte ich ja, dass der Composer wieterhin alle Daten verarbeitet, aber mkgmap schriebt nurnoch die Wege in die img-Dateien, die auch einer Relation angehören.

aighes wrote:

aber mkgmap schriebt nurnoch die Wege in die img-Dateien, die auch einer Relation angehören.

Aber nur wenn mkgmap dies erkennen kann.
in der ...data.osm sind Weg+Route schon aufbereitet und das relations-file wird offensichtlich nicht beachtet.
Also kommt das Tag nicht zum Weg (Ich sehe da aktuell auch keinen einfachen Weg noch ein Tag reinzubekommen.) ergo kann mkgmap nicht erkennen welcher Weg nun rauszusuchen ist.
Wenn das wenigstens ginge könnte die weitere Verarbeitung ja manuel mit mkgmap erfolgen.

Was geht ist die ...data.osm +..routes.osm wieder zusammenzuschreiben und dann manuell mit mkgmap weitermachen. Dort kann man dann via relations ein tag zufügen und nur diese rausschreiben.
Im Moment habe ich noch keine Vorstellung wie ich das Zusammenfügen bei größeren Datenmengen am besten mache.

Gruss
Gert

Stimmt, daran hab ich nicht gedacht 🙁

Dann braucht man wohl doch einen Filter, der Relationen analysiert, den Memberwegen ein Tagg spendiert und dann diese Wege, die betreffenden Nodes und die Relationen in eine osm-Datei schreibt. Mit der kann man dann den Composer füttern.

Composer macht die Analyse ja doch schon, es müsste "lediglich" bei Bedarf ein Tag an die Memberwege anfügen und eine dies entsprechend auswertende Regel in die styles übernommen werden

Gruss Gert

Mal ganz anders herum gedacht -
(Die folgende Idee funktioniert allerdings vermutlich nur mit überschaubaren Regionen.)
In JOSM gibt es mächtige Filterfunktionen.
Damit ist es möglich, ein Extrakt von allen Wegen zu erstellen, die Mitglied einer Routenrelation sind.
Hat man alle Member einer Routenrelation isoliert, kann man diesen Wegen in einem Rutsch ein beliebiges zusätzliches Tag verpassen.
Sammelt man die Extrakte mehrerer Downloads in einer lokalen Datei auf dem PC, erhält man eine Datei, die sich mit Composer verarbeiten läßt.

Gruß
tippeltappel

Damals hatte sich Nop gegen jegliche Vererbungsmöglichkeit von Realtionen auf andere Objekte gesperrt, weil es zu Problemen führen kann wenn man nicht genau weiß, was man tut...

@Tippeltappel...das sollte man tunlichst vermeiden. Das belastet die API nur unnötig.

aighes wrote:

...

@Tippeltappel...das sollte man tunlichst vermeiden. Das belastet die API nur unnötig.

Deinen Einwand verstehe ich nicht. Wenn man eine Region mit JOSM bearbeitet, lädt man sie doch ohnehin herunter.
Was liegt da näher, als die Daten auf dem PC zu speichern und daraus dann die Routen-Wege zu extrahieren. Das ist für die API doch dann keine zusätzliche Belastung.

Ist alles eine Frage der größe des Gebiets. Bei einer Stadt mit sicherheit kein Problem. Hier ging es aber eher um eine ganze Wandergegend oder noch mehr. Das sollte man der API nicht antun. Vorallem könnte es auch jOSM sprengen.

Deshalb schrieb ich "mit überschaubaren Regionen"

Ich habe JOSM auf einem Offline-Rechner installiert und dort schon Verschiedenes mit dem Programm ausprobiert, ohne auf irgendeine Weise mit OSM-Servern Kontakt aufzunehmen.
Unter anderm auch Daten extrahiert und in neuen Dateien abgelegt. Das funktionierte ganz gut.
Da sich Wanderrouten nicht "alle Nas lang" ändern, stelle ich mir vor, daß man sich im Laufe der Zeit systematisch mit der Erfassung der Wanderrouten befaßt und dabei dann die Sammlung anlegt. Wie das im Detail funktioniert und ob und wenn ja welche Schwierigkeiten auftreten, müßte man halt testen.

Gruß
tippeltappel

papaluna wrote:

in der ...data.osm sind Weg+Route schon aufbereitet und das relations-file wird offensichtlich nicht beachtet.

Ich muss das noch mal klarer machen.
in der ...data.osm befinden sich die Wege + routemarker, aber keine Routen mehr( route=hiking etc. fehlt)
Das ist dann auch der Grund warum das relations-file nichts bewirkt. Nicht weil composer es ignoriert, sondern mkgmap findet keine Entsprechung im ...garmin.osm( welches wohl widerum aus ...data.osm generiert wird)
Sobald data + routes wieder vereint sind funktioniert es auch direkt über Composer.

Die Krux scheint mir somit, möglichst einfach diese Wiedervereinigung zu bewerkstelligen.

Die Idee es mit der eh schon vorhandenen lokalen Datei in JOSM zu machen ist interessant.
Allerdings sind mir da mit 1GB RAM enge Grenzen gesetzt. Und wenn ich mir die Ladezeiten etc. bei schon kleineren Dateien <100Mb anschaue, bin ich da nicht so optimistisch. Mal sehen vielleicht schaue ich mir das aber doch noch mal an.

Gruss Gert

Mußt halt eine kleine Download-Datei nehmen.
Der Extrakt ergibt eine deutlich kleinere Datei. Denn da schmeißt Du ja jede Menge raus. Somit sollten sich mehrere Extrakte kombinieren lassen.
Wenn aus welchen Gründen auch immer mehrere OSM-Dateien mit den Extrakten erstellt werden müssen, kannst Du versuchen, sie auf folgende Weise mit Hilfe des Composers zu einer Karte zu vereinen:
Für jede Extrakt-Datei legst Du in Composer eine Region an und bindest die "Extrakt-OSM-Datei" als "lokale OSM-Datei" ein.
Dann legst Du einen Job an, der alle so definierten Regionen verbindet.

Gruß
tippeltappel

papaluna wrote:

tippeltappel wrote:

Die "Schildchen" sind dann allerdings ohne Text. (!!!)

Das war mir aufgefallen, ist mir in dem Fall aber egal.
Allerdings kann man die auch wiederbekommen, wenn man zu den Routen Einträge vom Typ "route_text" erzeugt. Wenn diese auf einen Labeltyp (0x2800)verweisen erhält das Symbolobjekt ein Label!!!. Es wird dann kein Extraobjekt erzeugt.

Sorry, da muss ich mich korrigieren.
Es ist zwar so das dann das Symbolobjekt eine Label hat, der Wert dann aber im Namen des Weges fehlt.
Allerdings ist mir dann aufgefallen das manchmal das Symbol mit Label(und der Weg ohne diesen Namensteil) und manchmal auch andersrum(Symbol ohne Wegmit) generiert wird. Evtl. hängt es ja mit den Einstellungen der Längen bei Routen zusammen
Nach 3 Tagen der Probiererei gebe ich es jetzt erstmal auf verstehen zu wollen, wie Composer da gestrickt ist.

Ich erstelle mein Overlay jetzt wie folgt:
1. Eingangsdaten von Composer verarbeiten lassen
2. Batchdatei starten
2.a. ...data + ....routes.osm aus 1. via Perlskript zu einer Datei zusammenfassen
2.b Diese Data mit mkgmap und eigenen styles weiterverarbeiten( s.o tag schreiben wenn route=hiking etc.
und nur dieses Tag zusammen mit den Symbolen rausschreiben

Als Ergebnis erhalte ich ein img das nur eine Linienmarkierung für die Route(benannt Wegenamen +
dem Textmarkierungsfeld aus der Route) + die Symbole enthält.

Nochmals Dank für eure Unterstützung

Gert

errorLog.txt wrote:

18.01.11 21:10 java.io.FileNotFoundException: http://api.openstreetmap.org/api/0.6/ma … ,10.9,51.1
18.01.11 21:10 Exception downloading: Can't download: http://api.openstreetmap.org/api/0.6/ma … ,10.9,51.1
java.io.FileNotFoundException: http://api.openstreetmap.org/api/0.6/ma … ,10.9,51.1
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
at nop.osm.DataSegment.gatherData(DataSegment.java:51)
at nop.osm.DataDownloader$DataJob.run(DataDownloader.java:197)
at java.lang.Thread.run(Unknown Source)

Ich habe heute meine Region als Download vom API-Server aktualisiert. Dabei hat das »logbuch=errorLog.txt« diesen Fehler ausgeschrieben.
Ich verstehe den so, dass beim Download eine Datei oder ein Datenteil nicht gefunden wurde ...

Kann/würde mir bitte jemand erklären, was das genau bedeutet und was ich ggf. falsch gemacht habe? Danke!

Torsten,
der sich gerade in die unendlichen Weiten der MapComposers einarbeitet. 😉

Unabhängig vom Composer-Fehelr hast du den KArdinalsfehler begangen und von der API geladen. Die API ist aber egtl. nur fürs Mapping da. Für den Rest sollte man die XAPI nutzen oder noch besser fertige Extrakte.

Den Composer-Fehler würde ich ähnlich interpretieren. Wahrscheinlich ist der Bereich für die API flächenmäßig zu groß oder hat zuviele Elemente. Lösung siehe oben 😉

Edit:

@Nop: Wäre es evtl. sinnvoll, wenn du die API generell im Composer sperrst und nur XAPI und Extrakte als Input zulässt?

aighes wrote:

Unabhängig vom Composer-Fehelr hast du den KArdinalsfehler begangen und von der API geladen. Die API ist aber egtl. nur fürs Mapping da. Für den Rest sollte man die XAPI nutzen oder noch besser fertige Extrakte.

Den Composer-Fehler würde ich ähnlich interpretieren. Wahrscheinlich ist der Bereich für die API flächenmäßig zu groß oder hat zuviele Elemente. Lösung siehe oben 😉

Hmmm ...

Mein Probefenster ist 5 Längengrade x 3 Breitengrade groß. Soll das zu groß sein?

In meiner Version steht zu Auswahl:
- Download vom API server (Originaleinstellung)
- Ausschnitt aus Planet Datei (keine Ahnung was das ist)
- Lokale OSM Datei komplett (die wollte ich aktualisieren)

Womit soll ich aktualisieren?

Das einfachste wäre, wenn du dir ein entsprechendes Extrakt herunterlädst und mit diesem dann deine bisherige Datei überschreibst.

Beim zweiten kannst du eine BoundingBox angeben und er schneidet die angegebene lokale OSM Datei auf diesen Bereich zurecht. Bzw. du kannst auch in den Job-Einstellungen ein Polygon-File angeben, welches der Composer dann ausschneidet.

Aktualisieren bedeutet ab in jedem Fall herunterladen aller Daten.

aighes wrote:

@Nop: Wäre es evtl. sinnvoll, wenn du die API generell im Composer sperrst und nur XAPI und Extrakte als Input zulässt?

Ja bitte auf die XAPI ändern! Wenn das standardmäßig an ist und man die ganzen DAUs, die ja in dem Fall nicht mal was dafür können, auf die API losläßt, dann ist es ja kein Wunder das die API lahm ist und die Admins mit sperren der User nicht hinterherkommen. Bitte nur Extrakte/Planet, XAPI und fertige *.osm -Datein zum laden anbieten, also keine API-Downloads oder Aktualisierungen.

_torsten_ wrote:

Mein Probefenster ist 5 Längengrade x 3 Breitengrade groß. Soll das zu groß sein?

In meiner Version steht zu Auswahl:
- Download vom API server (Originaleinstellung)
- Ausschnitt aus Planet Datei (keine Ahnung was das ist)
- Lokale OSM Datei komplett (die wollte ich aktualisieren)

Ja, das is definitiv zu groß, die API ist auf ein 0,5 Grad und 50000 Nodes begrenzt, die ist überhaupt nicht dafür geeignet und gedacht. Am besten nimmt man für Deutschland wenn man ein etwas größeres Stück braucht die Bundesländer oder Deutschlandextrakt von der Geofabrik. Sonst die XAPI, die jetzt noch lahm ist, weil sie in einer Exotenprogrammiersprache geschrieben wurde, die aber laut Liste wohl schon auf Java protiert wird und in einiger zeit dann hoffentlich auch schneller sein wird.

Fabi2 wrote:

Sonst die XAPI, die jetzt noch lahm ist, weil sie in einer Exotenprogrammiersprache geschrieben wurde, die aber laut Liste wohl schon auf Java protiert wird und in einiger zeit dann hoffentlich auch schneller sein wird.

Da wuerde ich mir mal nicht so viel Hoffnung machen. XAPI ist zwar in einer exotensprache geschrieben und wird zur Zeit auf Java portiert, ob es desshalb aber significant schneller wird, wage ich aber mal zu bezweifeln. Der grosse Vorteil des rewrites ist das er besser zu maintainen ist und man somit theoretisch viele neue XAPI server installieren koennte. Ob allerdings tatsaechlich massiv mehr Hardware der XAPI entgegen geschmissen wird muss man sehen, glaube ich aber beinahe nicht.

Fuer das (komplette) Herunterladen von groesseren Gegenden ist also auch die XAPI nicht geeignet. Es sollte imho also auch die XAPI nicht fuer soetwas empfohlen werden, wenn es sich nicht nur um ein paar Strassen oder ein Dorf handelt. (Allenfalls trapi ist etwas besser dafuer geeignet, aber selbst die wuerde mit vielen requests bald ueberfordert sein http://api1.osm.absolight.net/api/0.6/map?bbox=)

Planet extracts sind also eigentlich fuer Endanwender nahezu alternativlos (um das Unwort des Jahres zu verwenden). Zum Glueck bietet die Geofabrik eine gute Auswahl and sehr aktuellen planet extracts sodas das eigentlich kein Problem sein sollte.

amm wrote:

Fabi2 wrote:

Sonst die XAPI, die jetzt noch lahm ist, weil sie in einer Exotenprogrammiersprache geschrieben wurde, die aber laut Liste wohl schon auf Java protiert wird und in einiger zeit dann hoffentlich auch schneller sein wird.

Da wuerde ich mir mal nicht so viel Hoffnung machen. XAPI ist zwar in einer exotensprache geschrieben und wird zur Zeit auf Java portiert, ob es desshalb aber significant schneller wird, wage ich aber mal zu bezweifeln. Der grosse Vorteil des rewrites ist das er besser zu maintainen ist und man somit theoretisch viele neue XAPI server installieren koennte. Ob allerdings tatsaechlich massiv mehr Hardware der XAPI entgegen geschmissen wird muss man sehen, glaube ich aber beinahe nicht.

Fuer das (komplette) Herunterladen von groesseren Gegenden ist also auch die XAPI nicht geeignet. Es sollte imho also auch die XAPI nicht fuer soetwas empfohlen werden, wenn es sich nicht nur um ein paar Strassen oder ein Dorf handelt. (Allenfalls trapi ist etwas besser dafuer geeignet, aber selbst die wuerde mit vielen requests bald ueberfordert sein http://api1.osm.absolight.net/api/0.6/map?bbox=)

Planet extracts sind also eigentlich fuer Endanwender nahezu alternativlos (um das Unwort des Jahres zu verwenden). Zum Glueck bietet die Geofabrik eine gute Auswahl and sehr aktuellen planet extracts sodas das eigentlich kein Problem sein sollte.

... eigentlich .... Das ist genau das richtige Wort, denn es gibt durchaus Situationen, in denen man mit den aktuellen Downloadangeboten nicht wirklich gut weiter kommt. Stichwort "Grenzgebiete" Davon wird es immer mehr geben. Große Bundesländer werden längst in kleinere Einheiten aufgeteilt angeboten. Die Gründe dafür kann sich jeder selbst denken ...

Gruß
tippeltappel

tippeltappel wrote:

... eigentlich .... Das ist genau das richtige Wort, denn es gibt durchaus Situationen, in denen man mit den aktuellen Downloadangeboten nicht wirklich gut weiter kommt. Stichwort "Grenzgebiete" Davon wird es immer mehr geben. Große Bundesländer werden längst in kleinere Einheiten aufgeteilt angeboten. Die Gründe dafür kann sich jeder selbst denken ...

...genau das ist das Problem. Ich wohne im Bayerisch-Sächsisch-Tschechischen Grenzgebiet. Um eine brauchbare Karte der Umgebung mittels Composer ohne API-Download zu erzeugen, muss ich die ziemlich große Europakarte der Geofabrik downloaden um dann die maximal 3 Kacheln meines Bereichs vom Composer ausschneiden zu lassen. Ziemlich umständlich und vor allem Zeitaufwendig das Ganze. Gibt es vielleicht eine Möglichkeit mehrere kleinere Karten-Dateien der Geofabrik zu einer "Input-Karten-Datei" für den Composer zusammenzufügen. In meinem Fall also die Karten von Sachsen, Bayern und Tschechien? Oder Deutschland und Tschechien? Das wäre immer noch schneller heruntergeladen als die mit minimal 4,7GB angebotene Europakarte.

Gruß Oberoner

Gegen die Nutzung der XAPI aht ja auch keiner was. Man soll nur nicht die API mit solchen Anfragen belasten.

@aighes: Wie bekomme ich denn den Composer dazu statt der API die XAPI für den Download der Kartendaten zu nutzen? Ein Download vom XAPI-Server läßt sich dort nicht einstellen.

Grüße
Oberoner

Du musst in den Einstellungen die URL ändern. Siehe: http://composer.waldpfa.de/index.php/MC/Einstellungen

@aighes: Danke für den Hinweis und den Link. Ich werde es ausprobieren.

Grüße
Oberoner

Hallo Nop,

gibt es schon eine Lösung für die wirren Zickzacklinien von Straßenverläufen auf der Karte? Es scheinen bei mir immer mehr zu werden!? Es tritt derzeit hauptsächlich im Nordharz und Ostsachsen bei mir auf... Ich kann da aber leider auch keinen Fehler in den OSM-Daten finden.
Mal ganz vorsichtig angefragt: Wenn es evtl. eine Lösung gäbe, wann könnte die denn in einer neuen Version des OSMC gefixt werden?

Danke für Deine Arbeit, ich nutze Dein Programm wirklich gern!
Viele Grüße
Frank

Kannst du dein Problem etwas mehr konkretisieren? Weg-ID oder PermaLink wären hilfreich...

osmFrank wrote:

1. gibt es schon eine Lösung für die wirren Zickzacklinien von Straßenverläufen auf der Karte?
2. Ich kann da aber leider auch keinen Fehler in den OSM-Daten finden.
3. Mal ganz vorsichtig angefragt: Wenn es evtl. eine Lösung gäbe, wann könnte die denn in einer neuen Version des OSMC gefixt werden?

1. Ja.
2. Der Fehler lag in srtm2osm.exe und ist schon behoben.
3. Die neue Version von Composer ist fast fertig, hat nur den Abschlußtest leider nicht bestanden. Dauert noch ein paar Tage.

bye
Nop

Nop wrote:

osmFrank wrote:

1. gibt es schon eine Lösung für die wirren Zickzacklinien von Straßenverläufen auf der Karte?
2. Ich kann da aber leider auch keinen Fehler in den OSM-Daten finden.
3. Mal ganz vorsichtig angefragt: Wenn es evtl. eine Lösung gäbe, wann könnte die denn in einer neuen Version des OSMC gefixt werden?

1. Ja.
2. Der Fehler lag in srtm2osm.exe und ist schon behoben.
3. Die neue Version von Composer ist fast fertig, hat nur den Abschlußtest leider nicht bestanden. Dauert noch ein paar Tage.

bye
Nop

Danke Nop! Da spar ich mir die weiteren Experimente... und geh lieber mappen.

Frank

aighes wrote:

Kannst du dein Problem etwas mehr konkretisieren? Weg-ID oder PermaLink wären hilfreich...

Danke aighes, aber Nop hat es ja schon gefixt, es sind also nicht die OSM-Daten der Auslöser....