Neue experimentelle RouteConverter-Version mit mapsforge-Unterstützung

[routeconverter]

PS: Was ist mit "Gibt es Programme, die das lesen können?" gemeint?

Ich hatte angenommen, daß Du die XML-Datei für Programme bereitstellst, die sie herunterladen, um zu wissen, ob es neue Freizeitkarten liegen und wo sie herunterzuladen sind. Für Menschen hättest Du wohl eher eine HTML-Seite gebaut, oder?

Bezüglich der Test der Snapshot-Version 398 komme ich nicht so recht voran. Das Problem: Ich weiss nicht, welche Features bereits funktionieren müßten und welche nicht. So kann ich z.B. nur eine Zeile in der Trackliste markieren, danach aber keine mehr. Am besten du nennst die Bereiche mal, die explizit getestet werden sollen ...

Schwierig zu sagen. Funktionieren müßte das Auswählen und Anzeigen von Karten und Themes sowie das Rendering von Wegpunktlisten, Tracks und Routen. Abseits davon ist vieles noch nicht implementiert. Und Bugs lauern sicher überall - ich habe nicht viel getestet.

Falls Dir also etwas auffällt, dann beschreibe es kurz und ich antworte so schnell es geht, ob ich das Problem kenne oder ob ich genauere Informationen benötige, wie ich den Bug reproduziere.

Falls Du nichts schreibst, ist es auch nicht so schlimm: ich habe bereits einige Bugs gefunden und behebe sie, bevor ich mich an den Karten- und Themedownload mache.

PS: Das Thema Kartenanzeige scheint schon ganz gut zu funktionieren.

Das freut mich.

[toc-rox]

Meine Tests (unter OS X, 64bit) waren leider wenig erfolgreich. Vermutlich liegt das daran, daß ich mit "RouteConverterWindows.jar" getestet habe. Frage: Kann ich damit unter OS X überhaupt sinnvoll testen?

Gruß Klaus

[routeconverter]

Meine Tests (unter OS X, 64bit) waren leider wenig erfolgreich. Vermutlich liegt das daran, daß ich mit "RouteConverterWindows.jar" getestet habe. Frage: Kann ich damit unter OS X überhaupt sinnvoll testen?

Ich fürchte nicht: die Windows-Version ist kaum getestet und mangels Mac teste ich Mac OS X gar nicht.

Für mich viel interessanter wäre Deine Meinung zu folgender Frage: Du stellst Deine Freizeitkarte für ganz Deutschland zur Verfügung, was einen Download von 1 GByte bedeutet bevor es losgehen kann. Wäre es nicht sinnvoller, kleine Kartenausschnitte herunterzuladen und dafür mehrere parallel anzeigen zu können? Und: gibt es Nutzer, die die niederländische und die deutsche Freizeitkarte parallel verwenden möchten? mapsforge gäbe das her.

[toc-rox]

Für mich viel interessanter wäre Deine Meinung zu folgender Frage: Du stellst Deine Freizeitkarte für ganz Deutschland zur Verfügung, was einen Download von 1 GByte bedeutet bevor es losgehen kann. Wäre es nicht sinnvoller, kleine Kartenausschnitte herunterzuladen und dafür mehrere parallel anzeigen zu können? Und: gibt es Nutzer, die die niederländische und die deutsche Freizeitkarte parallel verwenden möchten? mapsforge gäbe das her.

Das Thema "Kartenzuschnitt" ist ein relativ schwieriges. Hier gilt es die Balance zwischen einer sinnvollen Gebietsabdeckung und einer moderaten Dateigröße zu finden. Gerade beim Smartphone werden die Karten meist via WLAN geladen und viele Geräte haben einen sehr begrenzten Speicher.

Sehr wünschenswert ist die automatische Anzeige weiterer identischer Karten (sofern diese vorhanden sind). Beispiel: Der User hat Karten für Deutschland und die Niederlande heruntergeladen. Aktuell betrachtet er die Karte für Deutschland. Verschiebt er die Karte jetzt in Richtung Niederlande, sollte automatisch die Niederlandekarte nachgeladen werden. Btw: Die Android-App "Locus Maps" macht das genau so.

Derzeit sind die (meisten) Freizeitkarten so zugeschnitten, daß sie um 30-50km über die Landesgrenze hinausgehen. Dies aus zwei Gründen: Für die Nutzer die in Grenznähe wohnen und um eine gute Kartenüberlappung zu erreichen (damit an der Grenze (bei paralleler Anzeige) keine Lücken entstehen).

Gruß Klaus

---

Bezüglich der Mac-Version: Stell die doch einfach mal zur Verfügung.

[routeconverter]

PS: Was ist mit "Gibt es Programme, die das lesen können?" gemeint?

