Hi!
Mir scheint in dieser Diskussion werden zwei Aspekte vermischt, die durchaus
separat betrachtet werden können.
Das sehe ich auch so.
1. Zentrale, automatische Produktion von Garminkarten, aktuell halten von
Garminkarten
2. Einfacheres Auffinden, einfacherer Zugang für den Nutzer
Für 2. würde ich mir eher einen vereinfachten Webzugang vorstellen
- eine Schaufensterseite wie auf openstreetmap.de für die Online Karten
- oder eine sukzessive Suche ähnlich wie bei den meisten Treiberdownloads:
Auswahl des Themas/der Themen, Auswahl einer Region auf einer Karte wie z.B.
hier http://www.dickemauern.de/ausland.htm und dann Anzeige aller in Frage
kommenden Karten mit Link, letzer Aktualisierung usw.
Dafür müßte man nur eine Datenbank von Karten analog zur jetzigen Wikiliste
unterhalten und die Links auf Gültigkeit prüfen. Ggf. noch die Karten auf
einen Mirror kopieren, um die Links zuverlässiger zu halten.
Umgekehrt argumentiert: Wenn man sich nur auf 1. und die Karten die man
selbst zentralisiert baut beschränkt, tut man dem Nutzer, für den vielleicht
eine der anderen Karten im Netz die passendste ist, keinen Gefallen. Im
Gegenteil, es würde eher verschleiert, daß es da noch mehr gibt.
Der zweite Ansatz erscheint mir der technisch deutlich einfachere und
weniger aufwendig umzusetzende. Als ich vor einigen Jahren eingestiegen
bin, habe ich auch erst mal lange rumgesucht, bis ich gefunden habe, wo
man eine OSM-Garmin Karten runterladen kann. Mit einer einfachen
Verlinkung sollte man die allermeisten Nutzer zufrieden stellen.
Der zweite Ansatz ist interessant, allerdings schätze ich die
technischen Probleme als relativ hoch ein. Wie bereits erwähnt, werden
von vielen Kartenerstellern die Typ-Files an den Style (die Regeln, mit
welchen Objekten die Karten gefüllt werden) angepasst. Meiner Meinung
nach, wird diese Funktionalität bereits vom MapComposer (bzw.
OsmComposer) abgedeckt. Leider steht die Software nicht als Opensource
zur Verfügung und rechnet die Karte auf dem PC des Endanwenders, wodurch
sie für die hier gewünschten Zwecke nicht in Frage kommt.
Optimierungsbedarf von mkgmap:
* Ich bezweifle, dass das Vorfiltern von Tags über die OverpassAPI einen
Vorteil bringt. mkgmap versucht, möglichst nur diejenigen Daten zu
laden, die notwendig sind. Natürlich sind auch hier noch kleinere
Optimierungsmöglichkeiten vorhanden.
* Eine wesentliche Optimierung (gerade was den Hauptspeicherbedarf
angeht) könnte sein, wenn man beim PBF-Format am Anfang des Files einen
Pointer auf den Anfang der Relationen und auf den Anfang der Ways setzen
könnte. Dann könnte mkgmap das File umgekehrt einlesen, also zuerst die
Relationen, dann die Ways und zuletzt die Nodes. Liest man die Datei in
der richtigen Reihenfolge, hat man das Problem, das man bei einem Node
zwar bestimmte Tags nicht mit einliest, weil sie nicht benötigt werden.
Man muß aber trotzdem alle Nodes einlesen, da auch ein Nodes ohne Tags
zu einem späteren Zeitpunkt von einem Way oder einer Relation verwendet
werden könnte. In der umgekehrten Reihenfolge, weiß man beim Einlesen
der Nodes bereits, ob ein Node verwendet wird oder nicht.
Falls es Änderungsbedarf an mkgmap für die Umsetzung der angerissenen
Funktionalitäten gibt, stehe ich gerne zur Verfügung.
WanMil
bye
Nop
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
