Hi !
ich falle immer wieder über Relationen die im Zuge der Liz-Umstellung ungültig sind.
Kennt sich einer soweit mit dem ganzen Wiki aus das man vielleicht mal die toten Relationen aufdecken kann ?
Gruß Jan 
Moin Moin, Jan
meine Antwort: Jain 
Ich würde einen XML-Parser für die Programmiersprache deiner Wahl nehmen und folgenden Weg gehen:
- Wiki-Seite öffnen (Html-Seiten sind XML-Seiten!)
- Schleife über alle Links (XML-Nodes mit “a”)
- ist das Link zu einem OSM-Objekt? attribute="href=www.openstreetmap.org/browse/"*
- Mit der OSM-Api nachsehen, ob es die (noch) gibt (ist auch XML)
- “motzen”
- end loop
Bei mir wäre das Java (“richtiges” Java, nicht Java-Script) und als XML-Parser Stax (Streaming Sax).
Ich weiss, schwerer Toback, aber so geht es.
Hier mal ein Beispiel, wie ich die Notes einlese:
/* ************************************************************************* */
Note getFromDoc(long id, Element NoteElement) {
Note nt = new Note();
nt.id = id;
nt.date_created = Timestamp.valueOf(getValue(NoteElement,"date_created").substring(0,19));
String dc = getValue(NoteElement,"date_closed");
if (!dc.equals(""))
nt.date_closed = Timestamp.valueOf(dc.substring(0,19));
else
nt.date_closed = null;
nt.open = getValue(NoteElement,"status").equals("open");
nt.lat = NoteElement.getAttribute("lat");
nt.lon = NoteElement.getAttribute("lon");
Point pt = new Point(Double.valueOf(nt.lon),Double.valueOf(nt.lat));
pt.setSrid(4326);
nt.way = new PGgeometry(pt);
Node Comments = NoteElement.getElementsByTagName("comments").item(0);
Element CommentsElement = (Element) Comments;
NodeList Comment = CommentsElement.getElementsByTagName("comment");
int num = Comment.getLength();
for (int i = 0; i < num; i++) {
NoteDet temp = new NoteDet();
temp.note= id;
Node comment = Comment.item(i);
Element CommentElement = (Element) comment;
temp.dtm = Timestamp.valueOf(getValue(CommentElement,"date").substring(0,19));
temp.uid = getValue(CommentElement,"uid");
temp.user = getValue(CommentElement,"user");
temp.user_url = getValue(CommentElement,"user_url");
temp.action = getValue(CommentElement,"action");
temp.text = getValue(CommentElement,"text");
temp.html = getValue(CommentElement,"html");
nt.details.add(temp);
}
return nt;
}
/* *********************************************************************************************** */
public Note getFromOSM(long id) throws Exception {
String myName = "Note.getFromOSM()";
String Url = "http://api.openstreetmap.org/api/0.6/notes/"+id;
SimpleLog.write(myName+" reading note "+id);
DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document doc;
Element NoteElement;
try {
doc = db.parse(Url);
NodeList Notes = doc.getElementsByTagName("note"); // get note from api
Node Note = Notes.item(0);
NoteElement = (Element) Note;
}
catch (FileNotFoundException ex) {
SimpleLog.write(myName+" Note "+id+" not found");
return null;
}
finally {
}
return getFromDoc(id, NoteElement); // get details from document
}
getFromOSM bekommt eine Id, besorgt sich die Note; getFromDoc liesst den Rest. Das ganze geht aber auch in fast jeder anderen Programmiersprache. Soll halt nur ein Beispiel sein.
Gruss
walter
hi !
ich dachte vielleicht das das einer als “Dienst” mal in das Wiki aufnehmen.
Gruß Jan
Fuer verschiedene Programmiersprachen gibt es auch fertige Bibliotheken zum Einlesen von Mediawiki-Seiten.
Das mit den ungueltigen Relations-IDs im Wiki sollte m.E. allerdings nicht geloest werden, indem man sie staendig findet und repariert, sondern indem man sie unterlaesst wir hatten das Thema ja schon oft. Objekt-IDs in OSM sind einfach nicht stabil genug dafuer.
Bye
Frederik
Da Jan 
das gesamte Wiki durchforsten (lassen) will, wäre es vermutlich besser, einen Wiki-Dump heranzuziehen. Gerüchten zufolge gibt es den irgendwo. Im Wiki-Quelltext sehen die Links dann natürlich etwas anders aus (Links und Makros aka Templates, in verschiedenen Varianten).
Klar, ist eigentlich fast so schlimm wie die von mir ach so “geliebten” Sammelrelationen.
Ich bin ja ein “Fan” einer auf [UUID Version 4](Universally Unique Identifier – Wikipedia UUID) oder gar Version 5 basierenden Lösung aber die Akzeptanz bei OSM ist äußerst gering, wenn nicht sogar ablehnend.
Gruss
walter
tl;dr: UUIDs werden automatisch generiert und haben einen so großen Adressraum ~5*10**36, daß sie nahezu nie identisch sein können.
das sind die UUID=“86587d35-fe56-4176-810e-9cade0d97d3c”, die ihr bestimmt von Platten kennt.
Bei V5 wären das ähnlich viele Ids alleine für OSM - das sollte reichen.
ps: könnte man ja mal provokativ in die neuen BS-Rels reinnehmen und Erfahrungen damit machen.
gerade eingefallen: Auch diese UUIDs könnten verschwinden und für das Wiki unauffindbar sein, falls jemand das Objekt neu erstellt und die UUID nicht überträgt. Daher wäre ein Link-Check “Ist das Teil noch in OSM” durchaus sinnvoll.
Du magst recht haben, dass OSM-IDs nicht stabil sind. Aber ein Link zu einer relation sagt einfach mehr aus als wenn man sagt such dir mal ein passendes Beispiel. Wie kann man denn OSM Objekte sinnvoll verlinken, wenn es nicht die ID ist?
Hi !
ich schließe mich dem von viw an …
Ein Bild sagt dem Laien und damit der breite Masse mehr als alles andere und OSM ist doch aus meiner Sicht ein Projekt was vom Mitmachen der breiten Masse leben soll.
Oder habe ich da etwas übersehen.
Gruß Jan
indem man ihm eine UUID verpasst. Die bleibt, auch wenn sich die osm-id ändert.
siehe: http://www.openstreetmap.org/relation/104906
Gruss
walter
ubuntu: uuidgen ergibt eine UUIDv4: bd2a738e-88ce-4136-b059-bc431c8d78e5
Ganz ehrlich? Das ist ein Schlüssel den ich jederzeit ändern oder löschen kann. Wie soll dieser dazu dienen das Ding wiederzufinden? Ich meine die OSM ID verschwindet nur wenn man das Objekt löscht. die UUID kann sogar während der normalen Bearbeitung verschwinden oder geändert werden.
Außerdem ist nicht sichergestellt das nicht ein zweites Objekt diese ID trägt. Das ist bei OSM-IDs schonmal sicher.
Kannst Du mal etwas ausführlicher erläutern, wie Du Dir das bei OSM vorstellst? Ich sehe noch nicht, wie die Idee umgesetzt werden und welche Vorteile sie bieten soll. Soll die UUID in ein Tag geschrieben oder als zusätzliches Merkmal wie ID, Version etc. gespeichert werden?
Konkretes Beispiel, Situation jetzt: jemand (“J”) verlinkt das Objekt O, etwa als Anschauungsobjekt im Wiki. J setzt im Wiki beispielsweise (für einen Weg) das Template {{Way|O}}, verlinkt also direkt auf die Objekt-ID.
Einige der bekannten Probleme mit diesem Vorgehen:
-
O sei ein Weg. O wird mit einem anderen Weg N<O zusammengefügt - N wird länger und O verschwindet; der Link führt ins Nichts.
-
Der Weg O wird mit einem anderen Weg N>O zusammengefügt - O wird länger, repräsentiert aber nun etwas anderes als zuvor (z.B. die gesamte Straße statt nur eines Abschnitts). Der Link funktioniert noch, ist aber womöglich unnütz.
-
O wird aufgespalten - es existieren nun zwei Wege O und P, die dasselbe reale Objekt (z.B. eine Straße) repräsentieren wie zuvor O allein. Wenn zuvor “die X-Straße” verlinkt war, ist es jetzt nur noch “die X-Straße bis zur Einmündung Y-Gasse”.
-
Die vorigen Beispiele beziehen sich auf das Editierverhalten von JOSM. Ein anderer Editor erzeugt beim Zusammenfügen womöglich einen ganz neuen Weg P - dann sind N und O futsch, und P ersetzt weder N noch O exakt, sondern stellt etwas (mehr oder weniger) anderes dar; oder beim Aufspalten wird O gelöscht und durch zwei neue Wege P und Q ersetzt. Ähnlich geschieht es sogar in JOSM beim Einsatz bestimmter Plugins.
-
O wird komplett umgedeutet, aus einer Bank in Karlsruhe wird eine Tankstelle in Hamburg. (Ist untypisch, kommt aber vor, vgl. etwa r1111111.) Auch hier ist der noch funktionierende Link unbrauchbar.
-
Objekteigenschaften werden von einem Objekt aufs andere übertragen, etwa von einem Adressknoten aufs Gebäude. Das ursprüngliche Objekt wird entweder gelöscht oder nicht (oder der alte Knoten ins neue Gebäude eingebaut, oder sogar in ein völlig anderes Objekt); wieder ist der Link entweder tot oder (weitgehend) nutzlos. Ähnlich beim Umbau einer einfachen Fläche zu einem Multipolygon oder umgekehrt dem Rückbau eines MP-Monsters.
-
Ähnlich, wenn ein Objekt komplett neu aufgebaut und der Vorgänger gestrichen wird (etwa eine völlig verkorkste ÖPNV-Relation durch eine neue, saubere ersetzt wird). Die neue Relation tritt an die Stelle der alten.
Bei der Speicherung von UUIDs in Tags kommen noch die von viw angesprochenen Probleme dazu: UUIDs können geändert werden, verschwinden oder fehlerhaft kopiert werden, denn für eine korrekte Verarbeitung müßten alle Editoren diese UUID-Tags unterstützen bzw. gesondert behandeln. In JOSM und iD ließe sich das umsetzen, aber schon bei Potlatch (noch >10% Bearbeitungsanteil) habe ich wenig Hoffnung, ganz zu schweigen von den ganzen Nischeneditoren, die zum Teil ebenfalls seit Jahren “unmaintained” sind (Merkaartor, iLOE, ArcGIS, QGIS, MapStalt, …) oder durch ihren beschränkten Funktionsumfang bereits jetzt immer wieder Probleme machen.
Bei einer Speicherung “zusätzlicher Identifier” in Tags fallen mir wieder die AND_nosr_r-Tags in NL ein, die dort seit dem Import versauern und durch sporadische Bearbeitungen längst unbrauchbar geworden sind. Oder, um im Lande zu bleiben, openGeoDB:.*.
Ich frage meine DB und ihr könnt die Overpass nehmen - ob oder wann WIKI Overpass kann, ist mir allerdings nicht bekannt.
hast du eine Ahnung, wie groß 5*10**36 ist?
schau mal hier: 500.000.000.000.000.000.000.000.000
nun denn, nein sagen ist einfach, was anderes vorschlagen wäre besser.
walter
Das ist aber leider nur die halbe Wahrheit. Da der Schlüssel jederzeit änderbar ist und damit die Links auch wieder unbrauchbar werden.
Worin besteht denn der Unterschied zwischen UUid und der OSMID? Der einzige Unterschied ist dass die UUID bearbeitbar ist. Man könnte sie an ein neues Objekt hängen. Man kann sie aber ebenso leicht zerstören.
Eine einzigartigkeit der ID ist in keinem Fall sichergestellt, kann auch gar nicht! Denn einer uuid:operator sollte bei allen Objekten des gleichern Betreibers gleich beliben. Woran unterscheidet man jetzt ob es der Gleiche oder ein anderer Operator ist? Dazu bleibt eigentlich nur das operator tag selbst. Jedenfalls wenn alle Deutsche Bahn schreiben und nicht Deutsche Bahn AG oder DB oder irgendwas ganz anderes.
Das Ganze ist also mindest genauso anfällig wie die OSM-ID.
Ich hab eine Overpass-Abfrage der Kreisstraßen im Landkreis Dahme-Spreewald
hier eingebaut. Die bbox-Angabe ist noch zu groß, da diese ganz Brandenburg umfasst.
Die Abfrage:
<osm-script output="json">
<query type="relation">
<has-kv k="type" v="route"/>
<has-kv k="route" v="road"/>
<has-kv k="operator" v="Landkreis Dahme-Spreewald"/>
<bbox-query e="15.0" n="53.5" s="51.3" w="11.2"/>
</query>
<print mode="body"/>
<recurse type="down"/>
<print mode="skeleton"/>
</osm-script>
Ich habe dazu die Funktion “teilen” benutzt. Es gibt aber sicher noch eine elegantere Lösung.
Sven
Das hab ich weiter oben schon längst erwähnt. Du kannst ja auch nicht verhindern, das jemand den Namen eine Grenzrelation ändert und da “Lummerland” dran schreibt.
Die OSM-ID ist der Primary Key des Datensatzes in der OSM-Datenbank, die UUID wäre ein Tag. Der Key kann sich ändern, Tags auch. Was kannst du besser zurücksetzen, wenn hier wirklich jemand Mist gebaut hat? Den Key (OSM-ID) auf jeden Fall nicht, der ist für Immer und Ewig verbrannt.
Das, was du hier (aus lauter Verzweiflung?) an den Haaren herbeiziehst, war und ist nicht Bestandteil dieser langsam auswuchernden Diskussion. Es geht hier um Objekte (Nodes, Ways und Relationen), die einem so wichtig erscheinen, daß sie immer und unter alle Umständen auffindbar bleiben sollen, auch wenn sich deren OSM-ID mal ändern sollte. Bring doch mal ein Beispiel, wo du in einem Tag die OSM-ID eines anderen Objektes verwendest. Würde mich wundern, wenn du welche findest.
Kann aber jederzeit von jedem gefixt werden.
Vorschläge außer “nein, geht nicht”?
Sehr hübsch und verd… schnell. Ich glaube, ich stampfe meine Karte ein 
aber eigentlich meinte ich mehr die Liste unten drunter - also Textausgaben oder Abfragen, die in Texte einfließen.
Gruß
walter
Das halte ich für groben Unfug. Es mag sein das du beim anlegen eines Objektes über die API keine Möglichkeit hast den Key zu setzen. Wenn du hingegen auf Datenbankebene arbeitest ist es dir durchaus freigestellt den Index selbst zu wählen. Du bekommst dann natürlich eine Schlüsselverletzung wenn der Key bereits vorhanden ist.
Bei deiner UUID würde es hingegen keinem Auffallen, wenn die 100mal an verschiedenen Objekten hochgeladen wird.
Lieber wambacher. Ich habe einfach einmal einen Blick in das Proposal geworfen:
http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID#UUID_Tagging
was bitte sollen diese ganzen uuid tags dort bedeuten wenn nicht die von mir beschriebene herangehensweise?
Du selber verwendest diese OSMID-Verknüpfung nicht. Das macht die API für dich. Bei jedem Weg und jeder Relation werden die OSMIDs der beteiligten Objekte eingefügt. Würde mich wundern wenn das in deiner Datenbank anders ist.
Es kann von jedem gefixt werden. Naja die Links können auch von jedem geändert werden! Was soll das für ein Argument sein?
hi!
aber sind solche Overpass-Abfrage der Weisheits letzter Schluss.
Wenn ich eine Verlinkung über die ID oder den Namen oder … ein Attribut mache, dann sind diese alle immer änderbar.
Ich würde das mit einer Auflistung toter ID in Zeitabständen (vergleichbar https://wiki.openstreetmap.org/wiki/Special:BrokenRedirects)) nicht dann sinnvoller?
Gruß Jan
+1 denn die Toten links sind mit Sicherheit falsch. Leere Overpassapianfragen helfen den Leseren des Artikels genausowenig weiter.
hier mal ein Overpass-Beispiel, daß der Sache schon ein wenig näher kommt:
<osm-script output="json">
<query type="relation">
<has-kv k="uuid" v="bd2a738e-88ce-4136-b059-bc431c8d78e5"/>
</query>
<print mode="body"/>
<recurse type="down"/>
<print mode="skeleton"/>
</osm-script>
Mehr wollte ich eigentlich nicht anregen. Ob und wie das allerdings für Nicht-Grafik-Links funktioniert, muß ich mal irgendwann checken.
Dazu kenn ich die Overpass zu wenig.
Gruß
walter