Neue Version Atlas Creator

Zitat

Original von Wunibald

Hallo Silver,

klasse Sache !!!

Aber: ich habe die URL von Womisa in die settings eingetragen, bei mit erscheint aber immer nur der 999-style, egal welche Zahl (statt 999) ich vorgebe - gibts da noch einen Trick ?
Gruß
W.

Alles anzeigen

Die URL von womisa ist nur zum nachschauen der Style

in den TBAC must du analog dieser URL eintagen:

<url>http://a.tile.cloudmade.com/BC9A493B4101...759707/999/256/{$z}/{$x}/{$y}.png</url>

und da bekomme ich im TBAC je nach Eingetragenen Style (999 ersetzt durch einen anderen Style) auch diesen als Ergebnis!

Der Cache must du natürlich vorher auch leer machen sonst kommen die Karten ja aus dem Cache - am besten das Tile Store im TBAC abschalten - da wandern nur noch die Karten in den Cache die der TBAC anzeigt - ist ja meist eine größere Zoomstufe als diese in denen man die Karten erstellt!!!!

Gruß
Silver

Zitat

Original von ThomasSc
Ist es möglich die historischen Karten von www.mapy.cz einzubauen?
Die Kartengrößen sind 256px x 256px.
http://www.mapy.cz/#mm=RA@x=129340416@y=133643776@z=11
Viele Grüße
Thomas

Das URL-Schema der Tiles ist aber anders kodiert als OSM oder Google.
Hexadezimal:

http://m4.mapserver.mapy.cz/army2/11_7ba0000_7fc0000

http://m1.mapserver.mapy.cz/relief-l/11_7b20000_7ee0000

Wenn man weiss wie die zustandekommen sollte es einfach sein in Java. Beispielcode ist hier:
\trekbuddyatlasc\trunk\TAC\src\tac\mapsources\impl
Auf Anhieb sehe ich da kein ähnlich kodiertes Schema.

Für mich wären die FR-Karten interessant, das ist nicht hex, sondern alphanumerisch:
http://visu-2d.geoportail.fr/geoweb/maps8u6Q23nyuMA.jpg

Keine Ahnung, wie sich das berechnet. Vielleicht steckt aber nur eine einfache Formel dahinter, die man im TAC-Java einbauen könnte.

Zitat

Original von frank334

Das URL-Schema der Tiles ist aber anders kodiert als OSM oder Google.
Hexadezimal:

http://m4.mapserver.mapy.cz/army2/11_7ba0000_7fc0000

http://m1.mapserver.mapy.cz/relief-l/11_7b20000_7ee0000

Wenn man weiss wie die zustandekommen sollte es einfach sein in Java. Beispielcode ist hier:
\trekbuddyatlasc\trunk\TAC\src\tac\mapsources\impl
Auf Anhieb sehe ich da kein ähnlich kodiertes Schema.

Keine Ahnung, wie sich das berechnet. Vielleicht steckt aber nur eine einfache Formel dahinter, die man im TAC-Java einbauen könnte.

Alles anzeigen

Sehr Schade.

Ich dachte, es wäre einfacher, weil die "Cykloatlas (Czech Republic only)" so aussieht, als wäre sie aus der www.mapy.cz

Zitat

Original von ThomasSc
http://m4.mapserver.mapy.cz/army2/11_7ba0000_7fc0000
Ich dachte, es wäre einfacher, weil die "Cykloatlas (Czech Republic only)" so aussieht, als wäre sie aus der www.mapy.cz

Mag sein, dass die Kartenquelle die gleiche ist. Aber das Serverformat vom Cykloatlas ist unterschiedlich:

GET /tiles/gm/shc/14c/8844/5549.png

Schaut eher nach dem OSM-Format aus, mit dem der Atlas Creator anscheinend per XML-Config gut zurechtkommt.

Egal, die Grundsteine im Sourcecode sind gelegt. Es sind ja schon in kurzer Zeit beachtlich viele und gute Karten verfügbar. Durch den offenen Code kann man dem Projekt gute Wachstumschancen prognostizieren. Die Klassenstruktur scheint gut durchdacht zu sein, wartungsfreundlich und offen für Erweiterungen.

