Routingfähige Karte mit OSM-Composer erstellen

Walter_Schlögl · 2009-12-28T22:08:53.000Z

Hallo Henning,

ich verstehe deine Umsetzungsidee ehrlich gesagt nicht. Was genau soll dort eingetragen werden? Kannst du dazu mal ein Beispiel angeben.

Es müßte doch eigentlich genügen, wenn bei den Renderregeln 2 zusätzliche Felder sind. Dort trage ich einfach die beiden Werte jeweils als Zahl ein, fertig.
Ok, die Ersetzungen müssten noch den Zahlenvergleich < / > beherrschen, damit die maxspeed ausgewertet werden kann.

Ich habe übrigens noch einen Parameter beim Aufruf von mkgmap vergessen zu erwähnen, da er bei mir bereits im Default-File gelandet ist.
–road-name-pois bewirkt, dass für jede Straße ein POI angelegt wird (Default mit ID 0x640a, diese finden sich beim Oregon unter Geografische Punkte/Gebäude)
Ich habe auch mit anderen IDs experimentiert, aber noch keine brauchbaren Ergebnisse.

Sinn dieser Aktion ist, dass man nach Straßen suchen kann, da bei der normalen Suche nach Adressen die berühmte Frage nach dem Landesteil kommt, auf die es derzeit keine gültige Antwort gibt.
Bei alten Geräten soll die Adress-Suche funktionieren. Dazu muss der Plan aber mit MapSource auf das Gerät geladen werden.

Walter

aighes · 2009-12-28T22:39:56.000Z

Walter Schlögl:

Hallo Henning,

ich verstehe deine Umsetzungsidee ehrlich gesagt nicht. Was genau soll dort eingetragen werden? Kannst du dazu mal ein Beispiel angeben.

Es müßte doch eigentlich genügen, wenn bei den Renderregeln 2 zusätzliche Felder sind. Dort trage ich einfach die beiden Werte jeweils als Zahl ein, fertig.
Ok, die Ersetzungen müssten noch den Zahlenvergleich < / > beherrschen, damit die maxspeed ausgewertet werden kann.

Hallo,

meiner Meinung sollte es eine Trennung zwischen Routing und Grafik im Composer geben.
Für das Routing könnte man den Aufbau der Ersetzungsdialoge übernehmen. Bei Bedingung kommen die Bedingungen fürs Routing hinein und da wo bei den Ersetzungen die Aktionen stehen gibt ein zwei DropDown-Boxen, wo man road_class und road_speed angeben kann.

Eine Trennung halte ich für sinnvoll, da man nicht 50 Renderregeln braucht, die die gleiche Grafik produzieren (bpsw. eine Landstraße), ich aber dennoch genau spezifizieren möchte, welche road_class die bestimmte Tagkombination bekommen soll.

Mal schauen, was nop dazu sagt…

Walter_Schlögl · 2009-12-29T10:48:19.000Z

Jetzt verstehe ich,

bei meinem Vorschlag benötige ich für einen Straßentyp mit 7 verschiedenen maxspeed Bereichen 7 Einträge in den Ersetzungen und ebenfalls 7 Einträge in den Renderregeln. Dafür habe ich die Flexibilität, auch noch je maxspeed verschiedene Resolutions anzugeben (eher selten benötigt).

Deine Lösung kommt mit 1x7 Zeilen aus.

Walter

Nop · 2009-12-29T13:00:29.000Z

Erst mal vielen Dank für die umfangreiche Vorbereitung. Momentan bin ich voll mit der Online-Version der Wanderkarte beschäftigt, aber das werde ich bald in Composer einbauen.

Ich denke es wird auf eine Kennzeichnung von Routingfähigen Kartenobjekten sowei zwei neue Drop-Down-Boxen bei den Renderregeln hinauslaufen, in denen man den Road Type usw. einstellen kann. Eine Geschwindigkeitsabhängigkeit könnte man auch einbauen, ähnlich zur Größenabhängigkeit (neu ab 0.8).

