[Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

[WanMil]

> 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
>
>