hier das konkrete beispiel:
http://www.openrouteservice.org/index.php?start=8.6437935,50.0715827&end=8.6415435,50.0703916&pref=Bicycle&lang=en&noMotorways=false&noTollways=false

die osm-daten sollten stimmen, da hab ich schon ausführlich nach fehlern gesucht. (wobei bei osr noch was falsch ist in den routingdaten, habe osr nur zur verdeutlichung verlinkt, wie geroutet werden sollte.

Die unterführung ist eben für autos nicht als durchfahrt gestattet (aber möglich, diverse navis routen auch da lang :wink: ), fahrradfahrer dürfen aber durch. achja, das tagging der straße dort habe ich mir nicht ausgedacht, nur angepasst

als karte verwende ich die hessenkarte mit den geofabrikdaten von gestern. (das bild oben ist mit etwas älteren kartendaten erzeugt, dennoch gleiches problem)
wenn man den schieberegler kleine straßen/autobahnen etwas mehr nach links verschiebt, (auf die 2. stufe von links) routet er auf der anderen seite von der bahn durch den wald… dann will er halt die bundesstraße rechts vermeiden.

Vorab: Ich konnte das (Umleitungs-)Routing gemäß Screenshot nachvollziehen (BC OSX 3.3beta).
Wählt man den Start- und Endpunkt aber etwas anders, so ergibt sich eine “sinnvolle” Route.

Da der Garmin-Routing-Algorithmus aber nicht bekannt ist …

Gruß Klaus

@JayJay01: Wenn du dich dort in der Gegend auskennst, dann könntest du bei der Flughafenstraße mal ein wenig bei access aufräumen.

Einen Grund für den Umweg kann ich auch nicht in den Daten erkennen. Da kein oneway vorhanden ist und es mit der anderen Strecke klappt, wird es wohl was im Garmin sein, was die Route verlängert.

kann evt. der highway=turning_circle das problem erzeugen?

Ok, hab auch noch einen Fehler (Werdohl):

http://maps.cloudmade.com/?lat=51.254798&lng=7.756455&zoom=16&directions=51.254703,7.761089,51.254404,7.758139&travel=car&styleId=1&active_page=0&opened_tab=1

Hier macht die Freizeitkarte oben einen Schlenker am Bahnhof vorbei. Standard-mkgmap-Karte (default Style) routet richtig.
Chris

Höhenlinien: Mitte Januar 2012 enthält die Freizeitkarte zusätzlich integrierte Höhenlinien.
Frage: Hätte im Vorfeld jemand Interesse hierzu eine Qualitätssicherung / Bewertung vorzunehmen?

Gruß Klaus

klar, bin ich dabei

kann es sein das cycleway=opposite nicht oder nicht richtig ausgewertet wird?

–make-opposite-cycleways: ist nicht aktiviert, oder? (seh zumindest nichst in der config)
im style file sehe ich auch nichts, wo cycleway=opposite ausgewertet würde?

//edit wie ich vermutet habe, hilft make-opposite-cycleways auch nicht, da die ja nicht mit mkgmap:carpool=1 ausgestattet werden…

hab grad ne neue karte mit aktuellen daten erstellt, da routet er gleich richtig… vielleicht hat ihn irgend eins der access tags gestört, vielleicht liegts auch an anderen einstellungen an denen ich gespielt habe. daher wäre es schön, wenn jemand von euch das vielleicht bestätigen könnte, der sich auch karten selbst baut?

Derzeit wird keine der mkgmap-cycleway-optionen verwendet.
Ich habe vor dies in einer der nächsten Ausgaben ggf. zu ändern.
Dies bedingt aber (unter anderem) umfangreiche Tests des Routings.

Zu berücksichtigen sind weiterhin:

  • die kommende BaseCamp-Version 3.3 mit Änderungen beim Routing
  • korrekte Darstellung der zusätzlichen Radwege (schwierig)

Gruß Klaus

PS: Ca. Mitte Januar folgt eine neue Ausgabe der Karte mit integrierten Höhenlinien als Hauptfeature.

@Jayjay01: Hast du hier eine funktionierende eMail-Adresse hinterlegt ?

Email: jetzt schon :wink:

Die frage ist eben, in wieweit man die mkgmap cycleway optionen momentan so verwenden kann. denn momentan werden halt zusätzliche straßen erstellt, über die auch autos geroutet werden, was ja nicht der sinn der sache ist…
da müsste man wohl was eigenes im style schreiben.

Wenn die Karte nur Radler routen soll, kann man im style einfach das oneway löschen.

das soll sie aber nicht :wink:

Die Freizeitkarte Deutschland ist in der Ausgabe 12.01 erschienen.
Das Kartenmaterial basiert auf den OpenStreetMap-Daten vom 10.01.2012.

Link: http://www.easyclasspage.de/karten/index.html

Ergänzungen / Veränderungen gegenüber der vorherigen Version:

  • verbesserte Darstellung der ÖPNV-Symbole Bahnhof, Haltestelle, U-Bahn-Eingang
  • dezentere Darstellung der Staatsgrenzen
  • Darstellung von Autobahnen auch in höheren Zoomstufen
  • allgemeine Verbesserung des Routings
  • Strichelung von Feld- / Waldwegen geändert (kürzere Striche)
  • Logikdefekt bei privaten Feld- / Waldwegen korrigiert
  • Darstellung von privaten Feld- / Waldwegen geändert
  • Darstellung von Wegen / Pfaden geändert (gepunktete Linie statt Volllinie)
  • Logikdefekt bei privaten Wegen / Pfaden korrigiert
  • Darstellung von privaten Wegen / Pfaden geändert
  • etwas dunklere Darstellung der Wasserflächen (B5D0D0 → 99CCCC)
  • Höhenlinien integriert (Äquidistanz 25 Meter, Beschriftung alle 250 Meter)
  • dezente Darstellung der Höhenlinien mit zwei Zoomstufen (C0C0C0)
  • Unterstützung von Höhenprofile für Routen

Bei der Erstellung dieser Ausgabe haben unterstützt:
Autor phyghtmap, Autor osmconvert, Garmin-User, Georg V. GerdP, guegafue, koepke, kukuk, mike_hd, Minko, Roman B.

Die Integration der Höhenlinien basiert auf essentiellen Vorarbeiten von:
Garmin-User, kukuk

Die Karte befindet sich im Status “Erprobung”.
Hilf mit sie weiter zu verbessern …

Gruß Klaus

So kannst du die Karte erst ab 1 April veröffentlichen. Höhenlinien und Kartendaten vermischen ist lizenzmäßig nicht erlaubt (zumindest solange du weiter Höhendaten von Jonathan de Ferranti verwendest) - da die Höhenlinien von Jonathan mit CCBYSA 2.0 nicht kompatibel sind - es die Karte im allgemeinen aber sein muss.

Auf Websites wird das daher auch über Layer geregelt. So musst du es auch machen. Höhenlinien in separate Kacheln packen wie die restlichen Kartendaten (zumindest überall dort von Daten von Jonathan benutzt werden. Mit SRTM3 kannst natürlich bzw dagegen machen was du willst).

Zunächst einmal ‘Hallo’ und einen ganz herzlichen Dank an Klaus und seine Mitstreiter für die Freizeitkarte und insbesondere für die ‘Entwicklungsumgebung’. Ich versuche mich gerade in die Erstellung individualisierter Karten einzuarbeiten, und da ist die Zusammenstellung der Tools und Scripte eine wirkliche Hilfe.

Sehe ich das richtig, das im Moment straßenbegleitende Radwege, die z.B. mit highway=residential cycleway=track getaggt sind, nicht als Radwege dargestellt werden? Wie müßte eine Änderung in der lines-Datei aussehen damit solche Radwege in Garmin-BaseCamp angezeigt werden?

Gruß aus dem sonnigen Rheinland
Wolfgang

Ja, in der Straße verlaufende Radwege werden derzeit nicht dargestellt.
Dieses Feature ist aber für eine zukünftige Ausgabe geplant.
Die derzeitige Idee dies darzustellen ist folgende: Straßenränder in “blau”
Dies bedingt dann diverse zusätzliche Linien.
Z.B. “Straße mit grauen Rändern” → “Straße mit blauen Rändern” (zusätzlich).
Im Stylefile “lines” ist dann die o.g. Bedingung entsprechend zu berücksichtigen.

Klaus

Vielen Dank für die Entwicklungsumgebung. Funktioniert echt prima.

Allerdings tauchen in den von mir generierten Karten (Version 12.01) in BaseCamp bzw. auf dem Oregon keine Höhenlinien auf. In der Anleitung habe ich dazu nichts gefunden.

Habe ich was falsch gemacht, oder ist das noch nicht in die Entwicklungsumgebung integriert?

Die Integration der Höhenlinien war etwas aufwändiger - ist jetzt jedoch fast fertig und soll in den Betatest.
Die Freigabe der Entwicklungsumgebung mit Höhenlinien ist für Anfang / Mitte Februar geplant.
Wer den Betatest unterstützen möchte, sollte mir eine PM schreiben - Danke.

Gruß Klaus

Das klingt doch prima, vielen Dank.

PM ist unterwegs…