DE:All in one Garmin Map

flux · 2010-02-23 06:50:05

Nein, ich nehme alles zurück ...

Das waren wohl atmosphärische Störungen, die mein Vista HCx da geritten haben. Heute routet das Vista HCx wieder genauso falsch wie die Tage zuvor.

Ausschalten gestern abend in der Freude, dass alles passt, anschalten heute und Ernüchterung. Die Einstellungen sind unverändert, definitiv.

flux.

master · 2010-02-23 10:04:23

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.
Die Kacheln könnten somit aufgrund der geringeren Daten größer werden. Vielleicht sollte ich auch ein festes Raster verwenden.

Punkte, Flächen und übrig gebliebene Linien könnte ich dann in einen anderen Layer packen.
Ich könnte mir vorstellen, dass das funktioniert, müsste aber ganz schön viel testen dazu.

Mal sehen, ob da was geht. Vielleicht findet ja auch noch jemand was anderes raus, was hier helfen könnte.

Viele Grüße!
Christoph

PS: Seh ich eigentlich irgendjemanden von euch zur FOSSGIS?

geopia · 2010-02-23 20:37:27

master wrote:

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.

Eine Trennung der Straßen von anderen Objekten ist wahrscheinlich eine gute Idee.

Man könnte aber auch noch einen Schritt weiter gehen und sämtliche für das Routing relevanten Elemente vollständig von den Elementen für die Darstellung der Karte trennen.
* Dabei würde eine dedizierter (optisch unsichtbarer) Layer ausschließlich Informationen zum Routing enthalten.
* Weitere (sichtbare) Layer würden dann zusätzlich die Darstellung der Straßen (und Flächen, ...) enthalten.

Dabei hätte man dann zwar in Summe viele Elemente (nämlich die Wege) doppelt, aber man hätte eine völlige Trennung zwischen der Routing-Informationen einerseits und der grafischen Darstellung andererseits.

Der Routing-Layer könnte dann mit viel weniger, möglicherweise sogar ohne, Kachelung auskommen.

Das hätte auch den Vorteil, dass man bei der grafischen Darstellung nicht mehr auf Einschränkungen bei der Definition der routing-spezifischen Eigenschaften Rücksicht nehmen müßte.

Last edited by geopia (2010-02-23 20:39:17)

flux · 2010-02-23 20:53:08

Sagt wie ihr das anpacken wollt (technisch, mit splitter/mkgmap) und ich kann mithelfen, testen, habe Zeit dazu und Interesse auch!

flux.

Walter Schlögl · 2010-02-23 22:02:48

Ich habe auch bereits Beeinträchtigungen beim Routing über Kachelgrenzen hinweg festgestellt,
habe es aber meist auf schlecht verbundene Wege geschoben.

Nach welcher Methode trennt der Splitter eigentlich die Kacheln auf, dass mkgmap über die Grenze hinweg überhaupt routen kann?
Vielleicht liegt ja gerade darin das Problem, dass diese Trennung nicht wieder sauber zusammengefügt wird.

Walter

flux · 2010-02-23 22:07:52

Probleme grundsätzlicher Art beim Routen über Kachelgrenzen kann ich nicht feststellen, lediglich in Einzelfällen eine längere Route, die einer kürzeren vorgezogen wird.

Ich kann von Flensburg korrekt nach Novigrad routen, ohne Fehler, Route ist ok, ca. 18 Kacheln werden durchfahren.
Ich kann von Regensburg nicht korrekt nach Reutlingen routen, Umweg und längere Zeit wird geroutet, ca. 5 Kacheln werden durchfahren.

Ich habe auch schon verschiedene --overlap=WERT im splitter verwendet, keine Änderung (default WERT = 2000).

flux.

Last edited by flux (2010-02-23 22:09:17)

master · 2010-02-24 11:30:43

geopia wrote:

