Das rd5-format ist ziemlich simpel aufgebaut:
-
Koordinatensystem ist “Mikrograd positiv”
-
keine NodeId’s, sondern stattdessen “unifizierte Geo-IDs”, also 64-Bit Zahlen aus lat-lon,
die ggf. um jeweils ein oder wenige Mikrograd verschoben wurden, um die Geo-ID eindeutig zu
machen damit sie als Schlüssel taugt.Dreistufiger Index:
-
eine Datei startet mit dem topevel-index (258=200 bytes) mit den start-offsets von
25 11 Grad Unterdateien -
eine Unterdatei startet mit dem index von 80804 = 25600 bytes mit den start-offsets
von 1/80 * 1/80 Grad Kacheln -
jede dieser Kacheln enthält die Knoten sortiert nach Geo-ID, sodass ein Knoten darin
über eine binäre Suche effizient gefunden werden kann
-
-
jeder Knoten codiert Geo-ID, Höhe, Node-Description Bitmap (64 bit) und dann die Liste der “Links”
-
jeder Link codiert die Geo-ID des Target-Knoten, und dann entweder:
- die Way-Description-Bitmap (64 bit) und ggf. noch eine Liste von
“Transfer-Knoten” (mit jeweils Geo-ID und Höhe) - oder ein Flag, dass anzeigt, dass der “Gegen-Link” am Zielknoten die Weg-Details codiert
- die Way-Description-Bitmap (64 bit) und ggf. noch eine Liste von
-
das ganze noch mit bisschen Pseudo-Kompression, um lat/lons ggf in 16 bit zu kodieren relativ zu irgendeinem
offset
Da fehlt schon einiges. Insbesondere die 64-Bit “Description-Bitmaps”, die die OSM Tags gemaess
der “lookup.dat” Tabelle codieren, sind eine Limitierung für die Zahl der Tags, und insbesondere
der Relationen, die man da rein codieren kann, und hier müsste ein “ordentlich entwickeltes”
Format dynamischer sein (aber eben trotzdem schnell, also nicht einfach die OSM-Tags als
Text da rein schreiben…)
In OsmAnds obf oder mapsforge steht schon deutlich mehr drin, und sie sind auch kompakter, also müsste eine Neuentwicklung zweifellos auf diesen Erfahrungen aufbauen. Aber ein routingfähiges Format, was (fast) keine OSM Daten wegwirft wäre schon ein interessantes Projekt.