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