master wrote:
Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.
Eine Trennung der Straßen von anderen Objekten ist wahrscheinlich eine gute Idee.
Man könnte aber auch noch einen Schritt weiter gehen und sämtliche für das Routing relevanten Elemente vollständig von den Elementen für die Darstellung der Karte trennen.
* Dabei würde eine dedizierter (optisch unsichtbarer) Layer ausschließlich Informationen zum Routing enthalten.
* Weitere (sichtbare) Layer würden dann zusätzlich die Darstellung der Straßen (und Flächen, ...) enthalten.
Dabei hätte man dann zwar in Summe viele Elemente (nämlich die Wege) doppelt, aber man hätte eine völlige Trennung zwischen der Routing-Informationen einerseits und der grafischen Darstellung andererseits.
Der Routing-Layer könnte dann mit viel weniger, möglicherweise sogar ohne, Kachelung auskommen.
Das hätte auch den Vorteil, dass man bei der grafischen Darstellung nicht mehr auf Einschränkungen bei der Definition der routing-spezifischen Eigenschaften Rücksicht nehmen müßte.

Naja, das ist dann wohl doch keine so super gute Idee! Ich habe mal spaßenshalber das Europafile genommen und mit Osmosis alle highways inklusive Relationen extrahiert und in ein separates File geschrieben:

bzcat europe.osm.bz2 | osmosis-0.34/bin/osmosis --rx - --b --tf accept-ways highway=* --un idTrackerType=BitSet --wx - |bzip2 > europe_roads.osm.bz2

Der Größenvergleich der Files zeigt, dass die Straßendaten viel ausmachen:

europe.osm.bz2 : 2,9G
europe_roads.osm.bz2 : 1,4G

Nur aus Gründen der Darstellung quasi die 1,4G doppelt einzubauen, halte ich für ziemlich unklug. Im Übrigen dauert die Extraktion auch seine Zeit. Ich meine ich müsste natürlich nicht vorher extrahieren und könnte einfach die mkgmap-styles entsprechend anpassen, dass sie einmal nur die Straßen bauen und einmal dann den Rest, aber dann kann ich wieder keine unterschiedliche Kachelung verwenden.
Bei der Kachelung weiß ich eh gerade nicht, ob das überhaupt was bringt, denn die wird ziemlich ähnlich der jetzigen aussehen.

Zum Thema routing über Kachelgrenzen hab ich auch nen interessanten Thread auf der mkgmapliste gefunden:
http://www.mkgmap.org.uk/pipermail/mkgm … 03396.html

Allerdings hab ich noch nirgends ne Lösung des Problems gesehen.

Mal sehen, ob da noch was kommt...

Ach so - ich hätte noch was zum testen bzw. rausfinden.

Ich habe in meinen Styles im basemapstyle bei den lines für die Straßen folgendes stehen:

highway=motorway & (maxspeed>110) [0x01 road_class=4 road_speed=7 resolution 12]
highway=motorway & (maxspeed>90 & maxspeed<111) [0x01 road_class=4 road_speed=6 resolution 12]
highway=motorway & (maxspeed>80 & maxspeed<91) [0x01 road_class=4 road_speed=5 resolution 12]
highway=motorway & (maxspeed>60 & maxspeed<81) [0x01 road_class=4 road_speed=4 resolution 12]
highway=motorway & (maxspeed>40 & maxspeed<61) [0x01 road_class=4 road_speed=3 resolution 12]
highway=motorway & maxspeed<41 [0x01 road_class=4 road_speed=3 resolution 12]
highway=motorway [0x01 road_class=4 road_speed=7 resolution 12]

Das Beispiel für motorways zeigt, wie ich prinzipiell für Straßen je nach gesetztem maxspeed unterschiedliche road_speeds vergebe.
Ob das wirklich so klappt weiß ich nicht mal hunderprozentig, da sie ja alle auf den selben Garmintyp gemappt werden.

Allerdings sehe ich hier auch ein Problem, was passiert, wenn im maxspeed-tag keine zahl sondern ein text steht? Es gibt da so Texte, wie "DE:urban" oder "variable" oder "unlimited" etc.
Schlägt der Vergleichstest dann fehl oder wird da einfach 0 angenommen (könnte eine Schlechtbewertung von manchen Autobahnabschnitten erklären) oder was passiert da eigentlich genau?

