Das Thema ist mir zu komplex, um es (gleich) in englisch zu schreiben. Ich bin auch kein Experte, kenne nicht mal die Probleme und Notwendigkeiten so genau. Das hier ist also eher ein Brainstorming mit einigen Schlagworten:

• Anything will be an area
• There has always be Vector Tiles
• Don’t tag vor the Vector Tiles
• Make the problem to the solution

Area als neuen Objekt-Typ ist nur Tagging-Sugar, die Verpackung wird einsichtiger, der Inhalt bleibt. Ein Kreisverkehr braucht kein area=no mehr, der Spielplatz keine identischen End-Nodes. Trotzdem bin ich dafür. Einige Editoren haben Areas ja auch schon im Interface. Ich sehe in Zukunft immer mehr Areas, auch für Wege. Am Ende ist jeder Fleck Erde Teil irgend eines Areas. Das ist gut für zoomed Rendern, für Rollstuhl-Karten und 3D Rendern. Es ist nur schlecht für rooting; vielleicht sollte im Way-Object eine Hilfe sein, eine Liste zu den anschließenden Wegen.

Vektor Tiles sind im Kern geordnete Informationen für ein Gebiet. Die brauchte man auch schon bei den ersten Bitmap-Renderern. Aus der Tagging-Anarchie wurden, und werden, Objekte in Layer gefiltert. Und dabei wird entschieden, was überhaupt sichtbar wird! Erst im nächsten Schritt werden die Objekte zu sichtbaren Linien, Flächen oder 3D Objekten. Daher dürfen Vektor Tiles nicht das aussehen festlegen und auch nicht bestimmen, was auf die Karte kommt. Allerdings gibt es “normale” Objekte, die jeder braucht und Seltene für Spezial-Karten. Mein Ansatz wäre: Immer zwei Tile-Dateien bereit zu stellen, eine die kompakt alles “normalerweise” notwendige enthält und eine mit wirklich dem ganzen Rest; schräge Sachen notfalls in einen Layer “sonstiges”. Den muß der Rendere dann nach dem Tagging der Objekte selbst sortieren.

“Don’t tag for the renderer!” sollte jeder kennen. Wird das in Zukunft auch für die Erstellung der Vektor Tiles gelten? Denn dabei wird schon viel geprüft und entschieden. Ein Editor könnte diesen Schritt transparent machen und das Objekt darstellen, wie und wo es in Tiles erscheinen würde. Dann ist es nicht mehr weit, bis man “direkt” in der Tile Editiert. Am Ende könnte das bisherige Tagging-Durcheinander komplett entfallen.

Aus dem offenen Tagging eine Zuordnung zu den Render-Layern zu schaffen ist auch heute schon notwendig. Allerdings kann hier jeder Renderer machen was er will. Wenn das schon für die Vektor-Tile gemacht wird, wird es vereinheitlicht/zentralisiert. Die meisten, aber nicht alle wird das freuen, erst recht, wenn das dann schon im Editor erzwungen wird. Nein, freie Tags müssen bleiben. Auch wenn die Vector-Tile die nicht “brauchen” kann, müssen sie mitgenommen werden. Der Renderer hat dann das Problem aber auch die Freiheit.

Zurück zum Data Model

Die Way-Nodes als Liste in das Way-Objekt scheint mir ok zu sein. Wenn der Weg jetzt einen Zebrastreifen hat, ist das ein eigenständiges Node-Object. Oder nenne wir es vielleicht gleich POI-Object! Nur hat dieses dann keine eigene Geo-Position sondern eine Referenz auf den Way und in die Liste dort.

Die Object IDs machen Probleme? Können wir sie vielleicht ganz los werden? Ich kann mir nicht vorstellen, das jeder Renderer immer alle World-Objekte scannt um die aus dem benötigten Gebiet zu finden; da gibt es schon Indizierungen, 2D Bäume oder so was. Ist das im Grunde genommen nicht schon eine Einteilung in Tiles? Wenn wir das Datenmodel schon so gestallten, dass die Objekte in Tiles-Datensätze sortiert sind würden die erwähnten Rechenprobleme würden doch entfallen. Ja, an den Grenzen gibt es viel Hirnschmalz einsetzen. Ds muß ja jetzt jeder Vektor-Tile-Builder auch schon schaffen.

Die Way-IDs sind also eher kleine Indices in die Tile-Lokale-Datenbank. Node IDs braucht es garnicht mehr? Zum Karten Rendern vielleicht nicht, aber für Busslinien etc. schon. Referenzen in Relationen brauchen ggf. neben der Objekt-ID auch die Tile-“ID”. Wenn die OSM-Objekte schon in Tiles sortiert sind kann man sie gut auf verschiedene Rechner verteilen. Editieren im Datensatz aktualisiert quasi sofort die Vektor Tile.

Natürlich sollte der editierende Mensch nicht auf die Tile-Grenzen achten müssen. Ja aber wie sollte dann das OSM-API aussehen? Immer noch nur lat/lon oder schon Tile-bezogen? Denkbar ist beides. IDs werden weiter benötigt. Wenn sie aber schon “Tile.Nr” sind, muß der Editor das auch können. Und wenn ein Objekt über die Tile-Grenze geschoben wird?! Wenn ein Way über nicht nur ein bisschen über die Tile-Grenze ragt? Wenn der oben genannte Zebrastreifen ausgerechnet in der benachbarten Tile ist? Vielleicht brauchen Tiles einen gewisse Überschneidungsbereich und wenn der nicht reicht, wird der Way automatisch gesplittet in Zwei. Wenn eine Relation POIs in ganz Europa auflistet? Sind Tile.ID stabile Referenzen? Als Byte-Offset nicht; und ein Objekt-Index nur, wenn gelöschte Objekte nicht neu vergeben werden. Sollten Objekte besser Rückwärts-Referenzen zu ihren Relationen haben?

So einfach ist das alles nicht, wie ich das hier erträume !!!

Welches Zoom-Level meine ich? Na so 18 vielleicht? Dann kommt man schnell an einzelne Daten. Und wenn die Dateien zu klein und zu viele werden kann man je 4 oder 16 Zusammen fassen, aber so, das nach dem Laden die einzelnen (PBF-)Teile wieder unabhängig verarbeitet werden können. Ob man das auch bis zum World-File treiben sollte? Warum nicht? Über Changesets möchte ich aber lieber nicht nachdenken.

Da war noch die Küstenlinie der Kontinente. Erst mal Teilstücke als Way. Mit Links zu den Nachbarstücken? Relationen für die Teile eines Bezirks oder Lands? Super Relationsbaum bis zu “Australien”?

Ich lege diesen Text jetzt mal hier offen ab; er kann sich aber noch ändern!