Am 20. Juni 2010 21:36 schrieb Joerg Fischer <osm2...@jfis.de>:
> Ich bin vielleicht aus den Erfahrungen meiner Ecke etwas angenervt. Ich
> habe hier mehr oder weniger flächendeckend alle Radwege erfasst, und weil
> das highway=cycleway dranhängt nicht noch zusätzlich bicycle=designated
> benutzt, weil das implizit am highway hing. Dann kamen ein paar Leute
> daher und machten aus allen =cycleway ein =path, _ohne_ ein
> bicycle=designated zu ergänzen, und schon sahen alle Wege, die vorher
> optisch sauber getrennt dargestellt wurden, wie ein Trampelpfad aus. Und
> es gingen richtig viel Informationen verloren, weil natürlich auch alle
> =footway angepackt und zu =path umgetaggt wurden. :-/
Das ist natürlich ein ziemlich hirnloser edit, den der Mitmapper da
fabriziert hat...
Andererseits kam die Position, daß highway=cycleway als Abkürzung für
highway=path, bicycle=designated zu sehen ist, auch erst mit dem
highway=path auf, was alle vorher nach anderen Kriterien("hier kann
man gut...") eingetragenen cycleways nicht berücksichtigt(wie auch bei
den footways).
Daher finde ich die implikation "cycleway=designated" problematisch -
es gibt auch noch einen großen Teil an Mappern, die cycleway so taggen
(nach Eignung/Nutzung).
>> >> Path kann diese Situation ebenso gut darstellen, wenn nicht sogar
>> >> besser (kombinierte Wege).
>> > Nein.
>> Ok, das überzeugt mich. Wo versagt path hier?
>
> Mißverständis: path ist nicht _besser_. Es gehen günstigstenfalls keine
> Informationen _verloren_, wie es im oben beschriebenen Beispiel passiert
> ist.
Für mich wird die Klarheit gewonnen, daß alle Eigenschaften, die nicht
getaggt sind auch nicht bekannt sind. ein fehlendes surface=* heißt
bei path also nicht "es ist die Oberfläche anzunehmen, die die meisten
Mapper als Standard für path ansehen (so wie die meisten durch
cycleway eine befestigte Oberfläche als gegeben ansehen), sondern, daß
es schlicht noch fehlt.
Auf die Implikation von bicycle=designated kann man sich bei cycleway
ja leider auch nicht verlassen.
Daher ist es mir dann lieber, bewußt auf implikation zu verzichten,
die mir bekannten Fakten einzutragen und durch highway=path zu zeigen,
daß ich nichts implizieren will, außer, daß es ein "untergeordneter
Weg" ist.
>> (Notiz: ich bin *nicht* für blindes umtaggen)
>
> Wie handhabst Du das dann?
Ich mache das eigentlich nur dann, wenn cycleway oder footway entweder
*wirklich* falsch sind (z.B. ein reiner Fußweg oder Trampelpfad, der
als cycleway gemappt ist) oder ich sowieso eine inhaltliche Ergänzung
hinzufügen muß (wenn bei ausgeschilderten Wegen kein *=designated
vorhanden ist).
Oder halt, wenn wieder jemand rumgeht und von mir mit path und
*=designated eingetragene Wege in cycleway umändert - idealerweise
noch unter löschung der *=designated-tags. ;-)
Damit die information, was nun vor Ort ist, besser überleben kann,
tagge ich meist noch eine notiz wie "note=fuß und radweg / note=reiner
radweg" dazu - vielleicht sollte ich das mal auf traffic_sign=*
umstellen.
> Wie gesagt: Wenn der Umtagger bei der Aktion das, was vorher im highway
> steckte, jetzt nach =designated verlagert hat er zumindest mal keinen
> Schaden angerichtet. Er hat aber auch keine zusätzlichen, irgendwie
> nützlichen Informationen hinterlegt. Da bin ich dann für "never change a
> running system". Inzwischen benutzen so viele Anwendungen OSM-Daten, das
> ich mit Umdefinitionen von globalen, bewährten Tags gern vorsichtiger wäre.
Wie gesagt, ich halte die implikation von *=designated im highway
nicht für "stabil" - ein explizites taggen sagt dagegen aus, daß
tatsächlich genau das gemeint ist.
> Was war so schlimm daran? Jetzt ist der "breite" footway, dessen
> Eigenschaften man hätte ebenfalls durch smoothness usw. beschreiben
> können, durch den _noch_ breiteren path ersetzt worden, denn der soll jetzt
> zusätzlich zu allen footway auch noch die cycleway ersetzen. ;-)
Das "schlimme" war, daß die "Gesamtbreite" sich aus vielen Einzelnen
Interpretationen zusammensetzt(e), die allesamt doch recht eng waren.
Und als Auswerter frage ich mich dann, in welcher Ecke des Spektrums
der Mitmapper "seinen" footway gerade sah. ;-)
> Ups. Jetzt wirds interessant! (Ich benutze bisher die AIO-Garminkarte von
> Christoph.)
Die hatte ich auch und von dort habe ich mir auch teilweise die
Umsetzung der maxspeed-Werte in garmin-"road_speed"-Klassen abgeguckt.
> Ich kenne die Anleitung wie die AIO-Karte entsteht, solche Eigenschaften
> sind dort etwas unterdokumentiert wie mir scheint. Da habe ich ganz klar
> ein Defizit, ich wußte nicht dass das geht. Bisher sagten alle, es gäbe
> diese IIRC 13 routingfähigen Garmintypen und da müsse man alles hinein
> pressen. Das habe ich so hingenommen.
Ja, das stimmt auch(etwa) - aber jedes Stück Weg lässt sich noch mit
den Eigenschaften "Verboten für $Fahrzeugklasse",
"Geschwindigkeit("road_speed")", "Netzhierarchie/Routinggewicht"(naja,
es heißt "road_class" und drückt aus, wie stark das Gerät einen Weg
bevorzugen soll), "unbefestigt", "Kostenpflichtig" sowie (benutze ich
nicht, weiß auch nicht, ob es schon unterstützt
wird)"Fahrgemeinschaftsspur" ausstatten.
Die letzten drei Eigenschaften lassen sich in meinem Etrex Vista auf
"vermeiden" stellen, so daß ich kontrollieren kann, wann ich die
kostenpflichtige Fähre oder den unbefestigten Weg benutzen will und
wann nicht.
Damit kann man schon eine Menge bauen, wenn man sich überlegt, wie man
die vorhandenen Linientypen verteilt - Ich habe zum Beispiel einen für
jeden Tracktype, weil ich diese optisch unterscheiden will, aber
(secondary und tertiary), (motorway und trunk), (residential und
unclassified und living_street und pedestrian) teilen sich jeweils
einen typ, da die Unterscheidung für mich weniger wichtig ist bzw. nur
in access-restrictions und maxspeed besteht, die ich auf dem Garmin
auch als solche einbauen kann.
Jetzt habe ich noch ein paar Typen frei. :-)
> Ich nehme Deinen Vorschlag an und hätte fürs Erste gern einen Pointer wo
> ich anfangen soll mit lesen.
Das beste ist natürlich die mkgmap-dev Mailingliste[1](vielleicht
besser lesbar auf nabble[2]), aber es könnte umständlich sein, dort
alles zusammen zu suchen, wenn man nicht schon länger mitliest.
Es gibt natürlich auch eine Wikiseite[3], die grundlegende
Vorgehensweise und Kommandozeilenparameter erklärt (die man auch mit
einem "nakten" Aufruf von mkgmap erfährt).
> Es müßte doch dann irgendwie, naja, wie in
> LaTeX, Minuspunkte für Eigenschaften geben die der Router bei seinen
> Entscheidungen berücksichtigt?
Ja, die gibt es - zumindest als Patch von Felix Hartmann, wenn ich nicht irre.
Damit kann man dann jedes Stückchen Weg erst einmal durch einen Satz
Regeln laufen lassen, der Plus- oder Minuspunkte verteilt um dann in
einem zweiten Schritt nicht nur auf Basis der OSM-tags, sondern auch
dieser Punkte eine Einordnung vorzunehmen.
Ich hab schon länger vor, mal nachzulesen, ob der Patch nun drin ist
und dann Teile meiner Regeln darauf umzustellen.
> Hast Du ein halbwegs dokumentiertes
> makefile oder Shellscript? Ich geh mal davon aus Du schmeißt die 100
> Parameter nicht jedesmal mit der Hand ein. ;-)
Stimmt, aber dokumentiert ist übertrieben - ich schreibe mal schnell
ein paar Kommentare rein. ;-)
Ich habe ein Skript, das die von Geofabrik heruntergeladene Region mit
dem splitter zerteilt und eines, das mir daraus meine Karte baut -
allerdings in mehreren mkgmap-läufen, die jeweils einen layer
erzeugen. Diese layer werden dann nachher wieder zu einer gmapsupp.img
zusammengefasst.
Ich würde empfehlen, aus dem mkgmap-Verzeichnis den Standardstil aus
/resources/styles/default/ zu kopieren und als basis zu verwenden.
Meine Verzeichnisstruktur sieht so aus:
->/garmin-karte/ (hier liegen die skripte)
-->/splitter/ (der splitter)
-->/mkgmap/ (das mkgmap-Verzeichnis)
-->/styles/ (meine eigenen Style-files)
--->/topo/ (der stil für den Hauptlayer)
--->/landuse/ (usw...)
-->/typ/ (die eigenen .TYP-Files)
-->/*region*/ (z.B."deutschland")
--->/quelle/ (hier liegt die .osm.bz2 und nach dem splitten die
Kacheln als *.osm.gz)
--->/topo/ (hier kommt das ergebnis des Hauptlayers rein)
--->/landuse/ (usw...)
Das Skript, das deutschland splittet:
###########
#!/bin/sh
#Wechsel in das Unterverzeichnis, in dem die germany.osm.bz liegt
cd deutschland/quelle
#Räume mit dem alten output auf
rm 63*.osm.gz template.args areas.list
rm -rf cache/*
#Der Splitter-Aufruf. "cache" ist der Name des Unterverzeichnisses, in
dem der cache angelegt wird. --geonames-file ist ein gimmick, das eine
Liste erzeugt, in der jeder Kachel ein Name zugewiesen wird.
#Das lässt sich dann in mkgmap mit der Option "--c" verwenden,
funktioniert bei mir aber nicht, weil meine KAcheln in einem anderen
Verzeichnis liegen(?).
#--max-nodes gibt die maximale Anzahl Nodes für eine Kachel an.
java -Xmx2500M -jar ../../splitter/splitter.jar --cache=cache
--geonames-file=DE.zip --write-kml=deutschland.kml --max-nodes=1500000
germany.osm.bz2
cd ../..
###########
Der Anfang des Skripts, das mit mkgmap die einzelnen layer erzeugt:
#########
#!/bin/sh
cd deutschland
date
echo "Hauptlayer..."
cd topo
rm *.img
java -Xmx2800M -jar ../../mkgmap/mkgmap.jar --code-page=1252
--max-jobs=2 --link-pois-to-ways --route --add-pois-to-areas
--family-id=909 --product-id=666 --description="OSM-Topo-DE"
--family-name=Topo --mapname=63240001 --draw-priority=25 --transparent
--remove-short-arcs
--generate-sea=multipolygon,extend-sea-sectors,close-gaps=100
--style-file=/home/ms/osm/garmin-karte/style/topo/ --tdbfile
--gmapsupp ../quelle/*.osm.gz /home/ms/osm/garmin-karte/typ/topo.TYP
cd ..
date
echo "fertig"
echo "Landnutzung..."
cd landuse
rm *.img
java -Xmx2800M -jar ../../mkgmap/mkgmap.jar --latin1 --max-jobs=2
--family-id=909 --product-id=665 --description="OSM-Topo-DE"
--family-name=Landnutzung --mapname=63240700 --draw-priority=21
--style-file=/home/ms/osm/garmin-karte/style/landuse/ --tdbfile
--gmapsupp ../quelle/*.osm.gz /home/ms/osm/garmin-karte/typ/topo.TYP
cd ..
date
##########
...das ganze für alle layer...
Am Schluß wird zusammengefaßt:
##########
date
echo "fertig"
echo "Alle layer zusammenfassen..."
cd ..
java -jar mkgmap/mkgmap.jar --gmapsupp --tdbfile
--description="OSM-Topo-DE" deutschland/gelaende/gmapsupp.img
deutschland/landuse/gmapsupp.img deutschland/topo/gmapsupp.img
deutschland/maxspeed/gmapsupp.img deutschland/extras/gmapsupp.img
deutschland/isohypsen/gmapsupp.img deutschland/wanderwege/gmapsupp.img
date
echo "fertig."
###########
Die grundlegende Funktion der Style-files sieht so aus, daß mkgmap für
jedes osm-Objekt die infrage kommenden Definitionen durchgeht, bis
eine gefunden wird, die darauf passt.
Du könntest z.B. alle highway=cycleway so erwischen:
highway=cycleway[0x10 road_class=1 road_speed=1 resolution 21]
alle highway=cycleway oder highway=path oder highway=footway, die
bicycle=designated haben oder bicycle=official:
( highway=path | highway=footway | highway=cycleway ) & (
bicycle=designated | bicycle=official ) [0x10 road_class=1
road_speed=1 resolution 21]
in "[]" stehen dabei garmin-typ, routingklasse,
routinggeschwindigkeit[4] und die Auflösung, ab der der Weg angezeigt
werden soll.
Normalerweise bricht mkgmap ab und behandelt das nächste Objekt,
sobald ein Ausdruck zutrifft.
Willst du aber mehrere Garmin-Objekte für ein OSM-Objekt verwenden,
kannst du "continue" verwenden, damit mkgmap weiter unten in der
Definition nach einem weiteren Teffer sucht:
Ein highway=cycleway, bridge=yes würde mit diesen Zeilen nur als
Brücke auftauchen:
bridge=yes [0x40 resolution 20]
highway=cycleway [0x10 road_class=1 road_speed=1 resolution 21]
Mit diesen erfasst mkgmap aber beide Eigenschaften:
bridge=yes [0x40 resolution 20 continue]
highway=cycleway [0x10 road_class=1 road_speed=1 resolution 21]
Dann gibt es noch Aktionen, die tags ergänzen oder überschreiben können:
Fahrräder und Autos aus Fußgängerbereichen ausschließen, aber
Fahrräder nur, wenn es nicht schon ein explizites bicycle=* am Objekt
gibt:
highway=pedestrian {add bicycle=no; set motorcar=no} [0x06
road_class=1 road_speed=1 resolution 21]
Man kann damit auch am Anfang der Definitionen tags setzen oder
verändern, die dann für alle Objekte gelten sollen, die später
definiert werden, z.B. schließt dies hier alle Fahrzeuge auf allen
Wegen aus, die mit vehicle=no getaggt sind, es sei denn, sie haben ein
explizites tag:
highway=* & vehicle=no { add motorcar=no; add bicycle=no }
Letztendlich kannst du deiner Karte noch ein individuelles Aussehen
verpassen, indem du ein eigenes TYP-File erzeugst, in dem jedem
Garmin-typen ein eigenes Icon, ein Linienstil oder eine Flächentextur
zugewiesen werden kann(die family-id muss bei TYP und Karte
übereinstimmen!).
Hier gibt es einen guten online-Editor dafür: [5]
Als ich angefangen habe, war es so, daß im mkgmap-Aufruf die .TYP-File
als letztes angegeben werden mußte und die Dateiendung groß
geschrieben werden mußte. Ich weiß nicht, ob das immer noch so ist,
aber so funktioniert es auf jeden Fall.
Ich denke das war das wichtigste, vieles ergibt sich aus den
vorhandenen style-files oder der mailingliste.
Sehr interessant ist noch die option "--link-pois-to-ways", die es dir
erlaubt, aufgrund von tags, die auf nodes in einem Weg liegen, die
Eigenschaften des Weges in einem kleinen Umkreis um den Node zu
verändern.
Damit kannst du z.B. Straßen, die durch einen barrier=bollard gesperrt
sind, für Autos unpassierbar machen oder im Radrouting Drängelgitter
oder Furten vermeiden... :-)
(Openrouteservice kann das z.B. derzeit nicht bieten)
> Das wird in beide Richtungen nicht funktionieren. Mir scheint, irgendwie
> entstehen so "lokale Konsenshäufchen" die dann nicht deutschland- und schon
> gar nicht weltweit zusammen passen.
Ja, gerade deshalb halte ich es für wichtig, explizit zu taggen.
> Entschuldigung, das sehe ich noch nicht so. ;-) Wenn ich einen, sagen wir
> mal nicht straßenbegleitenden Radweg, hübsch asphaltiert, 2m breit,
> erfasse, was ist dann der Unterschied ob ich highway=cycleway; width...;
> surface... schreibe oder highway=path; bicycle=designated; width...
> surface...
>
> Da stecken doch exakt die gleichen Angaben drin?
Ja, wenn das alles drin ist, sind die "bösen" ;) Implikationen
natürlich auch hinfällig, das stimmt.
> Keine Frage! Ich ergänze auch Oberflächen, maxspeed, Stopschilder,
> Drängelgitter usw! Ich habe nur ein Problem damit wenn bewährte Dinge so
> umdefiniert werden dass sie hinterher schlechter sind als vorher, wie ich
> in o.g. Beispiel dargestellt habe.
Ja, wie gesagt, das obige Beispiel ist natürlich Mist, da hat jemand
einfach nicht mitgedacht...
Gruß & viel Spaß beim basteln mit mkgmap,
Martin
[1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[2] http://gis.638310.n2.nabble.com/Mkgmap-Development-f4411397.html
[3] http://wiki.openstreetmap.org/wiki/Mkgmap
[4] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q2/002155.html
[5] http://ati.land.cz/gps/typdecomp/editor.cgi
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