Hab leider nicht die Zeit das alles im Detail rauszufinden - bin über Hilfe sehr dankbar!
Man könnte eventuell auch mal auf der mkgmap-dev nachfragen...

Grüße!
Christoph

flux · 2010-02-24 13:34:09

Ich habe mit deinem Stylefile (lines) und mkgmap zwei Karten aus der germany.osm.bz erstellt.

Karte 1: Splitter mit --max-nodes=1900000 (mehr geht nicht) --> 32 Kacheln
mkgmap nur mit dem Stylefile lines (points und polygons vorher gelöscht) gestartet
Teststrecke Regensburg - Reutlingen geht über Nürnberg, nicht die schnellste und nicht die kürzeste Strecke, wie bisher also fehlerhafte Berechnung

Karte 2: Splitter mit --max-nodes=400000 --> 146 Kacheln
mkgmap wie oben
Teststrecke wird wie oben berechnet

Dann habe ich 2 Karten mit dem Default-Stylefile von mkgmap aus der germany.osm.bz2 erstellt.

Karte 1: alles wie oben, nur das Original-Stylefile
Routing Regensburg - Reutlingen geht über München, die kürzeste und schnellste Strecke per Autobahn (nur die Route über die B300 wäre noch kürzer und schneller, sind aber ca. 60 km Bundesstraße)

Karte 2: alles wie oben, nur das Original-Stylefile
Routing Regensburg - Reutlingen geht über München ...

Es muss also am Stylefile bzw. der Auswertung der Geschwindigkeit in der road_class liegen, die ja im Original komplett fehlt.

Soweit meine bisherigen Tests.

Das Routen mit einem Zwischenpunkt auf der A8 Höhe Ulm klappt mit allen 4 Karten korrekt, Regensburg - Reutlingen über BAB, B300, BAB = kürzeste und schnellste Strecke.

Getestet wurde auf dem Vista HCx (Kürzere Zeit, PKW, beste Route) und auf dem Oregon 300 (Schnellere Strecke). Die Ergebnisse auf beiden Geräten mit allen 4 Karten sind übereinstimmend.

flux.

chris66 · 2010-02-24 14:14:11

Es muss also am Stylefile bzw. der Auswertung der Geschwindigkeit in der road_class liegen, die ja im Original komplett fehlt.

nur wenn --ignore-max-speeds gesetzt ist, sonst nimmt er eine Default-Logik.

Chris

flux · 2010-02-24 16:25:43

Damit ich es richtig verstehe: Der Default-Style von mkgmap (/mkgmap-r*/resources/styles/default/) hat keine Geschwindigkeitsangaben in der Datei lines wie sie Christoph hat. Diesen Default-Style nehme ich als Original-Style zum Bauen der Karten und vergleiche die Ergebnisse mit der Karte mit Christoph's Style.

Die Original-Karte routet annähernd korrekt, die mit Christoph's Style erstellte nicht.

Die Default-Logik scheint also richtiger zu rechnen als die "getunte" ...

--ignore-maxspeeds macht dann was? Vielleicht wird ja dann sogar noch genauer geroutet?

flux.

Last edited by flux (2010-02-24 20:44:12)

flux · 2010-02-24 22:12:03

Zwischenzeitlich habe ich zwei Karten mit dem Original-Style von mkgmap (Version r1584) erstellt (Splitter mit --max-nodes=400000, um viele kleine Kacheln zu erhalten und zu schauen, ob sich ein Unterschied zu großen Kacheln ergibt).

Karte 1: --ignore-maxspeeds
Karte 2: ohne --ignore-maxspeeds

Karte 1 berechnet Regensburg - Reutlingen über München, wie bisher zweitschnellste und zweitkürzeste Strecke (Vista HCx --> Kürzere Zeit, Auto/Motorrad, keine Vermeide-Optionen), Reutlingen - Regensburg wird über die B300 berechnet, schnellste und kürzeste Strecke