Ein extra Dialogsystem werde ich nicht dafür bauen. Man könnte zwar ein paar Regeln sparen, aber es wird sehr unübersichtlich, wenn man in drei Tabellen nachsehen muß, bevor man weiß was man da eigentlich eingestellt hat. Und Composer soll die Dinge ja einfacher machen.

bye
Nop

Walter_Schlögl · 2009-12-29T22:21:59.000Z

Hallo Nop,

prima, ich denke, so würde es funktionieren.

Ehrlich gesagt, habe ich mich mit dem neuen Feature der Größenabhängigkeit noch gar nicht beschäftigt.
Ich denke, dass man damit kleinere Flächen wie z.B. kleine Seen irgendwie ausblenden kann.
Bin schon gespannt, was damit alles machbar sein wird. Ich hoffe, du kommst bald dazu, das neue Feature zu beschreiben.

Ich hab jetzt auch eine bessere Lösung für road-name-pois gefunden. (Edit: für Garmin Oregon, nicht für MapSource)


--road-name-pois=0x2f09

Damit werden Straßen nicht bei “Geografischen Punkten” unter die Türme und anderes gemischt, sondern in einen eigenen Punkt unter Others/Marina_Boat_Repair_and_Storage.
Im gtt-File sollte man diesen Eintrag dann auf “Straßen” ändern.

Damit mkgmap diese POIs auch anlegt, muss diese ID im Typ-File vorkommen. Ich habe dafür einfach einen transparenten Dummy-Punkt gesetzt.
Man kann auf die restlichen POIs unter Others (2f0f bis 2f15) natürlich auch noch weitere interessante Punkte mappen. Meine Karte wird auf diese Art immer umfangreicher.

Walter

Nop · 2010-01-04T18:06:02.000Z

So, ich hab jetzt eine erste Umsetzung in Composer eingebaut, werde eine neue Version bereit stellen sobald sie einigermaßen rund aussieht.

Mit was für Daten und Usecases hast Du eigentlich das Routing ausprobiert? Besonders interessant ist die Frage, ob das Routing über Kachelgrenzen hinweg auch funktioniert. Dort müssen die Straßen ja aufgetrennt werden. Ich habe keine Ahnung, was für Voraussetzungen dafür nötig sind, wenn das funktioniert wäre es reiner Zufall.

bye
Nop

tippeltappel · 2010-01-05T04:55:20.000Z

@ Nop
Da bin ich gespannt, wie die neue Version dann funktioniert.

@ Walter
Eine Zweckentfremdung der ID 0x2f09 für die Straßennamen finde ich nicht passend.
Wie Du schon schreibst: Sie bezieht sich in MapSource auf die Kategorie Marine / Unterkategorie Yachthafen Reparatur und Lager.
Und für die Kategorie kenne ich bislang keine weiteren IDs. Da ich in der Nähe eines großen Flusses wohne, wo es so einige malerische Yachthäfen gibt, mag ich die ID lieber korrekt benutzen.

Teste mal
0x31 0x00
0x31 0x01
0x31 0x02
0x31 0x03
0x31 0x04
0x31 0x05

Die sollten allesamt in der

Kategorie Unterkategorie
Autoservices Händler/Autoteile

auftauchen. Bei dem Massenangebot kann man eher eine ID zweckentfremden.
Logisch ist das aber auch nicht. Und die Anzeige der nächsten Autowerkstatt geht in der Liste von Straßen unter.

Wie wäre es mit der ID 0x11 0x00?
Die wird von Garmin für Dörfer mit unter 100 Bewohnern benutzt.
Die Adress-Suche müllt dann allerdings die Städteliste zu.
Ist unter dem Gesichtspunkt also keine gute Idee.

0x64 0x0a Geografische Punkte / künstlich (MapSource)
Finde ich da noch am logischsten.

