Ein ID ist dafür und nur dafür da, einen Datensatz in einer Datenbanktabelle eindeutig zu identifizen und wird in der Regel von der Datenbank ohne weiteres Zutun automatisch bei Anlegen eines Datensatzes vergeben. Inhaltliche Information in einer ID zu verpacken, kenne ich nur aus alten Systemen, wo Speicherbedarf tatsächlich noch eine wesentliche Rolle gespielt hat und man jedes Byte ausgenutzt hat, um eine inhaltliche Information unterzubringen.
Bei neuern Systemen kenne ich nur nur inhaltslose IDs. Für inhaltliche Werte sind die Attribute (Spalten) in der Tabelle da.
Mir erschließt sich auch kein Anwendugsfall, wo die Einführung von klassifizierenden Nummern als ID auch nur annähernd der Aufwand für den notwendige Umbau der ganzen OSM-Infrastruktur rechtfertigen würde.
Mir z.B. ist in meiner gesamten OSM Laufbahn keine OSM-ID untergekommen, bei ich nicht erkennen konnte, ob sie nun zu einem node, way oder relation gehörte und ich z.B. JOSM die drei Möglichkeiten durprobieren musste.
Natürlich gibt es schon seit mittleren Ewigkeiten eine Konvention menschenlesbare Ids für OSM Objekte zu generieren, nämlich nid , wid und rid Die Ids sind dann zwar nicht mehr numerisch, aber das ist für die erwähnten Anwendungsfälle auch nicht wirklich nötig.
hatte ich (im Verlauf der Diskussion) auch schon diffus im Kopf, nur wenn die Konvention nirgends™ verwendet wird …
Ein Beispiel von vielen: http://www.openstreetmap.org/node/1234 gibt in der Beschreibung der ID:
Knoten: 1234 oder schlimmer: Knoten: Name des Knoten (1234). Bei Ways und Rels das selbe.
n1234 &Co ist mir bisher nur auf sehr wenigen Spezialkarten positiv aufgefallen.
JOSM kennt die Funktion “Datei/Objekt herunterladen”. Dort gibt man die Objektids der Objekte an, die man heruntergeladen habe möchte (ist ganz praktisch bei Relationen).
Dort kann man jederzeit auch nXXX, wXXX und rXXX angeben und mischen.
Genau gällt mit das Zitat nicht mehr ein, aber es ist sehr treffend:
Der Tot jeder Datenbank ist, wenn Du versuchst Unübersichtlichkeiten in der Bedienbarkeit durch Änderung der Datenstruktur statt Änderung der Bedienerführung zu lösen.
Und genau das finde ich in dieser Diskussion völlig angebracht.
Das ist nur eine Frage der Formatierung von IDs für die Darstellung nach aussen und im Prinzip das Gleiche wie z.B. die Darstellung als „Knoten: 1234“. Deshalb braucht man die eingeführte Art und Weise der Vergabe und Verwaltung von IDs nicht anzurühren, sondern ist allein Angelegenheit der Software für die Darstellung und Bearbeitung von OSM-Daten.
Aber deine Lieblingstools oder was auch immer so zu modifizieren, dass sie -auch- in dem Format ausgeben ist eine nahezu trivialer Aufwand (man kann davon ausgehen, dass alle Sachen die OSM Daten verarbeiten, ja die Information schon haben was es für ein Element ist), im Vergleich dazu eine fundamentale Änderung an, essentiell, Allem in OSM zu machen (von den anderen Problemen die schon erwähnt wurden gar nicht zu reden).
Es ist dann einfach die Aufgabe dessen der die Id angibt das n,r,w passend hinzuzufügen, der
weiss das Objekt 12345 ein n, r oder w ist, soll er es halt per prefix dazu schreiben.
Die Diskussion hier ist vielleicht gut das als Standard zu verbreiten. Muss man
auch Software anpassen, das geht aber Schritt für Schritt.
Man könnte damit bei openstreetmap.org beginnen, also das man nicht openstreetmap.org/way/12345 schreiben muss sondern das z.B. auch openstreetmap.org/object/w12345 geht. Wobei man hier sieht das das
kaum einen Unterschied macht, auch way/12345 kann man als id ansehen.
Das von Skinfaxi mit der Datenbank finde ich auch vernünftig.
Das nun noch Ändern gibt^Wgäbe einen Haufen Müll, würde OSM um Jahre
zurückwerfen, Entwickler würden ihre Projekte nicht weiter warten,…
kann sogar zum Tod führen.
Da muss man einfach akzeptieren das manche Entscheidungen gefallen sind,
nun wie Tatsachen bestehen und man das nicht revidiert. Wenn sowas zu
unüberwindlichen Problemen führen würde kann man nochmal gucken ob
man so eine grundlegende Änderung doch durchführt, aber besser man lebt damit.