Karte 2 identisch

Karte 1 bricht Berechnung Regensburg - Freilassing mit Routenberechnungsfehler ab, Karte 2 berechnet korrekt.

Wird "Vermeide Kehrtwenden" aktiviert berechnen beide Karten von Reutlingen nach Regensburg über Würzburg (100 km länger als ohne "Vermeide Kehrtwenden").

Mit beiden Karten ist aufgrund der hohen Kachelzahl (146 Kacheln) die Suche nach Städten nicht mehr möglich, das Vista HCx schaltet nach ca. 4 Sekunden nach Beginn der Suche ab.

Heute werde ich diese Karte noch mit 32 Kacheln erstellen und dann das ganze Prozedere (einmal 146, einmal 32 Kacheln, einmal mit und einmal ohne --ignore-maxspeeds) noch einmal mit dem Stylefile von Christoph.

Dann weiß ich mehr.

flux.

Last edited by flux (2010-02-25 07:00:40)

wmann · 2010-02-25 11:23:15

Hallo,

bin auch relativ neu bei OSM. Erst einmal danke eine Super Arbeit die hier geleistet wird.
Ich verwende die AIO Europa auf meinem Oregon 300 und mir ist jetzt schon öfters aufgefallen, dass Brücken nicht sichtbar sind. Laut OSM.org sind die Brücken auch in der Karte.

Ist das Absicht, ein Fehler oder einfach noch nicht implementiert ? Danke für die Info.

Gruß
wmann

stevebiker · 2010-02-25 19:09:27

Hi,

ich bin gar nicht begeistert! Habe alle .exe Dateien der Europa geladen, installiert, habe jetzt in MapSource ein haufen Einträge, aber praktisch nur eine Karte, die anderen mit Linien usw. Aber, was am schwersten wiegt, ich kann die Karten nicht mehr deinstallieren! Es gibt keinen Eintrag unter Software! Ist offensichtlich unsauber programmiert. Wie bekomme ich diese wieder von meinem Computer weg!?

Gruß,
stevebiker

mapfriend70 · 2010-02-25 20:16:00

Hi stevebiker,

so ganz kann ich das noch nicht nachvollziehen, aber um die Karten zu deinstallieren lädst du dir MapSetToolkit runter.
Findest du unter http://cypherman1.googlepages.com/

Die Exe Datei einfach in einen Ordner kopieren und starten. Wird auch nicht in der Windows Reg eingetragen.
Dann unter Mapset installed die Karten auswählen und uninstall - fertig.

Gruß
mapfriend70

P.S. Ich denke du solltest dich noch ein wenig mit der Sache beschäftigen, dann wirst du sehen, dass OSM und Co. ne super Sache ist.

stevebiker · 2010-02-25 20:35:22

Hi mapfriend70,

danke Dir für die antwort. Mit OSM habe ich mich schon auseinandergesetzt, auch durch aktives Loggen. Die All in One habe ich auf eine Empfehlung aus dem Naviboard installiert. Hatte aber keine Zeit mich damit näher zu befassen, die Erklärung auf der Homepage ist meiner Meinung nach nicht außreichend. Bisher hatte ich mit den Karten von openmtbmap gute Erfahrungen, auch das Kartenbild hat mir besser gefallen. Momentan habe ich für langwierige Konfigurationsaktionen für OSM Karten weder die Zeit, noch die Lust, noch dazu, wo ich jetzt vermehrt mit einem Lowrance Safari neue Erfahrungen sammle.

Gruß, stevebiker.

RufusB · 2010-02-26 10:04:36

Hallo,
ich habe heute am 26.2 die aktuelle Karte heruntergeladen ,beim Test im e trex habe ich festgestellt ,wenn man irgendeinen Punkt der unbelegt ist anklickt so wird der als Land angezeigt .Will man also einen Punkt markieren um ihn später zu erfassen ,so muss man ihn erst speichern -etwas umständlich -War früher nicht so.Kann man die freien Stellen nicht unbelegt lassen?

Weide · 2010-03-01 14:51:56