Ob die Adresssuche in der Wander-Reit-Karte allerdings am Ende einigermaßen funktioniert, bleibt noch abzuwarten. Das Problem: Je umfangreicher die Suchergebnisliste wird, um so größer ist die “Chance”, daß sich das GPS-Gerät bei der Suche aufhängt. Da viele Wanderwegmarkierungen Marine IDs nutzen, die in MapSource in der Suchergebnisliste angezeigt werden, ist diese Liste bereits sehr lang. Im Vista werden allerdings nur die als Marine/Gefahrenpunkt definierten IDs angezeigt. Die “Tonnen” sieht man nur auf der Karte und nicht in der Liste. Seitdem ich nur noch Sperren (Tore, Umlaufsperren etc. mit Gefahrenpunkt-IDs markiere, ist die Liste kürzer geworden. Und trotzdem: Die Städte-Suche gelang auf meinem VistaHCX bislang nur dann, wenn ich ich begrenzte Kartenausschnitte geladen hatte. Mit der kompletten Karte gab es bereits wiederholt “Hänger”. Adress-Suche wird es deshalb vorerst auf meiner Geräte-Karte nicht geben. In der PC-Version vielleicht. Aber dann als GEO-Punkt.

Weiter oben las ich von Einträgen in das data-Verzeichnis.
Wenn dafür keine relativen sondern absolute Beziehungen programmiert werden, bedeutet das dann, das man unter Einstellungen das Data-Verzeichnis nicht mehr frei wählen kann?
Das fänd ich ungeschickt. Da ich beim Testen verschiedener Renderdurchgänge die Möglichkeit, das Data-Verzeichnis zu wechseln, ausgiebig nutze.

Gruß
tippeltappel

Walter_Schlögl · 2010-01-05T07:49:49.000Z

Hallo tippeltappel,

ich muss mich korrigieren, ich hatte eine bessere ID für den Oregon gesucht, nicht für MapSource.
Beim Oregon ist der Autohändler auf 2f07, nicht auf 0x31…
Meine ID war natürlich nur ein Vorschlag, jeder muss selbst wissen, wo es ihm für sein Gerät am besten dazupasst.

Bei den geografischen Punkten (Manmade Places) suche ich recht gerne nach Leuchttürmen, Windmühlen, usw.
Die finde ich jedoch nicht mehr, wenn sie durch sämtliche Straßen zugemüllt werden.

Die Wander-Reit-Karte ist nicht für die Oregon-IDs erstellt, daher habe ich die meisten IDs umgeroutet.
Auf die Marine-IDs habe ich nur jene POIs gelegt, die ich auch wirklich suchen möchte.

Ich habe meine routingfähige Karte bisher innerhalb von Wien getestet, da funktioniert die Suche nach Straßen und die Navigation bisher einwandfrei.
Leider fehlen in Wien bei vielen Straßen noch die maxspeed Angaben, daher werde ich manchmal auf “Schleichwege” geführt.
Bei größeren Entfernungen (>20km) habe ich derzeit noch Probleme, die ich auf den Splitter zurückführe. Da muss ich noch ein wenig weiterforschen.

Die absoluten Pfadangaben waren ein Tipp von mir, keine Einschränkung des Composers.
Es funktioniert alles auch mit relativen Pfadangaben, man muss halt nur mehr aufpassen, welches das gerade aktive Verzeichnis ist.

Gruß
Walter

Nop · 2010-01-05T09:28:28.000Z

Walter Schlögl:

Ich habe meine routingfähige Karte bisher innerhalb von Wien getestet, da funktioniert die Suche nach Straßen und die Navigation bisher einwandfrei.
Leider fehlen in Wien bei vielen Straßen noch die maxspeed Angaben, daher werde ich manchmal auf “Schleichwege” geführt.
Bei größeren Entfernungen (>20km) habe ich derzeit noch Probleme, die ich auf den Splitter zurückführe. Da muss ich noch ein wenig weiterforschen.

Das dürfte dann der nächste Arbeitspunkt werden. Composer hat seinen eigenen Splitter, der einiges besser macht als der von mkgmap, aber halt noch nix von Routing weiß.

bye
Nop

tippeltappel · 2010-01-05T13:18:30.000Z

Walter Schlögl:

Hallo tippeltappel,

ich muss mich korrigieren, ich hatte eine bessere ID für den Oregon gesucht, nicht für MapSource.
Beim Oregon ist der Autohändler auf 2f07, nicht auf 0x31…
Meine ID war natürlich nur ein Vorschlag, jeder muss selbst wissen, wo es ihm für sein Gerät am besten dazupasst.

Bei den geografischen Punkten (Manmade Places) suche ich recht gerne nach Leuchttürmen, Windmühlen, usw.
Die finde ich jedoch nicht mehr, wenn sie durch sämtliche Straßen zugemüllt werden.

Die Wander-Reit-Karte ist nicht für die Oregon-IDs erstellt, daher habe ich die meisten IDs umgeroutet.
Auf die Marine-IDs habe ich nur jene POIs gelegt, die ich auch wirklich suchen möchte.

…

Gruß
Walter

Daß der Autohändler bei Dir mit einer anderen ID an der Suchfunktion hängt, hatte ich vermutet. Daher der Vorschlag, auszuprobieren, ob die anderen IDs auf Deinem Gerät funktionieren.

Daß Du Dir aus genanntem Grund die Suchliste für geografische Punkte nicht zumüllen möchtest, verstehe ich.
Mir geht es da nicht anders. Da es in dem Bereich Unterkategorien (Gebäude, Gewässer, Landeigenschaften) gibt, kann man sich aber überlegen, ob man eine Unterkategorie “opfern” möchte.

Adresssuche benötigt eigentlich eine eigene Kategorie. Denn ganz egal, wo Du sie hin packst: sie wird irgendjemanden stören.

Benutzt Du MapSource eigentlich gar nicht zum Anzeigen der Karten auf dem PC?

Bei der Suche nach geeigneten IDs prüfe ich immer zuerst, die Bezüge in MapSource. Da erkennt man vieles, was auf dem Gerät nicht sichtbar wird. IDs aus der 0x2f-Serie werden dort auch mit Bezug zu verschiedenen Auto-Services angezeigt. Und das gilt auch für das VistaHCX. Für Auto-Händler kann man in MapSource aber eben verschiedene IDs nutzen. Bei meinen Tests tauchte die Verknüpfung zur 0x31-Serie als Alternative zur 2f07-Serie auf. Ob die im Vista funktionieren, hab ich in meinem Test-Protokoll noch nicht vermerkt.

Aus eigenen Beobachtungen/Recherchen, aus den Berichten anderer User und aufgrund einer Liste im OSM-Wiki ist der Schluß zu ziehen, daß MapSource sozusagen das Sammelbecken der IDs ist. MapSource greift auf wesentlich mehr IDs in der Suchfunktion zu als die Geräte.
In den Geräten ist die Suchfunktion auf eine gerätespezivische Auswahl von Punkten begrenzt. Das heißt aber nicht, daß sie total umfunktioniert werden. Denn sie müssen ja mit der Suchfunktion von MapSource kompatibel sein. Übereinstimmungen und Unterschiede zwischen MapSource und VistaHCx hab ich schon zu einem großen Teil dokumentiert. Den Vergleich zwischen verschiedenenGeräten allerdings noch nicht. Daher mein ID-Vorschlag ausschließlich mit Hinweis auf MapSource.

Die Übereinstimmungen und Unterschiede muß man allerdings kennen, will man eine Karte programmieren, die eine für möglichst viele Geräte kompatible Suchfunktion aufweist. Wenn man sich an die Grundregel hält, alle IDs so zu programmieren, daß sie in MapSource in der richtigen Kategorie auftauchen, darf man vermutlich davon ausgehen, daß sie in den Geräten mit großer Wahrscheinlichkeit zumindest nicht in der falschen Kategorie angezeigt werden. Bleibt nur die Frage ob (!!!) sie angezeigt werden und wenn ja, wie die Unterkategorien eingeteilt sind. Da scheint es Unterschiede zu geben.

Wenn ich zu einer Kategorie zusätzliche ID-Nummern finde, die in Map-Source in der Suchfunktion auftauchen, vom Vista jedoch ignoriert werden, benutze ich die für Objekte, die zur Kategorie gehören, im Handgerät aber nicht in der Suchfunktion auftauchen sollen. Diese nicht suchbaren IDs lassen sich mit individuellen Grafiken verknüpfen, die diese Punkte dann auf der Karte von anderen Punkten der Kategorie unterscheiden. In MapSource läßt sich überprüfen, welche Icons Garmin in der Software für die IDs hinterlegt hat. Sie tauchen in der Suchliste “zuletzt gefunden” neben den Suchbegriffen (Namen der Objekte) auf.
Auch im GPS-Gerät werden in der Liste “kürzlich gefunden” die in der Garmin-Software hinterlegten Icons angezeigt. Die selbst definierten Icons werden ausschließlich auf der Karte angezeigt.
In Geräten, deren Software die im Gerät hinterlegten Icons auf die Karte setzt, überlagern die Garmin-Icons leider die selbst definierten Icons. Auch das ist ein Grund, warum es ratsam ist, nach Möglichkeit die IDs nur der Kategorie konform zu verwenden. Es gibt viele IDs, die von Garmin bislang nur wie Platzhalter programmiert wurden. Deren Icon, ein kleiner Punkt, stört bei der Überlagerung nicht. Vor allem, wenn die selbst definierten Icons relativ groß sind. (Meine sind 15x15px - fast das Maximum für das VistaHCx).

Nach detaillierter Überprüfung der ID-Programmierung des Composers hab ich aus oben beschriebenen Gründen Wanderwegmarkierungen aus der Kategorie Marine/Gefahrenpunkte heraus genommen. Den Bereich geografische Punkte hab ich ebenfalls neu geordnet. Aus dem von Dir genannten Grund: da soll nur auftauchen, was ich wirklich suchen möchte.

Durch solche Maßnahmen wird eine Karte zumindest teilweise sehr individuell auf ihren Nutzer zugeschnitten. Du hast schon recht. Da muß jeder selbst überlegen, wie er seine Karte haben möchte.

Da ich nicht testen kann, auf welche ID-Auswahl die Suchfunktion des Oregon reagiert, kann ich Dir lediglich berichten, was MapSource an Möglichkeiten bietet. Daher mein Vorschlag, die Nummern mal zu testen.

Gruß
tippeltappel

Walter_Schlögl · 2010-01-05T16:44:27.000Z

Hallo tippeltappel,

du hast dich ja ebenfalls recht intensiv mit dem Problem der IDs beschäftigt.
Ich habe ehrlich schon ne ziemliche Wut auf die Firmware Programmierer.
Bei der Fülle an IDs hätte man bei der Suchliste nicht derart knausrig sein müssen.

OSM bietet heute bereits wesentlich mehr PIOs an als jedes Navi unterscheiden kann.
Kurioserweise ist Garmin trotzdem noch 3x besser als alle anderen Geräte am Markt.
Trotzdem, mein Wunsch an eine bessere Firmware wäre, die POI-Listen jeweils bis xx2f durchsuchbar zu machen.

Ich verwende MapSource nur am Rande, wenn ich den POI am Gerät nicht suchen kann, nutzt mir die POI-Liste in MS auch nichts.

Bei Sport/Freizeit schwanke ich, ob ich verschiedene Symbole vergeben soll, oder alles weitere unter dem letzten durchsuchbaren Punkt (2d0b) dafür dann mit einheitlichem Symbol ablegen soll.

Bei Attraktionen habe ich die Tourist-Info einsortiert, die Liste wird aber auch rasch eng.

Mit Autoservice komme ich derzeit aus, sogar der Automobilclub ist auf 2f0d gelegt, obwohl es in OSM gar kein TAG dafür gibt (ich selektiere halt auf Name und Operator).

Unter Gemeinde habe ich noch die Botschaften untergebracht, mit Government Office konnte ich ohnehin nichts anfangen.
Dafür habe ich Bank und ATM getrennt, zugunsten verschiedener Symbole.

1d03 und 1d06 sind beides im Original “Tides”, hier gibt es bei mir Arzt und Zahnarzt (hoffentlich nie benötigt).
Die weiteren “Marine Serives” wie z.B. Ramps, Pump-Out usw habe ich am Oregon noch nicht gefunden.
Ich würde sie mit Burgen und Schlössern belegen, die kann der Composer sehr schön unterscheiden (z.B. jeweils nach Ruine=ja/nein).

Bei den Gewässerarten habe ich Wasserfall und Quelle, bei der Landnutzung Berg und Höhle. Da will ich nicht zu viel unterbringen, da es nicht weiter unterteilt wird.

Hast du schon mal versucht, bei der Karteneinstellung die Textgröße für Kartenpunkte auf “kein” zu setzen.
Beim Oregon werden die POI-Symbole dann nicht mehr überschrieben.

Nachdem ich meine Karte nur für ein Gerät erstelle, muss ich auf das Verhalten anderer Geräte keine Rücksicht nehmen.

Gruß
Walter

Walter_Schlögl · 2010-01-05T16:47:35.000Z

Hallo Nop,

der Splitter müsste die Linien so trennen, dass mkgmap die Trennstellen wieder zusammenkleben kann.
Ich hoffe, du kannst das benötigte Verhalten aus dem frei verfügbaren Source-Code herauslesen, sonst wird es kompliziert, das nachzubauen.

Walter

tippeltappel · 2010-01-05T21:43:59.000Z

Hallo Walter

Ich denke, die Programmierer sind aus gutem Grund knauserig. Wenn man die Navi-Foren zum Thema Suchfunktion-OSM-Karten-Garmin absucht, stößt man auf Berichte, daß die Suchfunktion bei manchen Karten zu sehr merkwürdigen Ergebnissen führt und die Geräte sich bei manchen Abfragen aufhängen. Meine Erklärung:

Die merkwürdigen Ergebnisse entstehen natürlich, wenn der Kartenersteller die IDs nicht gründlich genug recherchierte oder wider besseren Wissens für artfremde Kategorien verwendet.
(ohne detaillierte fachliche Kenntnis der programminternen Vorgänge - also rein hypothetisch):
Die große Fülle der in OSM abrufbaren POIs übersteigt vermutlich die Rechenleistung der in den GPS-Geräten steckenden Minicomputer. Grund für die Annahme: Ein und dieselbe Suche führte auf meinem VistaHCX bei Verwendung der kompletten Deutschlandkarte (openmtbmap oder Wanderreitkarte) zum Absturz, bei Verwendung eines begrenzten Kartenausschnittes jedoch nicht. Daraus ziehe ich den Schluß, daß der Detailreichtum der OSM-Karte zu einer viel zu großen, für das Gerät nicht mehr zu bewältigenden Suchergebnisliste führt, die dann durch Verkleinerung der Karte auf eine bearbeitbare Größe geschrumpft wurde. Auch andere Gründe sind denkbar. Doch die sollen die beschreiben, die sich mit Programmieren auskennen.

Wut auf die Firmware-Progammierer finde ich nicht so ganz berechtigt. Schließlich arbeiten die für Garmin und nicht für OSM.

Beim Programmieren der eigenen Karte auf das Verhalten anderer Geräte Rücksicht nehmen, braucht man natürlich nicht, wenn man an einer ganz persönlichen Karte bastelt. Bei einer öffentlich geführten Diskussion wie dieser macht es aber Sinn, zu prüfen, wie kompatibel die niedergeschriebenen Vorschläge sind. Wenn der OSM-Composer nun so eingerichtet werden soll, daß er routingfähige Karten erzeugt, und eine ID für die Adressuche eingerichtet werden soll, muß gut überlegt werden, welche Kategorie damit belegt werden soll. Sie sollte schon intuitiv im Suchsystem der GPS-Geräte und MapSource abrufbar sein und nicht die Abfrage eines völlig unlogischen Begriffs erfordern. Die einzig logische Kategorie ist Geografische Punkte. Im Vista stehen als Unterkategorien Gebäude, Gewässerart und Landeigenschaften zur Verfügung. Tja, was nehmen? Gebäude? - Hmm. Nicht wirklich. Die Unterkategorie sollte für das Auffinden besonderer Gebäude reserviert bleiben. Kirchen, Schulen, Windmühlen, etc. — Gewässer? - Na, das braucht man wohl nicht diskutieren, daß das unsinnig ist. — Landeigenschaften? - Hmm. Was taucht bei mir darin auf? Bäume, die als POI eingetragen wurden (nicht sehr sinnvoll, wenn es namenlose Alleebäume oder ähnlich uninteressante Objekte sind - Da muß ich versuchen eine Renderregel einzubauen, die dafür sorgt, daß nur Bäume mit Eigennamen in der Liste auftauchen. Für die namenlosen brauch ich dann eine ID, die das Objekt nur auf der Karte zeigt), Gipfel (sehr passend) Höhlen (auch passend)… Wenn nun das Straßenverzeichnis hier eingeblendet wird, wird der Zugriff auf den nächsten Berg und die nächste Höhle natürlich erschwert. Aber wie wichtig ist es, Berge, Höhlen etc. ohne Eingabe des Namens oder der Bezeichnung in der Liste zu finden? Für die Adress-Suche scheint mir die Unterkategorie Landeigenschaften die sinnvollste zu sein. Wenn z.B. die Höhlen mit einem Eigennamen getagt sind, dann kann man diese auch mit der Namenssuche “höhle” finden. Namenlose Höhlen und Höhlen, in deren Name das Wort Höhle nicht vorkommt, zeigt die Suchergebnisliste dann allerdings nicht an. Aber vielleicht kann man eine Renderregel erzeugen, die dafür sorgt, daß die Bezeichnung Höhle als Name gerendert wird. Dann wären alle Höhlen über die Suche nach Name auffindbar. Hab jetzt leider keine Zeit, das auszutüfteln.

Gruß
tippeltappel

EDIT

“Kartenpunkte auf kein”
Ich las schon von der Methode. Ist meines Erachtens eine Krücke. Greift das Problem nicht bei der Wurzel. Mich braucht die Behelfslösung zZt nicht interessieren, da mein Gerät alles wie gewünscht anzeigt.

Gruß
tippeltappel

Walter_Schlögl · 2010-01-06T08:02:44.000Z

Hallo tippeltappel,

ich finde die Default-Einstellung für die Straßen schon ok, und seit V 8.0 kann ja jeder beim Composer seine mkgmap Parameter selbst modifizieren.
Eigentlich hoffe ich ja weiterhin, dass mkgmap bald routingfähige Karten erzeugen kann, wo auch die richtige Adress-Suche funktioniert.

Garmin wäre gut beraten, die OSM Tauglichkeit seiner Geräte weiter auszubauen.
Jeder in meinem Bekanntenkreis dem ich diese Möglichkeiten von OSM bisher gezeigt habe möchte als nächstes Navi nur mehr ein Garmin-Gerät kaufen.
Leider macht Garmin selbst viel zu wenig Werbung für die eigenen Geräte. Auch das Lifetime-Upgrade der Garmin-Karten ist kaum bekannt.

Die Suche über viele POIs stürzt nur ab, wenn in einer Liste zu viele Treffer sind, nicht wenn es mehr Kategorien gibt.
So ein Fehler müsste sich recht einfach beheben lassen, auch bei langsamem Prozessor.

Walter

aighes · 2010-01-06T08:55:20.000Z

Das Problem ist, dass Garmin ein großer Teil ihres Gewinnes abhanden kommt, wenn sie auf ihren Karten sitzen bleiben. Und das wird passieren, wenn sie ihr Format öffnen und damit OSM-Karten besser (da aktueller) und günstiger sind.

Aber ich bin mir sicher, dass es GPS-Geräte geben wird, die OSM-fähig sind. Alles eine Frage der Zeit und der Bekanntheit und der Abdeckung von OSM.

chris66 · 2010-01-06T10:19:36.000Z

Walter Schlögl:

Garmin wäre gut beraten, die OSM Tauglichkeit seiner Geräte weiter auszubauen.
Jeder in meinem Bekanntenkreis dem ich diese Möglichkeiten von OSM bisher gezeigt habe möchte als nächstes Navi nur mehr ein Garmin-Gerät kaufen.

Auch ich bin seinerzeit wegen der besseren OSM bespielbarkeit von Magellan auf Garmin umgestiegen.
Aber wie gesagt, die machen Ihr Geld mit den Karten, deshalb werden die OSM vermutlich nie
offiziell unterstützen.

Aber auch google macht Garmin mächtig Konkurrenz:

http://www.nodch.de/google-maps-navigation/1236

Outdoor taugliche Androids mit langer Akkulaufzeit sind mir aber nicht bekannt…

Chris

Nop · 2010-01-06T12:17:11.000Z

Walter Schlögl:

der Splitter müsste die Linien so trennen, dass mkgmap die Trennstellen wieder zusammenkleben kann.
Ich hoffe, du kannst das benötigte Verhalten aus dem frei verfügbaren Source-Code herauslesen, sonst wird es kompliziert, das nachzubauen.

Genau das kann ich nicht. Bzw. ich hab mir den Source von mkgmap schon angeschaut, aber das ist nicht in vernünftiger Zeit herauszulesen. Da bräuchte man die Hilfe von jemand, der sich dort schon ein wenig auskennt und bereit ist zu fachsimpeln.

bye
Nop

Walter_Schlögl · 2010-01-06T13:05:11.000Z

Hallo Nop,

falls es gar keine bessere Lösung gibt, wäre eine Alternative immer noch, bei der Erstellung routingfähiger Karten auf den externen Splitter umzuschalten.
Dabei würde man natürlich die Vorteile des Composer Splitters komplett verlieren.
Ich nehme an, einer der Vorteile des Composers ist die Möglichkeit, per Datenbank beliebig große Gebiete zu splitten, was ja sonst nur mit einer Menge RAM möglich ist.

Die schönere Lösung wäre natürlich, wenn ein Insider sein Wissen weitergeben würde.
Bei einem Open-Source Projekt wäre das ja auch gar nicht so abwegig.

Walter

Nop · 2010-01-06T15:02:42.000Z

Walter Schlögl:

falls es gar keine bessere Lösung gibt, wäre eine Alternative immer noch, bei der Erstellung routingfähiger Karten auf den externen Splitter umzuschalten.
Dabei würde man natürlich die Vorteile des Composer Splitters komplett verlieren.
Ich nehme an, einer der Vorteile des Composers ist die Möglichkeit, per Datenbank beliebig große Gebiete zu splitten, was ja sonst nur mit einer Menge RAM möglich ist.

Das werde ich garantiert nicht machen.

Der Splitter von Composer kann Höhenlinien mit einbeziehen, hat eine bessere Heuristik die Gebiete zu treffen, keine Einschränkung wieviele Gebiete eine Relation berühren darf und verarbeitet Multipolygone besser. Wenn er durch den Splitter von mkgmap zu ersetzen wäre, hätte ich ihn gar nicht erst geschrieben.

Walter Schlögl:

Die schönere Lösung wäre natürlich, wenn ein Insider sein Wissen weitergeben würde.
Bei einem Open-Source Projekt wäre das ja auch gar nicht so abwegig.

Sollte man meinen, ja. Magst Du Dich auf der mkgmap-Liste mal umhören ob es einer erklärt?

bye
Nop

Walter_Schlögl · 2010-01-06T15:19:00.000Z

Hallo Nop,

du könntest anbieten, deine Erfahrung für den mkgmap Splitter zur Verfügung zu stellen und im Gegenzug Infos über die Routing-Funktionen zu erhalten.
Ich denke, das es sich gar nicht um eine so umfangreiche Änderung handeln kann. Aber für mich ist das alles noch sehr fremd.
Bei großem Zoom-Maßstab (ca. 20 km) sind mir bei der Composer-Karte feine Haar-Risse aufgefallen.
Könnte es sein, dass beim mkgmap Splitter eine winzige Überlappung (vielleicht 1 Pixel oder eine äquivalente OSM-Einheit) eingerechnet wird?

Walter