Doch ich werte die ~Top15 Surface Tags aus. Dazu smoothness, usability, tracktype plus als reines negativ Kriterium sac_scale, mtb_scale, trail_visibility, und natuerlich auch Access Tags. Mehr Tags fallen mir nicht ein.
Es gab einen Fehler bezueglich highway=path & sac_scale=hiking - wo aus versehen kein unpaved gesetzt wurde.
Das Design der Wege/Tracks war wie geschrieben nur provisorisch, ich hab es jetzt deutlich verbessert und es schaut ganz gut aus mit einem Server.
Ausserdem hab ich das Autorouting noch einmal gefuehlt deutlich verbessert, indem ich source:maxspeed sowie maxspeed=Zahl auswerte. maxspeed=de:local / maxspeed=de:urban bitte ich umzutaggen da es Schwachsinn ist (und hoffe dass dies alle anderen Renderer auch so sehen). Am besten schickt dazu jemand mal einen Bot los.
Was welchen Wert hat, schaust du dir am besten im style an. Weil das ist viel zu kompliziert zum erklaeren.
Gibt’s eigentlich eine Möglichkeit, die Karten auch ohne Garmin zu sehen und das ganze ggf.s für Dumme erklärt?
Würde mich mal interessieren, ob die von mir getaggten Wege im Großraum Karlsruhe korrekt kommen etc.
Im Gegensatz zur Reit- und Wanderkarte http://topo.openstreetmap.de/ gibt’s die ja offenbar nicht online anschaubar?
Routen die Karten eigentlich über die Karlsruher Rheinbrücke, wenn das die kürzeste Strecke ist?
Qlandkarte GT ist 100% kompatible (benutze Version 0.18.2 – also selbst kompilieren…)
Autorouting geht nur mit Garmin Programmen - etwa Basecamp (kostenlos Max/Windows), Mapsource (WINE/Windows) (okay es geht noch mit gpsmapedit, aber dass ist ein Entwicklertool).
@ extremecarver
Ok. Mit Hilfe der “Legende” erkenne ich jetzt besser, was wie gemeint ist.
Ich warte noch ein paar Tage und dann lade ich ein Udate der Karte herunter.
Wenn mir dann in dem mir vertrauten Gebiet Radwegschnipsel mitten im Wald auffallen, die garantiert als Radweg unbrauchbar sind, sehe ich mir das Tagging an. Die Karte, die ich jetzt betrachte hat das Kartendatum 29.4.
Ein Teil der blau angezeigte Waldwege ist als highway=path, surface=dirt getagt. Solche Pfade würde ich als “Straßenfahrer” meiden, da meist auch recht holperig. Bei mindestens zwei der blau angezeigten Pfade wurde surface=mud getagt und bei einem anderen surface=grass. Das sollten eigentlich eindeutige Ausschlußkriterien sein. Bei einfach nur surface=unpaved wäre ich mir unsicher. Das kann alles sein, auch ein gut verdichteter glatter Pfad. Das Tag scheint aber auch für holperige Waldwege beliebt zu sein.
So weit eine Kurzanalyse des mir bekannten Bereichs.
Okay, habs mir nochmal angeschaut. Ich muss mir nochmal was ueberlegen wie ich hier besser differenzier. Ich habe surface zwar insoweit ausgewertet, aber nur fuers Autorouting (add mkgmap:unpaved=1}, nicht jedoch so umfassend bei der Wegdarstellung benutzt. Ich muss hier bei path und track noch mehr Regeln einbauen. Ich bin vom Denken her einfach zu stark Mountainbiker beim aufbauen der Regeln, und hab ja auch einen Großteil der Regeln uebernommen und angepasst. Meine Prioritaet lag beim Autorouting, weil das 10x so schwer zum hinbekommen ist, wie einfach nur die Darstellung. Ich werde einfach noch eine Regelserie einbaun, die surface auf den imaginaeren tracktype umsetzt, wenn weder smoothness, usability noch tracktype an sich getagged sind.
Ausserdem hab ich highway=path ohne Zusatztags, jetzt eh schon aus halbblaugrau dargestellt, so ist es ein Zwischending. Ich schaetze 99% der Wege mit Tags hab ich recht gut dargestellt, etwa 85% auch ohne Tags sind halbwegs korrekt. Moechte halt bei der velomap das ganze nicht so kompliziert werden lassen wie bei der openmtbmap, wo ich zeitweise 40.000 Zeilen Code hatte, bevor der Merge in mkgmap mit der style-branch kam. Primaer ist es halt einfach wahnsinnig aufwendig immer das typ-file ans style-file anzupassen.
Ja, das Autorouting für die Zielgruppe “Straßenfahrer mit Sinn für’s Grüne” hinzubekommen ist bestimmt 'ne aufwändige Sache. Die Darstellung der Wege geht bei so einer Karte aber doch letztendlich zwangsläufig mit dem Routingschema zusammen. Oder nicht? Jedenfalls sieht es für mich so aus, als ob man anhand des Farbschemas erkennen kann, welche Wege hinsichtlich der Straßenradtauglichkeit vermutlich falsch oder unvollständig getaggt sind. Feine Sache!
Vielleicht sollte man im OSM-Wiki http://wiki.openstreetmap.org/wiki/DE:Key:surface oder an anderer Stelle einen Hinweis einbauen, daß bei manchen surface-Arten nur aus der Kombination von surface und smoothness herauslesbar ist, für welche Nutzung ein Weg geeignet ist. Und daß dies die Qualität einer routingfähigen Straßenrad-Karte erheblich beeinflußt. Hast Du eventuel schon irgendwo eine Hilfestellung mit Beispielen für das sinnvolle Taggen hinterlegt?
Bei der Openmtbmap schon. Bei der Velomap bin ich noch nicht dazu gekommen. Werde es aber heute tun.
Das wichtigste IMHO ist, allerdings weniger offensichtlich.
“oneway=yes & lanes=2”, denn so kann man die generell uebelsten Straßen mehr oder weniger ausschließen. Womit wir wieder beim Thema bikeability Tag waeren. Und ich glaube ich werden den Key jetzt einfach implementieren. Die ganzen Noergler die meinen man koennte sowas doch ueber Eingenschaften taggen, sind einfach noch nicht in der Realitaet angekommen. Die highway Klassen haben ja auch nichts mit Eigenschaften zu tun, und werden fuer Autofahrer auch benutzt.
Hmmm. - Als “Buschreiter” bin ich eher mit track und path vertraut. Diskussionen um das Taggingschema für Radwege hab ich bislang nicht verfolgt. Deshalb ist mir nicht klar, von was für einen Key Du schreibst.
Eine klare Anleitung wie sinnvolles (weil auswertbares) Taggen auszusehen hat, find ich sehr wichtig. Sonst bringt das ja alles nichts. Separate Radwege taggen ist leicht. Aufpassen muß man offensichtlich bei in die Straße integrierte Fahrradspuren und nur in Fahrtrichtung (oneway) nutzbare Radwege neben der Straße . Daß die für das Routing deutlich als solche erkennbar sein müssen, ist klar. Aber wie gesagt, in dem Thema bin ich nicht wirklich “drin”. Von daher gehöre ich auch zu denen, die für eine gute Tag-Anleitung dankbar wären.
Warte noch rund 3-4 Stunden und schau dann mal auf die talk-osm (englisch) Mailingliste und meine Website stelle. Ich schreibe gerade einen Artikel der hoffentlich genauso viel “Staub” aufwirbelt wie die path vs footway vs cycleway Diskussion und in dem ich aus meiner Sichtweise beschreibe warum es einen neuen Tag braucht, aber auch welche Tags schon jetzt Sinnvoll sind.
Auf Englisch habe ich den Artikel fast fertig, moechte ihn aber gleichzeitig auf Deutsch veroeffentlichen, damit wir auf der Deutschlen ML eine “Debatte” in mehreren Threads, und keine “unkonstruktive Endlosdiskussion” zustande bekommen.
Ich werde den Artikel daher auf Deutsch uebersetzen (brauche dafuer jedoch sicherlich noch 2-3 Stunden) und auf die Deutsche Mailingliste stellen
path vs footway vs cycleway
Path und Track kombiniert mit smoothness, surface und/oder tracktype ergeben zusammen mit auf amtlichen Bestimmungen beruhenden access-tags die einzig logische Grundlage für klar strukturierbare Renderregeln.
Leider werden Wege viel zu häufig nach persönlichem Gutdünken klassifiziert. Erst kürzlich hab ich in der Eifel Reitverbote gelöscht, wo definitiv keine existieren. Den Mapper hab ich natürlich vorher befragt und der bestätigte meinen Verdacht, daß er das so getagt habe, weil er meinte xyz=no würde bedeuten, daß der Weg für diese Nutzergruppen ungeeignet sei. Es ist zwar richtig, daß dieser Weg für diverse Nutzer ungeeignet ist. Doch solche Klassifizierungen sollte man besser z.B. mit einem Gefahrenhinweis signalisieren. (hazard= …Kurzbeschreibung…). Solche Hinweise lassen sich dann ganz allgemein auswerten und werden z.B. auch auf der Wander-Reit-Karte angezeigt.
Ein Howto auf meiner Website kommt auch noch. Welches ich auch ins Wiki stellen werde. Aus dem Wiki sollte hervorgehen welche Tags ich fuer Sinnvoll halte, und warum sie trotzdem nicht ausreichen.
Bei diesem neuen Schlüssel handelt es sich, wenn ich das richtig verstanden habe, um die subjektive Bewertung von Radwegen.
Aus der Sicht eines Radfahrers kann dann bewertet werden, ob ein Radweg empfehlenswert (z.B ruhig gelegen und landschaftlich schön) oder normal ist oder sogar tendenziell eher gemieden werden sollte (z.B. wegen des hohen Verkehrsaufkommens).
Die Idee finde ich sinnvoll und eigentlich sogar überfällig.
Auf alle Fälle werde ich bei mir in der Gegend mit dem entsprechenden Tagging mal beginnen.
Ja, werde den Key versuchen innerhalb den naechsten 1-2 Wochen einzubaun. Ist nicht sehr einfach da es keine Möglichkeit gibt in mkgmap basierend auf tags eine Straße abzuwerten und ich somit Minimum 200 Zeilen Code zusaetzlich braeuchte… Ich warte daher noch ein bisserl ab, ob noch bessere Lösungen kommen (sehe ich aber nicht), und werde es nochmal auf der Mailingliste von mkgmap vorschlagen, da die Möglichkeit basierend auf Tags die Straßen auf/abzuwerten das maintainen der Autoroutingfaehigkeit wahnsinning vereinfachen wuerde. Da es dies schon fuer POI gibt, dürfte die Umsetzung auf Tags nicht so schwer sein. Nur selber kann ich es halt nicht programmieren…
Ab Morgen Abend/Dienstag sollte es voraussichtlich Updates und eine Europakarte sowie Laenderkarten geben…
Problem ist, dass beim Erstellen einer gmapsupp.img beim Rauszoomen auf dem Etrex Vista HCx nur die Kachel mit Kartendaten angezeigt wird, in der sich der Cursor befindet, alle anderen werden nur mit Umrissen angezeigt.
Um deine Routingfunktion auf einer Europa-Süd-Karte (DE-AT-HU-IT) zu testen würde mich sehr interessieren, welche mkgmap-Optionen und welches Stylefile du zum Erstellen der Kacheln verwendest.
Dass mit dem Cursor kann ich am Vista HCx jedoch nicht nachvollziehen, ab welcher Zoomstufe tritt das Problem auf?
Es ist normal, dass immer zuerst eine Kachel geladen wird, und erst wenn diese vollstaendig angezeigt wird, wird die naechste Kachel (also die nicht aktive) angefangen. Es kann also schonmal 2-3 Sekunden dauern bis die weiteren Kacheln kommen. Das ist aber normal und bei allen Karten so. Je mehr Details dargestellt werden, desto laenger braucht es also bis die weiteren Kacheln angezeigt werden.
Kacheln: Das tritt in jeder Zoomstufe auf. Es wird - egal wie lange man wartet - nur die Kachel angezeigt, in der sich der Cursor befindet. Überfährt man die Kachelgrenze wird sofort die andere Kachel angezeigt. Aber eben immer nur eine Kachel.
Ich werde die Karte noch einmal neu zusammenstellen …
wenn ich das richtig vestehe, ist der allgemeingültige key: class:bicycle=*
In welcher Beziehung stehen die erweiterten keys dazu (z.B. class:bicycle:touring=*). Werden diese keys von Fall zu Fall ergänzend benutzt oder ersetzen diese -bei Anwendung- den allgemeingültigen key?
Ich werde alle Keys die zur Karte passen auswerten. Hoffe halt noch dass sich einer der mkgmap Programmierer meinem Feature Request annimmt. Schließlich waere der auch allgemein sehr Sinnvoll. @flux, hast du die Karte ganz normal per Mapsource ans GPS gesendet mit Standardinstallation (also ohne Hoehenlinien oder aehnliches). Ich schaffe es einfach nicht das zu reproduzieren.
Ich habe die *.img-Dateien und das bikede.TYP mit mkgmap zu einer gmapsupp.img erstellt und dann auf die SD-Karte des Etrex Vista HCx kopiert.
Mach’ dir keinen Kopf, ich habe jetzt mit deinem Style-File eine Europa-Karte generiert, die optimal angezeigt wird und hervorragend routet!
Danke nochmals,
flux.
Ergänzung: Was mir auffällt ist, dass beim Herauszoomen in große km-Bereiche neben den großen Städten auch Inseln angezeigt werden (Schleuseninsel Geisling/Donau, Insel im Chiemsee und andere).