p.s.: wer wissen möchte, welche URL-Requests vom Browser vorgenommen werden sollte mal dieses probieren:
http://livehttpheaders.mozdev.org/
alternativ oder wenn es nicht der Browser ist: "Wireshark" Netzwerkanalysator

Hallo mobrob. Auch von mir ein Dankeschön für dieses Tool und die Glopus Anpassung.

Zitat

Original von ReRo
Für mich wären die FR-Karten interessant, das ist nicht hex, sondern alphanumerisch:
http://visu-2d.geoportail.fr/geoweb/maps8u6Q23nyuMA.jpg
[*]Die Dateinamen der Tiles folgen leider nicht einem einfachen Schema, sondern sind regelrecht "verschlüsselt". Man könnte den Algorithmus natürlich aus dem JavaScript-Code herausbekommen (http://www.geoportail.fr/js/compress/2D-second-compress.js), aber dafür reichen meine JavaScript-Kenntnisse nicht aus (zumal der Code auch nicht gerade lesbar ist).

Ja, schaut aus als ob ein "Obfuscator" am Werk war. Hab's mal durch einen Javascript reformat/tidy laufen lassen, damit wenigstens das Textformat übersichtlicher wird. Es sind schon recht eindeutige Ops zu erkennen, den X/Y Offset, die Rechenoperationen und Projektionseinstellungen für die diversen "territoires d'outre-mer" Nur viele Variablen haben unverständliche Bezeichner, was die Lesbarkeit stark einschränkt.

Zitat

[*]Selbst wenn man die Tile-Namen herausbekäme, könnte man nach derzeitigem Stand das leider nicht in den TAC integrieren, da die Zoom-Stufen inkompatibel sind. Herausfinden kann man das für eine
[...]
und prüfen, ob die Straßen an den jeweiligen Kanten des Bildes zur Deckung zu bringen sind. Das ist bei Geoportail leider nicht der Fall.

Wird also wohl erstmal nix mit den Geoportail-Karten.
René

In Glopus ist das recht elegant gelöst, wo beliebige Zoom-Stufen möglich sind. Eigentlich sollte das auch in TAC möglich sein, zumindest ein Äquivalent zu definieren und die entsprechende Skalierung dazu anzugeben. Falls nicht, ich kenne den Code nicht, wäre das eine gravierende Einschränkung die auch andere Karten betreffen würde. Man darf nicht die Google-Zoomstufen als gottgegeben nehmen. Die sind erstmal rein willkürlich.

Ich denke machbar ist das alles. Wenn man Zeit hat ... Bei mir als Sommerurlauber ist momentan kein Eigenbedarf da Aber Frankreich wäre noch ein Punkt wo Glopus ein Defizit an Kartenmaterial hat. Deutschland ist mit den Topokarten auf CD/DVD und der Generalkarte bereits gut versorgt. Dafür zahlt man gerne, für eine solche Qualität. Ist ja auch praktischer, gleich das ganze Land auf SD-Karte zu haben statt jedesmal nur Teilkarten herunterzuladen. Google finde ich eigentlich weniger brauchbar. Die Google-Straßenkarte bietet keine Landschaftsdetails, da kann ich gleich das Naviprogramm mit kompletter Westeuropa-Karte nehmen, OSM ist weit entfernt von vollständig, und Google-Satfoto ist ebenfalls nicht so praktisch zur Outdoornavigation wie eine echte Topokarte.

Zitat

Original von ReRo
Also, um TAC so flexibel zu machen, wie man es sich wünschen würde, müsste man wohl die Anwendung fast komplett neu schreiben. Ich habe mir ja den Quellcode schon etwas genauer angeschaut und kann das leider bestätigen. Allerdings muss man auch sagen, dass es ja immer mehr Karten im Netz gibt, die nach dem System von Google (bzw. ja auch OpenStreetMap) aufgebaut sind und TAC hat ja auch schon eine ganze Mengen an Kartenquellen integriert. Leider scheint für Frankreich das geoportail der einzige Anbieter brauchbarer Karten zu sein und dort achtet man wohl sehr darauf, dass man die Karten eben nicht so ohne Weiteres runterladen kann. Leider kann ich kein Französisch, um mal zu googlen, ob es nicht jemanden in Frankreich gibt, der ein anderes Tool für geoportail gebaut hat - würde mich doch wundern, wenn es da nichts gäbe. Eine Kalibrierung in einem anderen Format könnte man dann sicherlich irgendwie konvertieren.
Viele Grüße,
René

"Anwendung fast komplett neu schreiben" ist Unsinn. Das wäre vielleicht bei Spaghetticode der Fall. TAC ist aber gut strukturiert und parametrisiert, so dass eine Tilegrößen-Flexibilität relativ einfach wäre. Sicher, die Zahlenkonstanten müssten überall durch Parameter ersetzt werden, aber das ist ja wohl weder schwierig noch aufwendig. Ich frag mich sowieso, warum nicht gleich vernünftige Bezeichner statt der Zahlen gewählt wurden. Ich mache das grundsätzlich, schon alleine weil es weniger Arbeit macht und um den Code lesbarer zu gestalten. Es schreibt ja auch keiner 3.1415926535897932385.... in Formeln herein, sondern definiert sein Pi einmal als constant (oder doch? :). Ob es dann konstant ist, oder als Variable in einer Kartenstruktur abgelegt wird spielt keine große Rolle bezüglich des Aufwandes.

Bezüglich inkompatibler Zoom-Levels gilt Ähnliches. Bei TAC besteht nicht die Schwierigkeit wie in Glopus, verschiedene Auflösungen bildlich nebeneinander setzen zu müssen. Das vereinfacht die Sache erheblich. Wenn bei "Map Source" auf eine andere Karte geschaltet wird müssen dann eben noch die Zoom-Levels bzw. Umrechnungsfaktoren angepasst werden. Ob der Maßstab nach dem Umschalten ein anderer ist, würde mich nicht allzu sehr stören. Etwas angleichen kann man die Zoomlevel immer noch.

Natürlich ist alles ein gewisser Programmieraufwand, den man nicht unbedingt vom Erstautor erwarten muss. Er hat schon eine gute Leistung vollbracht. Jetzt sind auch Helfer gefragt. Meistens ist es ja Eigenbedarf, der dazu motiviert, an freien Tools mitzuarbeiten. Zumindest würde ich die Flexibilität ganz oben auf einer Todo-Liste für zukünftige Weiterentwicklungen setzen. Es wäre wenig sinnvoll, sich unnötigerweise in der Kartenvielfalt zu beschränken. Die Frankreich-Karte ist nur ein Beispiel. Die meisten Karten sind nicht kompatibel zum Google/OSM-Schema. Bsp. die vielen Stadtpläne, die wesentlich mehr Inhalt und touristische Hinweise liefern als Deutschlandkarten. Oder viele ausländische Karten. Zumindest wird die wichtigste Outdoor-Karte in Deutschland, die amtliche topographische Karte, von TAC unterstützt. In Deutschland (und AT/CH/CZ) kann man schon mal sehr zufrieden sein.

Abgesehen von der Tilegröße/Zoomstufung: Ich denke die größte Schwierigkeit bei anderen Karten wird das URL-Kodierschema sein. Da sind die wildesten Standards bzw. Non-Standards denkbar. Dafür ist gerade so schön, dass der Quellcode freigegeben wurde und der Autor sich nicht selbst um alle Karten kümmern muss. Wichtig ist nur, das die Basisapplikation offen für Erweiterungen ist und möglichst wenig die Flexibilität einschränkt.
Bedarf wird sicherlich da sein. Gerade im Ausland ist man nicht gut mit Navikarten versorgt. Mein Navi hat "nur" Westeuropa drauf. In USA bin ich erstmal aufgeschmissen mit dem deutschen Naviprogramm. Oder auch Südosteuropa, Kroatien etc. wäre sehr interessant. Gut, jeder hat so sein persönliches Reiseprofil.