Ich überlege da schon längere Zeit dran rum, ich halte es für sinnvoll (bzw. eher hilfreich) Objekt-IDs für die einzelnen Objektarten zu reservieren.
Ich erklär das mal an direktem Beispiel, versteht sich besser:
Adressraum
5.xxx.xxx.xxx für Nodes
6.xxx.xxx.xxx für ways
7.xxx.xxx.xxx für relationen
8.xxx.xxx.xxx für irgendwas komisches, was sich irgendwer irgendwann ausdenkt.
(Die Zahlen sind nur Beispiele, man kann das auch bei 10 MRD anfangen oder sonstwo)
Vorteil:
Mensch kann die Art eines Objektes an der ID erkennen → DAS ist ein Node vs. DAS ist ein Way …
Maschine kann die Art ein Objektes erkennen. Beispiel: Man hat eine ID in der Zwischenablage, JOSM:Objekt herunterladen → Wahrscheinlichkeit ist 100% dass Josm “weiss” was es laden soll, statt momentan 33%.
2 Fragen dazu:
gibt es sowas schon? Ich finde gerade keine halbwegs neuen ways (aber Nodes) mit ID 4 MRD.xxx
irgendwelche Nachteile bei der Vorgehensweise? Oder gar weitere Vorteile?
Verstehe ich nicht.
die 1. Mio wurde vor 11 Jahren vergeben, die erste Mrd. vor 6., der “Speicherplatz” wird also aktuell schon gefressen.
Meine Zahlen sind auch eher fiktiv, mir geht’s um das “Problem” an sich.
Die Idee von Kreuzschnabel finde ich ganz gut, da sie a: zukunftssicher aussieht und b: jederzeit angefangen werden könnte ohne auf “freie” Zahlen zu warten.
Ich hatte mir ja vor langer Zeit mal Gedanken dazu gemacht, gewisse Wertebereiche zu reservieren (z.B. a la privater IP Adressraum), oder mindesten die 50% die wir aktuell wegschmeissen für solche Zwecke zu strukturieren.
Trotzdem halte ich den Vorschlag von MKnight nicht für wirklich sinnvoll, einerseits ist der Nutzen sehr sehr klein wenn überhaupt vorhanden (es ist wirklich kein Problem mit den parallelen Wertebereichen umzugehen), anderseits ist es aber auch so, dass wir gerade bei den Nodes gar nicht sooooo viel Spielraum haben, sprich wir können aktuell 6 nodes/cm^2 auf der Landoberfläche verwenden (so lange wir nicht anfangen den Meeresboden zu mappen :-)). Das ist sicher genug, wenn man da aber nur 1/100 oder so davon hat, scheint es mir dann eher knapp. Ohne Umnummerierung sind IDs für gelöschte Objekte übrigens verloren, wir haben also neben den Verbrauch für aktuelle Objekte auch den zu berücksichtigen (aktuell +25%).
Damit brauchst du für Node, Ways und Relations 64bit Werte, heute benötigt man nur 64bit für die Nodes, der Rest geht (noch) mit 32bit. Das betrifft 419531586 Ways und 5062122 Relationen.
Und damit noch nicht gelöst, das Problem alle bestehenden Files auf das neue Schema umzustellen, also alle Minutely/Hourly/Daily diffs, alle Planets, alle Extrakte, etc. Weiterhin offen, entspricht jetzt ein Node ID dem alten oder neuen Schema? Totales Chaos ist 100% garantiert.
Es gibt aber in der Tat eine Anwendung, die heute schon mit diesen Adressräumen arbeitet und Node + Ways + Relationen auf eine eigene ID für Areas abbildet: Overpass API.
Dort wird das aber eher zum internen Managen der Areas benötigt, einem berechneten Objekt, was es so nicht in der OSM Datenbank gibt.
Area ID = OSM way + 2400000000
bzw.:
Area ID = OSM relation + 3600000000
Genau, mit “Magic-Numbers” (zB. 01=Node, 02=Way, 03=Rela) im Pre- oder Postfix könnte man das “Problem” bequem auf Interface Ebene abbilden, ohne die API damit zu quälen.
Das frage ich mich auch, Antworten konnte ich bisher nicht rauslesen.
Bevor man hier über etwaige Implementationen nachdenkt, sollte doch erstmal das Problem definiert werden, oder nicht?
Also ich finde, MKnight hat das doch sogar sehr exemplarisch aufgeführt:
Wenn ich euch jetzt einfach so eine ID hinknalle, z.B. die 5953053, was möchte ich dann gerne bearbeiten? Einen Node, einen Way oder eine Relation?
Nachtrag: wieder zu langsam
PS: Nachtrag zu MKnight: vielleicht sollten wir es nicht exemplarisch schreiben sondern direkt: man braucht um zu wissen, was man bearbeiten möchte, vorher erst mindestens eine Abfrage, um was für einen Typ es sich handelt …
und um es noch trockener und technischer zu schreiben, schaut euch einfach /#id an (da muss man wissen, ob es ein node ein way oder eine relation ist)
Nix. Ich bitte dich, aussagekräftige Daten zu liefern, ansonsten → Mülltonne.
Prinzipiell ist es natürlich richtig: Wenn es unterschiedliche Adressräume gäbe, wäre es hier einfacher. Aber das hätte man 2003 (?) mit Steve klären müssen, der das von Anfang an anders definiert hat.
Ändern kann man das theoretisch auch, aber einige der Konsequenzen hab ich (und andere Kollegen) ja bereits angedeutet.
Naja, ihr denkt halt sehr im “alten” relationalen OSM Datenbank-Schema … musste neulich auch erst die ID anpassen, als ich nodes, ways und relations in NoSQL Systeme wie MongoDB und Neo4J importieren wollte und eben KEINE getrennten Typen, sondern einfach nur “Dokumente” anlegen wollte, da hätte es mit den “doppelten” IDs gekracht
PS: unabhängig davon, dass es bei Neo4J sowie eine eigene _ID gibt…
