Ich habe nur MKnights Vorschlag optimiert. Ich habe nicht gesagt, dass ich die Idee generell gut finde 
–ks
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
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29
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?
Wie war das noch mal? “Wir haben eine wunderbare Lösung, uns fehlt nur noch das Problem dafür.”
Also wissen 'se nee
walter
Das “Problem” habe ich im ersten Beitrag skizziert:
Und was das Problem betrifft:
(Hervorhebungen nachgetragen…)
Wenn da irgendwas missverständlich war, keine Ahnung, wollte keinen Roman schreiben 
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) 
Ach so. Ok, das habe ich nicht als Problem erkannt.
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.
Gruss
walter
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…
Meine Meinung dazu:
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.
Ist alles nur eine Frage, wo man hinsieht:
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.
Soviel zu “nirgens™”.
Gruss
walter
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.
Um das dort anzugeben, brauch ich erstmal ein n/w/r. Das ist genau, was ich im Post vorher meinte.
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).
Vielleicht sollten wir erstmal klären wo du überhaupt die ganzen ids herbekommst. Vielleicht liegt da schon dein Problem.
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.
Dann könnte man hinzufügen:
openstreetmap.org/object/w12345,r2345,w123,w124,w125
also auch eine Liste um überhaupt etwas von der Änderung zu haben -
sieht einer hier einen Nutzen?
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.