Ich hatte angenommen, daß Du die XML-Datei für Programme bereitstellst, die sie herunterladen, um zu wissen, ob es neue Freizeitkarten liegen und wo sie herunterzuladen sind. Für Menschen hättest Du wohl eher eine HTML-Seite gebaut, oder?

[toc-rox]

Ich hatte angenommen, daß Du die XML-Datei für Programme bereitstellst, die sie herunterladen, um zu wissen, ob es neue Freizeitkarten liegen und wo sie herunterzuladen sind. Für Menschen hättest Du wohl eher eine HTML-Seite gebaut, oder?

Ja genau, das Repository ist gedacht für den programmgestützten Download und Aktualitätsabgleich. Für letzteres habe ich noch einige Erweiterungen (zusätzliche Elemente) in die XML-Struktur aufgenommen. Ein entsprechend produktives Repository wird ca. Mitte Februar verfügbar.

Gruß Klaus

[routeconverter]

Ich hatte angenommen, daß Du die XML-Datei für Programme bereitstellst, die sie herunterladen, um zu wissen, ob es neue Freizeitkarten liegen und wo sie herunterzuladen sind. Für Menschen hättest Du wohl eher eine HTML-Seite gebaut, oder?

Ja genau, das Repository ist gedacht für den programmgestützten Download und Aktualitätsabgleich. Für letzteres habe ich noch einige Erweiterungen (zusätzliche Elemente) in die XML-Struktur aufgenommen. Ein entsprechend produktives Repository wird ca. Mitte Februar verfügbar.

Gruß Klaus

Für den Download von Höheninformationen (aka .hgt-Dateien) sowie den BRouter benötige ich ähnliche Informationen:

Code:

<datasources xmlns="http://www.routeconverter.com/datasources">
    <datasource name="BRouter" baseUrl="http://h2096617.stratoserver.net/brouter/segments2/" directory="brouter">
        <file uri="E0_N10.rd5" size="2236187" checksum="9DE01AE68A11F500E3A3C8543177820231EFE895"/>
        <file uri="E0_N15.rd5" size="1390045" checksum="E0A711B9B9CF64929672234D7BD01EFFDE15C061"/>

sowie

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<datasources xmlns="http://www.routeconverter.com/datasources">
    <datasource name="NASA SRTM 3" baseUrl="http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/" directory="srtm3">
        <fragment key="N00E006" uri="Africa/N00E006.hgt.zip" size="2884802" checksum="8014E27BD824CDA8F1F6094B919AA63A3369101E"/>
        <fragment key="N00E009" uri="Africa/N00E009.hgt.zip" size="2884802" checksum="D5DE3E2B85162CEA796DF3C777467A28CDECB573"/>

        <file uri="Africa/N06E006.hgt.zip" size="1178595" checksum="CB405811BBDE567E31F7FC48CCBEE2B797E8E8AE"/>

Das XML-Schema dafür findest Du im Repository.

Eigentlich wollte ich dasselbe Verfahren für die Kartenrepositories verwenden. Das sähe dann für die Freizeitkarte etwa so aus:

Code:

<datasources xmlns="http://www.routeconverter.com/datasources">
    <datasource name="Freizeitkarte Map" baseUrl="http://download.freizeitkarte-osm.de/Experimental/MapsForge/Beta6/" directory="map/freizeitkarte">
        <file uri="freizeitkarte_alps_east.map.zip" size="642494391" checksum="9DE01AE68A11F500E3A3C8543177820231EFE895"/>
        <file uri="freizeitkarte_alps_west.map.zip" size="642494391" checksum="9DE01AE68A11F500E3A3C8543177820231EFE895"/>
        
    <datasource name="Freizeitkarte Theme" baseUrl="http://download.freizeitkarte-osm.de/Experimental/MapsForge/Beta6/" directory="theme/freizeitkarte">
        <file uri="freizeitkarte.zip" size="642494391" checksum="9DE01AE68A11F500E3A3C8543177820231EFE895"/>

Allerdings hieße das, daß ich die Dateigrößen, Prüfsummen und weitere Metadaten für alle Datenquellen weiterhin selbst erstellen müßte. Langfristig ist das keine gute Idee und es wäre toll, wenn alle Datenquellen ein Metadaten-Katalog bereitstellten. Dein Format ist natürlich für Deine Freizeitkarte optimal, meins hat für mich den Vorteil, daß ich für Karten und Themes dieselbe (Programm-)Infrastruktur wie für Höhen- und Routinginformationen nutzen kann.

[toc-rox]

Bei den Höhen- und Routingdaten könnte man mal prüfen, ob die erforderlichen, kachelbezogenen Daten nicht algorithmisch bestimmt werden können. M.E. müßte das gehen sofern die Bounding-Box des Zielbereichs (z.B. die Kartenanzeige oder die Route) bekannt ist.

