Hallo.
Ich habe es bereits vor einiger Zeit schon mal angeregt und auch im GeoClub nochmal danach gefragt: Es wäre doch super, wenn man es irgendwie hinkriegen könnte, die super Funktionen von Glopus und die Funktionen vom Cachewolf irgendwie miteinander zu vereinen. Im GeoClub ist dabei diese Diskussion herausgekommen:
http://www.geoclub.de/viewtopic.php?f=40&t=23747&p=374219
Ich hoffe, dass es am Ende doch noch was wird 
Ob das was wird ?
Da wird auf eingefahrenen Schienen diskutiert!
Da pfeffer trotz kontakt mit Peter genau als Anforderung für ein neues Kartenformat definiert was GMF schon ist ?
und die Frage in den Raum stellt:
was hat Glopus, was CacheWolf nicht hat?
Bis auf die Geocacheanbindung könnte man auch die Frage rumdrehen und noch mit dem Anhang "kann besser" versehen!
Von CacheWolfs seite sehe ich da wenig motivation diesbezüglich!
Es wird doch wenn man zwischen den Zeilen ließt nur nach Gründen dagegen gesucht.
Ich denke das Peter bezüglich der Schnittstelle zu den Cachewolf-Daten mehr intresse hat- soweit es ntürlich seine Zeit und Resurcen zulassen.
Ich werde bis dahin mit meiner CacheScanner und MortScript Lösung und dannach Händisch die Geochaches verwalten weitermachen. Und wenn ich ehrlich bin, bin ich damit recht zufrieden da ich doch nicht zig Caches an einem Tag erlege.
Gruß
Silver
Es stimmt, dass ich letztes Jahr wegen des Glopus Kartenformates angeschrieben wurde. Ich habe den aktuellen GMF Aufbau beschrieben und angekündigt, dass eine Erweiterung bzgl. Kartenprojektion nötig wäre und ich gerne kooperiere. Das wurde positiv zur Kenntnis genommen und mir wurde versprochen das ich "in den nächsten Tagen" einen Vorschlag bekomme. Trotz Nachfrage habe ich keine weitere Mail erhalten, leider.
Ist das Warten keine Zeitverschwendung? Wenn du die Projektionswerte drin haben willst, mache es doch einfach. Es würde doch genügen, eine Integerzahl als EPSG-Projektionscode für jede Kachel dem GMF-Format hinzuzufügen. Oder alternativ einen Code für das GMF als Ganzes.
Im PROJ Sourceverzeichnis /nad ist eine EPSG-Tabelle mit den jew. Transformationsparametern. Es reicht ja auch, die Unterstützung auf die gebräuchlichen Codes zu beschränken. Wenn man alles frei parametrisierbar macht, wird es natürlich sehr aufwendig. Aber ich denke, die Notwendigkeit besteht bei den üblichen Karten nicht. EPSG hat den Vorteil, dass viele Libraries wie PROJ und GDAL oder GIS-Programme das verstehen.
Wenn Cachewolf sich da nicht anschliessen will, who cares?
p.s.
ein Universalformat wäre natürlich GeoTIFF. Das verstehen viele Programme, der Projektionscode/datum steht drin, es gibt eine kachelorientierte Unterstruktur (tiles-modus) zum schnellen Auslesen, verschiedene Kompressionsalgorithmen (jpeg/zip/fax-RLE-basiert je nach Erfordernis). Ob es viel Aufwand zur Umsetzung macht und ob die Performance mit GMF mithalten kann? Zumindest sollte es viel Public-Domain Beispielcode geben, an den man sich orientieren kann.
Ich habe auch schon darüber nachgedacht, die Projektion basierend auf EPSG zu kodieren. Das wäre schön einfach. Aber reicht das wirklich? Wenn ich bei Wiki danach suche, sind nur die Gauss-Krüger Zonen von Deutschland gelistet. Ich weiß leider nicht, von welchen Sourcen Du schreibst. GeoTIFF wäre sicher auch für Glopus mit überschaubaren Aufwand nutzbar. Es ist mehr die Zeit sich da einzuarbeiten.
Auf Cachewolf warten, werde ich aber sicherlich nicht. Zugegeben hätte ich letztes Jahr wohl gleich die Projektion noch irgendwie in gsf reindefiniert, wenn die Anfrage nicht gekommen wäre. Jetzt haben aber erst mal andere Baustellen Priorität.
Da nicht jeder karibische Inselstaat sein eigenes Kartendatum hat, wird die EPSG-Tabelle dort sicherlich die meisten Anwendungsfälle abdecken. Ausserdem kann man immer noch neue benutzerdefinierte Codes mit anderen Parametern hinzufügen.
Dann müsste man entweder die EPSG-Tabelle für jeden Code auswerten und Projektionsparameter auslesen, so wie PROJ, sehr flexibel. Oder man beschränkt sich auf einige verbreitete Karten über eine interne Tabelle.
Naja, weiss nicht ob das die Nonplusultra-Lösung ist, aber zumindest vereinfacht sich so die Projektionskennung auf eine einzige Integerzahl.