geopia wrote:

master wrote:
Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen.
Das Gebiet, in dem bei mir die häufigen Abbrüche lagen, scheint von einer Kachelgrenze durchzogen zu sein.
Bei Experimenten mit von mir selbst gebauten Karten konnte ich auch eine Abhängigkeit von den Splittereinstellungen feststellen.
Eine unterschiedliche Heapgröße für Java führte bei ansonsten gleichen Einstellungen zu unterschiedlicher Kachelung und auch zu unterschiedlichen Routingergebnissen. Routen über eine Kachel-Grenze hinweg waren teilweise unmöglich oder wurden mit sehr seltsamen Umwegen berechnet.

Hmm, wieso gibt es überhaupt die Meldung "Routenberechnungsfehler". Das bedeutet doch, dass das Verfahren zu einem Fehler in der Lage ist und den auch noch erkennen kann!

Es gibt einen solchen Routing-Algorithmus. Der arbeitet mit Entfernungsschätzungen. Das Ergebnis ist exakt, aber die Schätzungen dürfen dann auf keinen Fall größer sein, als die wirkliche Entfernung. Als Schätzung kann man z.B. die Luftlinienentfernung nehmen, die kann nicht größer sein als die wirkliche Entfernung. Bessere Schätzungen würden das Verfahren aber erheblich beschleunigen und -- vielleicht noch wichtiger -- den Speicherhunger vermindern.

Vielleicht enthalten die Kacheln bislang unidentifizierte Daten für eine solche bessere Schätzung -- sowas in der Art "von unten nach oben mindestens 18,3km" usw.. Wenn diese Daten nicht stimmen, dann würden die beschriebenen Effekte auftreten. Routenberechnungsfehler, wenn die Schätzwerte größer sind als die realen Werte; lustige Umwege, wenn die Zahlen nicht korrekt sind; Routen mit möglichst wenig Kacheln, wenn überall dasselbe als Schätzwert eingetragen ist.

Nur so ne Idee...

Weide

flux · 2010-03-01 15:53:57

Ich habe inzwischen mit der mkgmap-Option --ignore-maxspeeds und dem Original-Stylefile keinerlei Probleme mehr und eine korrekte Routenberechnung.

Mehr brauchts für mich nicht, die Fehlermeldung scheint sowieso niemand erklären zu können ...

flux.

Peter Maiwald · 2010-03-02 16:28:23

Ich wollte mal eine Rückmeldung geben über die All-In-One-Garmin-Map Deutschland auf einem Nüvi 255t. Das Nüvi hab ich ganz frisch und hatte vorher auch noch kein Navi. Mit der OSMkarte fahre ich jetzt seit 3 Tagen.

Erster Eindruck (in Berlin):
- Adresseingabe funktioniert nicht.
- Die Ansagen beim Routing kommen teilweise reichlich früh. Nach "links abbiegen" kommen noch 3 Straßen vorher.
- Ziel auf der falschen Seite angesagt.
- Keine Maxspeed Angaben. (Oder sind das die Zahlen, die manchmal in Klammern hinter dem Straßennamen stehen? Mit den Garminkarten bekomme ich ein Verkehrsschild mit der Höchstgeschwindigkeit auf dem Display links neben der Straße angezeigt.)
- Die Namen der Querstraßen beim Vorbeifahren werden fast nie angezeigt. (Habe das Gefühl, dass nur kleine Wege von Gartenkolonien oder ähnlich angezeigt werden.)
- Neuberechnung im Kreisverkehr obwohl vorher korrekt angesagt wurde.

Gut gefallen mir die ein- oder ausblendbaren Höhenlinien und dass ich z.B. alle Wanderwege im Elbsandsteingebirge angezeigt bekomme, die sonst erst auf kommerziellen Karten 1:15000 auftauchen.

Also grundsätzlich kann man schon gut damit fahren. Besten Dank für die Arbeit.
Trotzdem wäre es natürlich noch besser wenn die obigen Probleme auch noch gelöst werden könnten.