Das Freizeitkarte-Repository erfährt noch eine Erweiterung der Metadaten. Hinzu kommen werden noch all die Informationen die mit "Mapsforge" beginnen. Damit ist ein Versionsabgleich möglich ... und der Benutzer kann z.B. auf neuere Karte hingewiesen werden.

Code:

<Map>
    <Name>Freizeitkarte_ITA</Name>
    <DescriptionGerman>Freizeitkarte Italien</DescriptionGerman>
    <DescriptionEnglish>Freizeitkarte Italy</DescriptionEnglish>
    <Url>http://download.freizeitkarte-osm.de/Experimental/MapsForge/Beta6/freizeitkarte_ita.map.zip</Url>
    <Size>644530399</Size>
    <Checksum>1d7fcf1b151b3ed3d45a1de73cb5cdbf</Checksum>
    <LocusActionLink>locus-actions://http/download.freizeitkarte-osm.de/Experimental/MapsForge/Beta6/locus_install_map_freizeitkarte_ita.xml</LocusActionLink>
    <MapsforgeFileVersion>3</MapsforgeFileVersion>
    <MapsforgeFileSize>813439239</MapsforgeFileSize>
    <MapsforgeDateOfCreation>2013-12-21 23:35:02.000000</MapsforgeDateOfCreation>
    <MapsforgeBoundingBoxMinLat>35076380</MapsforgeBoundingBoxMinLat>
    <MapsforgeBoundingBoxMinLon>6602696</MapsforgeBoundingBoxMinLon>
    <MapsforgeBoundingBoxMaxLat>47101690</MapsforgeBoundingBoxMaxLat>
    <MapsforgeBoundingBoxMaxLon>19124990</MapsforgeBoundingBoxMaxLon>
    <MapsforgeTileSize>256</MapsforgeTileSize>
  </Map>

Möglicherweise lassen sich die XML-Daten geeignet in dein Zielformat transformieren ... damit habe ich allerdings keine Erfahrung.

Gruß Klaus

[routeconverter]

Das Thema "Kartenzuschnitt" ist ein relativ schwieriges. Hier gilt es die Balance zwischen einer sinnvollen Gebietsabdeckung und einer moderaten Dateigröße zu finden. Gerade beim Smartphone werden die Karten meist via WLAN geladen und viele Geräte haben einen sehr begrenzten Speicher.

Auch auf dem Desktop ist das ein Problem: bei dauert der Download von 1 GByte so 25-30 Minuten. Solange kann man Nutzer kaum hinhalten, wenn sie "mal kurz außerhalb der existierenden Karte gucken" wollen.

Sehr wünschenswert ist die automatische Anzeige weiterer identischer Karten (sofern diese vorhanden sind). Beispiel: Der User hat Karten für Deutschland und die Niederlande heruntergeladen. Aktuell betrachtet er die Karte für Deutschland. Verschiebt er die Karte jetzt in Richtung Niederlande, sollte automatisch die Niederlandekarte nachgeladen werden. Btw: Die Android-App "Locus Maps" macht das genau so.

Das könnte ich auch einrichten - doch geht der "Spaß" für den Nutzer erst nach dem länglichen Download weiter. Wären da nicht mehr kleinere Fragmente angenehmer?

Derzeit sind die (meisten) Freizeitkarten so zugeschnitten, daß sie um 30-50km über die Landesgrenze hinausgehen. Dies aus zwei Gründen: Für die Nutzer die in Grenznähe wohnen und um eine gute Kartenüberlappung zu erreichen (damit an der Grenze (bei paralleler Anzeige) keine Lücken entstehen).

Kann man dann zwei Karten überhaupt sinnvoll parallel darstellen? Theoretisch sollten sie ja dieselben Daten enthalten...

[toc-rox]

Das könnte ich auch einrichten - doch geht der "Spaß" für den Nutzer erst nach dem länglichen Download weiter. Wären da nicht mehr kleinere Fragmente angenehmer?

Der Wechsel des Kartennutzungsparadigmas von Online auf Offline hat auch Nachteile. Einer davon ist sicherlich die Hürde des zunächst erforderlichen Kartendownloads. Für die bisherigen Nutzer von RouteConverter dürfte das neu und somit ungewohnt sein. Grundsätzlich haben die Nutzer von Offline-Kartenanwendungen, z.B. BaseCamp oder QLandkarte, damit aber kein Problem. Aber zu deiner Frage: Kleinere Gebiete und damit kürzere Downloadzeiten wären, zumindest am Anfang, durchaus wünschenswert.

Kann man dann zwei Karten überhaupt sinnvoll parallel darstellen? Theoretisch sollten sie ja dieselben Daten enthalten...

M.E. kann man zwei Karten durchaus sinnvoll parallel anzeigen. Die oben liegende Karte überlagert dann die darunter liegende. Beim gleichen Kartentyp (z.B. beides Freizeitkarten) merkt der Benutzer davon eigentlich nichts.