Ich muss den anderen zustimmen. Wir probieren die Daten weitestgehend unabhängig von der späteren Anwendung zu erfassen. Ich verstehe deine Argumentation, aber wir wollen ebend modellieren wie es da draußen aussieht und das nicht bereits in diesem Schritt interpretieren
Hinter dem obigen Link findest du die aiostyles.7z
Aus dieser Datei brauchst du basemap.TYP und basemap_style. Im Ordner basemap_style kannst du die Datei mit ~ löschen. Dann öffnest du die Datei lines und gehst zu Zeile ~72 (generall access) und fügst unterhalb der vorhandenen Zeile maxheight < 4.0 | maxweight < 7.5 { set hgv=no } ein. Speicherst und fertig ist schon mal der Style.
Dann brauchst du noch splitter.jar und dessen lib-Ordner und mkgmap.jar mit den beiden anderen jar-Dateien.
In den selben Ordner kopierst du dir aus aiostyles.7z aus dem Ordner scripts die Datei build_aio.sh
In der Datei wirst du dann die Pfade anpassen müssen. Weiterhin kannst du bei Splitter_options_Complete --cache und --geonames-file entfernen und --no-trim hinzufügen.
Dann solltest du noch .osm.gz mit .osm.pbf ersetzen.
Hi win32netsky,
hier der Thread, wo ich das auch schonmal ausprobiert hatte: http://forum.openstreetmap.org/viewtopic.php?id=13665
Zusätzlich zu den beiden Regeln maxheight und maxweight benötigt es allerdings noch ein bisschen mehr,
um die access-Hierarchie sauber abzubilden. So werden im Garmin LKW Modus die Flags für motorcar nicht vollständig vererbt.
Ein motorcar = destination oder private gilt im Garmin ebend nur im Automodus und nicht im LKW-Modus, während
im OSM Datenmodell motorcar für alle Kraftfahrzeuge gilt (also auch für LKW).
…oder wechsle zu Navigator free auf einem Windows Mobile-Smartphone: http://navigatorfree.mapfactor.com/de/
Dort gibt es ein LKW-Profil, das du zu einem eigenen Profil mit Gesamtgewicht, Achslast, Länge, Breite und Höhe anpassen kannst.
Demnächst soll übrigens eine Android-Version rauskommen
Musste gestern Abend leider feststellen, dass diese Profile nicht mit den freien OSM-basierten Karten verwendbar ist. Ich vermute, “unsere” Datenqualität reicht dafür noch nicht aus
Es fehlen wohl einfach noch zuviele maxweight, maxheight, maxwidth an unseren highways.
Gibt es eigentlich ein Tool, mit dem ich erkennen kann, wo diese tags fehlen?
willst du etwa an alle highways maxweight, maxheight, maxwidth “ranklatschen”, blos weil ein bestimmtes Programm keine Defaults kennt?
Dass vergiss bitte nicht "oneway=no, bridge=no, tunnel=no, u.s.w.
Nein ,das will ich keinesfalls! Das kann und soll es sicher nicht sein und so wollte ich das auch nicht interpretiert wissen.
Ich meine natürlich nur solche Straßen- bzw. Wegteile, die von den defaults negativ abweichen und mit entsprechenden Schildern gekennzeichnet sind.
Wenn, würde ein solches Tool nur anzeigen, wo sie (nicht) vorhanden sind. Ob sie tatsächlich fehlen oder nur schlicht unnötig sind, weil max(height|weight|width|…) für alle zulassungsfähigen Fahrzeuge ausreicht, kann kein Algorithmus erkennen. Von daher wäre der Nutzen einer entsprechenden Karte eher gering und hätte allenfalls den “Erfolg”, daß dann doch auf etlichen Straßen Standardwerte eingetragen würden.
Überall, wo eine Straße eine andere Straße, Bahngleis, Gebäude unterquert, könnte doch ein maxheight fehlen. Ein tool, das solche Stellen anzeigt, wäre durchaus hilfreich.
war dann wohl ein Mistsverständniss.
Die tags drinzuhaben, die die Strecke besser beschreiben, dürfte wohl noch lange dauern. Es gibt halt viele Interessenten und Zielgruppen bei OSM und nicht jeder interessiert sich für Brückenhöhen oder Ähnliches.
Ich mach ja beim Taggen auch einen riesengrossen Bogen um HKTS (Hundekottüten-Spender)
Nun so eine Karte wäre schon gut um mal einen Eindruck vom jetzigen Stand der Erfassung zu bekommen. Klar weiß man nicht, inwieweit nun wirklich die Infos fehlen oder ob es schlichtweg garnicht soooo häufig ausgeschildert ist.
Es gab mal jemand, der Kreuzungen von Eisenbahnen und Flüssen ermitteln konnte und der bei OSMBugs dann entsprechende Einträge generiert hat. Das wäre ja im Prinzip nix anderes.