Ich konnte übrigens die Europakarte nur feherhaft herunterladen. Ich habe nur so einen Surfstick mit 5GB Trafficlimit im Monat. Danach wirds langsam. Die Europakarte hatte ich bei einer Freundin mit DSL heruntergeladen und beim Auspacken zu Hause bekam ich nur Fehlermeldungen und Abbrüche. Die Deutschlandkarte hab ich mit meinem Surfstick und "Downloader für X" (ein Downloadmanager für Linux) zwei mal heruntergeladen. Die erste Datei konnte auch nicht entpackt werden.

MHohmann · 2010-03-02 19:42:34

Hm... Das mit den Höchstgeschwindigkeiten ist interessant. Ich hatte gedacht, dass mkgmap genau diese als road_speed in die Garmin-Karte einträgt. Aber anscheinend haben die Original-Garmin-Karten da noch eine andere Information.
Vielleicht erklärt das auch, warum diese road_speed Einträge scheinbar zu einem falschen Routing führen - oder zumindest, warum es sich durch --ignore-maxspeeds beheben lässt. Möglicherweise ist die Umsetzung maxspeed => road_speed => Höchstgeschwindigkeit in der Garmin-Karte bei mkgmap fehlerhaft.

Ach ja, die Zahlen in Klammern müssten tatsächlich die Höchstgeschwindigkeiten sein.

Peter Maiwald · 2010-03-02 21:37:10

Ich habe leider (noch) überhaupt keine Ahnung wo das Nüvi sich welche Information her holt. Falls mir einer auf die Sprünge helfen kann könnte ich da mal nachsehen. Oder auch andersherum. Ich kann auch jemand eine Datei vom Nüvi senden im sie zu analysieren. Wäre dann auch interessant welche Datei.
Zum öffnen von komischen Formaten wäre es vielleicht noch wichtig, dass ich kein Windows besitze und ausschließlich Linux verwende.

Ich wurde gerade in einen Zaun geroutet! Auf dem Weg ist ein Node mit barrier=gate getagt. Zwei Meter hohes Tor nur für Firma zugänglich. Im Wiki steht: Standardmäßig ist access=no ist impliziert, deshalb sollten Zugangsberechtigungen für das Element vergeben werden. Weitere Zugangsberechigungen stehen da aber nicht in dem Node.

Last edited by Peter Maiwald (2010-03-02 21:52:22)

Walter Schlögl · 2010-03-02 22:07:25

mkgmap wertet gewisse TAGs für's routing aus (z.B. bicycle=*, oneway=*, usw.), vielleicht ja auch maxspeed.
Leider wird von den Programmierern von mkgmap nur sehr oberflächlich dokumentiert, was da eigentlich programmiert wurde.
Oder ich habe diese Dokumentation einfach noch nicht gefunden.
Vermutlich muss man sich den Sourcecode herunterladen und durchforsten.

Walter

Peter Maiwald · 2010-03-04 13:25:41

Schon wieder komisch gerouted worden.
http://www.openstreetmap.org/?lat=52.51 … rs=B000FTF
Ich kam von der Mühlsamstr., links von der Petersburger Str. in Fahrtrichtung Petersburger Straße und sollte letztendlich links auf die Petersburger Str. abbiegen. Nur sollte ich nicht einfach links rum fahren sonder rechts auf die Petersburger, um den Bersarinplatz und dann geradeaus auf der Petersburger (an der Mühsamstr. vorbei).
Warum soll ich so einen Schlenker fahren, wenn ich doch einfach links abbiegen kann? Ich habe keine Restriction oder so gefunden an der Kreuzung, die das Linksabbiegen verbieten würde.

Garmin-User · 2010-03-04 19:06:12

Peter Maiwald wrote:

Schon wieder komisch gerouted worden.
http://www.openstreetmap.org/?lat=52.51 … rs=B000FTF
Ich kam von der Mühlsamstr., links von der Petersburger Str. in Fahrtrichtung Petersburger Straße und sollte letztendlich links auf die Petersburger Str. abbiegen. Nur sollte ich nicht einfach links rum fahren sonder rechts auf die Petersburger, um den Bersarinplatz und dann geradeaus auf der Petersburger (an der Mühsamstr. vorbei).
Warum soll ich so einen Schlenker fahren, wenn ich doch einfach links abbiegen kann? Ich habe keine Restriction oder so gefunden an der Kreuzung, die das Linksabbiegen verbieten würde.

Wer weiß schon genau, wie der Routing-Algorithmus der jeweiligen Firmware funktioniert? Vielleicht verwendet dieser die erstbeste Petersburger Straße die er findet und diese ist nunmal eine Einbahnstraße. Zwar erstmal weg vom Ziel, aber eine weitere Verfolgung bringt ja dann bald die Möglichkeit der Umkehr, weswegen der Algorithmus sich so entscheidet. Ist nur so ein Gedanke. Ob man (anspruchsvolle) Restriktionen überhaupt im Style-File für die Kartenerzeugung konfigurieren könnte, sei dahingestellt.

chris66 · 2010-03-04 19:12:14

Peter Maiwald wrote:

Ich wurde gerade in einen Zaun geroutet! Auf dem Weg ist ein Node mit barrier=gate getagt. Zwei Meter hohes Tor nur für Firma zugänglich. Im Wiki steht: Standardmäßig ist access=no ist impliziert, deshalb sollten Zugangsberechtigungen für das Element vergeben werden. Weitere Zugangsberechigungen stehen da aber nicht in dem Node.

Um das zu erreichen gibt es die --link-pois-to-ways Option[1] bei mkgmap, zusätzlich muss man
es im Style-file triggern:

barrier=gate {add access=yes; add motorcar=no} [0x7000 resolution 24]

Durch access wird die --link-pois-to-ways Option getriggert und durch add motorcar=no
das Autorouting über die Schranke vermieden.

Chris

[1] --link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
way's properties. Currently supported are POIs that restrict
access (e.g. bollards). Their access restrictions are applied
to a small region of the way near the POI.

Announcement

#176 2010-02-23 06:50:05

Re: DE:All in one Garmin Map

#177 2010-02-23 10:04:23

Re: DE:All in one Garmin Map

#178 2010-02-23 20:37:27

Re: DE:All in one Garmin Map

#179 2010-02-23 20:53:08

Re: DE:All in one Garmin Map

#180 2010-02-23 22:02:48

Re: DE:All in one Garmin Map

#181 2010-02-23 22:07:52

Re: DE:All in one Garmin Map

#182 2010-02-24 11:30:43

Re: DE:All in one Garmin Map

#183 2010-02-24 13:34:09

Re: DE:All in one Garmin Map

#184 2010-02-24 14:14:11

Re: DE:All in one Garmin Map

#185 2010-02-24 16:25:43

Re: DE:All in one Garmin Map

#186 2010-02-24 22:12:03

Re: DE:All in one Garmin Map

#187 2010-02-25 11:23:15

Re: DE:All in one Garmin Map

#188 2010-02-25 19:09:27

Re: DE:All in one Garmin Map

#189 2010-02-25 20:16:00

Re: DE:All in one Garmin Map

#190 2010-02-25 20:35:22

Re: DE:All in one Garmin Map

#191 2010-02-26 10:04:36

Re: DE:All in one Garmin Map

#192 2010-03-01 14:51:56

Re: DE:All in one Garmin Map

#193 2010-03-01 15:53:57

Re: DE:All in one Garmin Map

#194 2010-03-02 16:28:23

Re: DE:All in one Garmin Map

#195 2010-03-02 19:42:34

Re: DE:All in one Garmin Map

#196 2010-03-02 21:37:10

Re: DE:All in one Garmin Map

#197 2010-03-02 22:07:25

Re: DE:All in one Garmin Map

#198 2010-03-04 13:25:41

Re: DE:All in one Garmin Map

#199 2010-03-04 19:06:12

Re: DE:All in one Garmin Map

#200 2010-03-04 19:12:14

Re: DE:All in one Garmin Map

Board footer