[Talk-de] AIO fehlt völlig

[Felix Hartmann]

On 04.01.2011 23:17, Christoph Wagner wrote:
> Am 04.01.2011 22:03, schrieb Sven Geggus:
>> Christoph Wagner<freemaps.osm at googlemail.com>  wrote:
>>
>>> Ich bin noch nicht so ganz sicher woran das liegt. Da ist wohl was gehörig
>>> schief gelaufen. Zunächst muss ich aber mal mit den Leuten reden, die da
>>> was gemacht haben und rausfinden, was genau sie da gemacht haben.
>> Du solltest auch das Makefile ins git reinstopfen nicht nur die Styles.
> Ist schon seit Ewigkeiten drin.
>
>
> Ich hab jetzt mal ne Weile mit flacus telefoniert und wir haben jetzt ganz gute Ideen, wie die ganze AiO-Geschichte in Zukunft aussehen könnte.
>
> Ich werd das vielleicht mal hier kurz zusammenfassend schildern:
>
> 1. der Server splittet die ganzen Daten mit festen Tilegrenzen, welche gelegentlich korrigiert werden, wenn Kacheln zu groß werden.
>
> 2. der Server rechnet die einzelnen Layer mit mkgmap und den kacheln einmal durch.
>
> 3. die fertigen Kacheln jedes Layers werden einzelnen gezippt und zum download angeboten
>
> 4. der Endnutzer kann selbst bestimmen welche layer er in welchem bereich runterladen will und bappt das dann auf seinem eigenen Rechner zusammen und kriegt ne Datei raus, die er aufs Gerät schieben kann
>
>
> Damit die Endnutzer Schritt 4 möglichst komfortabel hinbekommen, will ich ne Java-Applikation schreiben, die Kacheln vom Server abrufen und cachen kann und dann mkgmap aufruft und die fertige gmapsupp rausbekommt.
>
> So der Plan.
>
> Das ganze hätte gegenüber der jetzigen Variante unglaublich viele Vorteile:
>
> 1. deutlich weniger Serverlast ->  damit wäre es vielleicht möglich die ganze Welt anzubieten
>
> 2. viel weniger Bandbreite notwendig, da einzelne Kacheln gezielt geladen werden und bereits geladene Kacheln wieder verwendet werden können
>
> 3. Die User suchen selber aus, was sie haben wollen
>
> 4. deutlich flexibler bei steigender OSM-Datendichte und begrenztem Kartenspeicher im Gerät
Zu Schritt 4. Ich bin mir nicht sicher ob die Last dadurch wirklich 
sinken würde. Kann gut sein, dass die User dann im Endeffekt größere 
Karten runterladen.
zu 4.2 Dann muss das Programm Updates erkennen können, bzw zumindest den 
letzen Switch bei den Kachelgrenzen.

-- Schritt 4 generell. Das setzt voraus dass der Enduser eine 
funktionierende Java Umgebung hat und mkgmap integriert wird. Ausserdem 
können dann nur User die ein x64 System mit genügend freiem RAM haben, 
sich etwa für eine DACH Karte eine Adresssuche generieren lassen 
(prinzipiell benötigt zum bauen der Adresssuche ist etwa Kachelgröße mal 
1.2). Ich hoffe mal dass durch die Sources von cgpsmapper hier die 
Fehler bald gefunden werden, warum die mkgmap Adresssuche derzeit noch 
nicht 100% korrekt funktioniert auf den GPS (in Mapsource funktioniert 
sie ja schon). Das ein Programm den freien RAM ermittelt ist aber 
problematisch. Sprich wahrscheinlich läuft so eine Lösung dann darauf 
heraus, dass man gar keine Adresssuche hat.