Wiki nach ungültigen RelationsID durchforsten

Lübeck wrote:

Kennt sich einer soweit mit dem ganzen Wiki aus das man vielleicht mal die toten Relationen aufdecken kann ?

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 :-)

wambacher wrote:

Ich würde einen XML-Parser für die Programmiersprache deiner Wahl nehmen und folgenden Weg gehen

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

wambacher wrote:

- Wiki-Seite öffnen (Html-Seiten sind XML-Seiten!)

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).

woodpeck wrote:

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.

Klar, ist eigentlich fast so schlimm wie die von mir ach so "geliebten" Sammelrelationen.

Ich bin ja ein "Fan" einer auf UUID Version 4 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.

woodpeck wrote:

wambacher wrote:

Ich würde einen XML-Parser für die Programmiersprache deiner Wahl nehmen und folgenden Weg gehen

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

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 ...

... Aber ein Link zu einer relation sagt einfach mehr aus als wenn man sagt such dir mal ein passendes Beispiel. ...

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 :-)

viw wrote:

Wie kann man denn OSM Objekte sinnvoll verlinken, wenn es nicht die ID ist?

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.

wambacher wrote:

indem man ihm eine UUID verpasst. Die bleibt, auch wenn sich die osm-id ändert.

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.

Ich sehe nicht, wie UUIDs diese Probleme lösen würden. Beim Aufspalten eines Weges müßten O und P (oder P und Q) dieselbe UUID erhalten, um anzuzeigen, daß sie gemeinsam Nachfolger von O sind - das widerspricht aber dem "unique", scheidet also aus. Bei der Übertragung von Eigenschaften müßte der Editor diesen Vorgang als solchen erkennen - was nicht ganz einfach ist, da Kopieren und Einfügen von Merkmalen auch nur ein Zwischenschritt sein kann, und auch OSM-Objekte mit identischen Eigenschaften, etwa dingens=hundekacktütenspender, nicht dasselbe reale Objekt darstellen müssen, sondern bloß ähnliche/gleichartige Objekte - und dann auch die UUID übertragen (bei "einfachem" Kopieren von Merkmalen/Objekten dagegen nicht). Beim Zusammenfügen von Wegen müßte der "lange" Weg die UUIDs beider "kurzen" Wege erben; das wäre wahrscheinlich noch das kleinste Problem.

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:.*.

viw wrote:

Ganz ehrlich? Das ist ein Schlüssel den ich jederzeit ändern oder löschen kann. Wie soll dieser dazu dienen das Ding wiederzufinden?

Ich frage meine DB und ihr könnt die Overpass nehmen - ob oder wann WIKI Overpass kann, ist mir allerdings nicht bekannt.

Außerdem ist nicht sichergestellt das nicht ein zweites Objekt diese ID trägt. Das ist bei OSM-IDs schonmal sicher.

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

wambacher wrote:

viw wrote:

Ganz ehrlich? Das ist ein Schlüssel den ich jederzeit ändern oder löschen kann. Wie soll dieser dazu dienen das Ding wiederzufinden?

Ich frage meine DB und ihr könnt die Overpass nehmen - ob oder wann WIKI Overpass kann, ist mir allerdings nicht bekannt.

Das ist aber leider nur die halbe Wahrheit. Da der Schlüssel jederzeit änderbar ist und damit die Links auch wieder unbrauchbar werden.

wambacher wrote:

Außerdem ist nicht sichergestellt das nicht ein zweites Objekt diese ID trägt. Das ist bei OSM-IDs schonmal sicher.

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.

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.

wambacher wrote:

ob oder wann WIKI Overpass kann, ist mir allerdings nicht bekannt.

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.

Der Link: http://overpass-turbo.eu/map.html?Q=%3C … t%3E%0A%0A

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

viw wrote:

Das ist aber leider nur die halbe Wahrheit. Da der Schlüssel jederzeit änderbar ist und damit die Links auch wieder unbrauchbar werden.

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.

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.

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.

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, 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.

Das Ganze ist also mindest genauso anfällig wie die OSM-ID.

Kann aber jederzeit von jedem gefixt werden.

Vorschläge außer "nein, geht nicht"?

streckenkundler wrote:

Ich habe dazu die Funktion "teilen" benutzt. Es gibt aber sicher noch eine elegantere Lösung.

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

wambacher wrote:

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 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.

wambacher wrote:

viw wrote:

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, 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.

Lieber wambacher. Ich habe einfach einmal einen Blick in das Proposal geworfen:
http://wiki.openstreetmap.org/wiki/Prop … ID_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.

wambacher wrote:

Das Ganze ist also mindest genauso anfällig wie die OSM-ID.

Kann aber jederzeit von jedem gefixt werden.

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/Spe … Redirects) 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>

http://overpass-turbo.eu/map.html?Q=%3C … ript%3E%0A

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

viw wrote:

Lieber wambacher. Ich habe einfach einmal einen Blick in das Proposal geworfen:
http://wiki.openstreetmap.org/wiki/Prop … ID_Tagging
was bitte sollen diese ganzen uuid tags dort bedeuten wenn nicht die von mir beschriebene herangehensweise?

total veraltetetes (2010) und nie aktiviertes Proposal. "This proposal is abandoned and the original proposer is no longer active in OSM, but this should be retained for historical purposes" Darauf Bezug zu nehmen, ist mit Verlaub ein wenig übermütig.

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.

genau da liegt der Grund für dein Mißverständnis: Das will ich überhaupt nicht.

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?

Was machst du, wenn jemand ein Objekt bei OSM löscht und das erneut mit den gleichen Informationen einträgt (z.B. um die History loszuwerden - warum auch immer) ?
---> Alle Referenzen, Links und sonstige Verweise in allen Dokumenten außerhalb von OSM ändern - was anderes bleibt dir nicht übrig.

Was machst du, wenn jemand den Tags UUID=Schlag-mich-tot ändert?

---

> setzt ihn in OSM zurück.

Such dir was aus.

Im übrigen warte ich immer noch auf konstruktive Gegenvorschäge und betrachte das Thema ansonsten hier als beendet.

wambacher wrote:

... betrachte das Thema ansonsten hier als beendet.

Ich weiß nicht, ob Du das Posting übersehen oder nur ignoriert hast, aber ich hatte oben um eine etwas ausführlichere Erklärung gebeten, wie Du Dir UUIDs in OSM vorstellst, und auch schon typische Fälle skizziert, in denen die Verlinkung per OSM-ID scheitert. Mich würde interessieren, inwiefern Deine Idee von UUIDs diese Probleme löst. Wie/wann/von wem sollen UUIDs vergeben werden, wie sollen Editoren in den damit umgehen, speziell in den oben benannten Bearbeitungsvorgängen?

Zum Verlinken von Objekten im Wiki per Overpass API hat Roland die Lösung Permanent ID implementiert. Objekte werden dabei über eine eindeutige Tag-Kombination referenziert, z.b. ref + network.

Beispiel aus dem Wiki: aus dem Template DisplayRoute:

{{DisplayRoute|network=BAB|ref=A␣555}}

wird dieser Overpass API Link generiert:
http://overpass-api.de/api/interpreter?data=[out:custom];rel[network="BAB"][ref="A+555"];out;
und nach ID-Auflösung zu osm.org weitergeleitet.

Bei mehreren Ergebnissen wird eine Link-Liste generiert, das funktioniert aber im Moment nicht (ist gemeldet).

Gruß,
Norbert

Edit: Link-Liste geht wieder

ikonor wrote:

Zum Verlinken von Objekten im Wiki per Overpass API hat Roland die Lösung Permanent ID implementiert. Objekte werden dabei über eine eindeutige Tag-Kombination referenziert, z.b. ref + network.

Cool... Kurz und Schmerzlos...

http://overpass-api.de/api/interpreter?data=[out:custom];rel[operator="Land+Brandenburg"][ref="L+44"];out;

Liefert die L 44 und Brandenburg...

Irgendwo ist aber noch ein Bug, oder?
Wieso bekomme ich hier: zwei Straßen, eine in BW

{{DisplayRoute|operator=Landkreis␣Dahme-Spreewald|ref=K␣6101}}

und hier die, die ich will.

{{DisplayRoute|network=LDS|ref=K␣6101}}

Das Tag "network=LDS hab ich nur für diesen Test eingefügt, nehme es später wieder raus.

Beide Links stehen unter: http://wiki.openstreetmap.org/wiki/Land … ra.C3.9Fen im Bemerkungsfeld.

ikonor wrote:

Zum Verlinken von Objekten im Wiki per Overpass API hat Roland die Lösung Permanent ID implementiert. Objekte werden dabei über eine eindeutige Tag-Kombination referenziert, z.b. ref + network.

Cool... Kurz und Schmerzlos...

http://overpass-api.de/api/interpreter?data=[out:custom];rel[operator="Land+Brandenburg"][ref="L+44"];out;

Liefert die L 44 und Brandenburg...

Irgendwo ist aber noch ein Bug, oder?
Wieso bekomme ich hier: zwei Straßen, eine in BW

{{DisplayRoute|operator=Landkreis␣Dahme-Spreewald|ref=K␣6101}}

und hier die, die ich will.

{{DisplayRoute|network=LDS|ref=K␣6101}}

Das Tag "network=LDS hab ich nur für diesen Test eingefügt, nehme es später wieder raus.

Beide Links stehen unter: http://wiki.openstreetmap.org/wiki/Land … ra.C3.9Fen im Bemerkungsfeld.

Edit: funktioniert das nicht mit operator??

Sven

streckenkundler wrote:

Edit: funktioniert das nicht mit operator??

Im Wiki-Template Quelltext steht mal nix von operator drin, wird also nicht so klappen:

Link (Achtung: öffnet Template im Edit Mode, nicht speichern!): http://wiki.openstreetmap.org/w/index.p … ction=edit

Oli-Wan wrote:

wambacher wrote:

... betrachte das Thema ansonsten hier als beendet.

Ich weiß nicht, ob Du das Posting übersehen oder nur ignoriert hast, aber ich hatte oben um eine etwas ausführlichere Erklärung gebeten, wie Du Dir UUIDs in OSM vorstellst, und auch schon typische Fälle skizziert, in denen die Verlinkung per OSM-ID scheitert. Mich würde interessieren, inwiefern Deine Idee von UUIDs diese Probleme löst. Wie/wann/von wem sollen UUIDs vergeben werden, wie sollen Editoren in den damit umgehen, speziell in den oben benannten Bearbeitungsvorgängen?

glatt übersehen. Sorry. Melde mich spätesten morgen wieder - ist ja nicht lang hin 😉

Gruss
walter

couchmapper wrote:

Im Wiki-Template Quelltext steht mal nix von operator drin, wird also nicht so klappen:

Ah... Ok... kann ich mit Leben... Als Netzwerk=Kreisstraßen Dahme-Spreewald eintragen... Da fällt mir ja ein, wo das Tagging (eigentlich) falsch ist...

Bei dem Operator-Tag*) der Bundes- und Landesstraßen muß eigentlich der jeweilige Landesbetrieb für Straßenwesen (oder ähnliche Bezeichnungen) eingetragen werden. In den Netzwerk Tag dann jeweils Bundesstraßen xy, Landesstraßen xy.. Kreisstraßen xy... (vgl. Beitrag http://forum.openstreetmap.org/viewtopi … 90#p389790

• ) was wiederum voraussetzt, daß Bundesstraßen an Ländergrenzen segmentiert werden...
  

Danke für die Hilfe,

Sven

Oli-Wan wrote:

wambacher wrote:

indem man ihm eine UUID verpasst. Die bleibt, auch wenn sich die osm-id ändert.

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.

Ich versuche es mal, aber es ist nicht so, daß ich eine schlüsselfertige Lösung habe.

Soll die UUID in ein Tag geschrieben oder als zusätzliches Merkmal wie ID, Version etc. gespeichert werden?

Mit schwebte ein einfacher Tag vor. Als zusätzliches Merkmal müsste die DB mit allem Drum und Dran (API 0.7) geändert werden und das würde auch nicht bringen: Objekt gelöscht - Daten futsch. Es sei denn, man gibt dem neuen Objekt irgendwie die alte UUID.

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.

Klarstellung: Ich habe das nicht vorgeschlagen um jedes Objekt bis runter auf Node-Ebene mit einer lebenslangen - genauer genommen überlebenslangen - Kennung zu versehen, die dann automatisch von allen OSM-Komponente respektiert wird. Das war und ist nicht mein Anliegen. Ich wollte lediglich "wichtigen" Objekten eine 2. eindeutige Kennung geben können.

• Das gemeinsame Objekt würde den Tag uuid=xxx behalten, wenn der Mapper das nicht verhindert
• stimmt
• 3 ist von dir falsch gedeutet: beide Ways hätten dann die selbe uuid, was noch schlimmer wäre
• Das Aufspalten eines UUID-ten Objektes ist immer problematisch.
• gebont. zur 1111111 siehe unten
• Da ist der Mapper bereits jetzt gefordert. Wenn ich z.B. die Adressdaten eines Buildings an einen Entrance-Node kopiere, weil sie manchmal da besser hinpassen, muß ich selbstverständlich dran denken, building=yes oder irgendwelche 3d-Tags vom Ziel zu entfernen.

Ich sehe nicht, wie UUIDs diese Probleme lösen würden. Beim Aufspalten eines Weges müßten O und P (oder P und Q) dieselbe UUID erhalten, um anzuzeigen, daß sie gemeinsam Nachfolger von O sind - das widerspricht aber dem "unique", scheidet also aus. Bei der Übertragung von Eigenschaften müßte der Editor diesen Vorgang als solchen erkennen - was nicht ganz einfach ist, da Kopieren und Einfügen von Merkmalen auch nur ein Zwischenschritt sein kann, und auch OSM-Objekte mit identischen Eigenschaften, etwa dingens=hundekacktütenspender, nicht dasselbe reale Objekt darstellen müssen, sondern bloß ähnliche/gleichartige Objekte - und dann auch die UUID übertragen (bei "einfachem" Kopieren von Merkmalen/Objekten dagegen nicht). Beim Zusammenfügen von Wegen müßte der "lange" Weg die UUIDs beider "kurzen" Wege erben; das wäre wahrscheinlich noch das kleinste Problem.

Viele dieser Aktionen machen aber auch dann Probleme, wenn jemand die OSM-ID in seinen Dokumenten (Wiki, Webseite, Report, ...) verwendet. Diese Probleme sind mMn nicht auf den uuid-Tag beschränkt.

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,...

Klar, aber hier hat derjenige, der diesen Identifier braucht eine reelle Chance das wieder hinzubiegen. Mit OSM-IDs geht das nicht mehr - die sind verbrannt.

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:.*.

ok, da ist was dran. Ist aber wohl so ähnlich wie mit den TMC-Tags. Keiner kennt sie, sind verd... kompliziert und keiner traute sich ran. Dann springen auch noch die Anwender ab und das war es dann.

ach ja, irgendwo hast du geflagt, wer die uuids vergibt: der interessierte Mapper selber. Es gibt für jede Plattform entsprechende Pogramme. In Linux z.B. uuidgen; Microsoft kennt und nutzt das natürlich auch.

walter@wno-server:~/osm/qgis$␣uuidgen
da7b4de1-4c68-40ca-9735-53e559fcce54
uuidgen
91759290-1a61-43b4-9aac-e55f8e79b5a7
...
...

Gruss
walter

ps: was ist denn mit "meiner" 1111111? Die beschreibt doch immer noch die Grenze von Deutschland als Liste von mehrere Multilinestrings? Welchen Link meinst du denn? Dann schau ich mir den mal an.
Das "Entführen" von Objekten mit besondere OSM-ID kenne ich ja von Steve's Node °1 aber doch nicht von r1111111. Da achte ich schon ein wenig drauf, hat schließlich einige Mühe gekostet, die zu bekommen 😉

-snip- war nix

-snip- war auch nix 🙁

Wie soll das bei Wanderwegen funktionieren - da sind die valide "ffreier" !

Jan

streckenkundler wrote:

Irgendwo ist aber noch ein Bug, oder?
Wieso bekomme ich hier: zwei Straßen, eine in BW

{{DisplayRoute|operator=Landkreis␣Dahme-Spreewald|ref=K␣6101}}

Auf http://wiki.openstreetmap.org/wiki/Temp … splayRoute habe ich das Template angepasst,
so dass auch obiger Link jetzt funktioniert.
Auf die gleiche Weise können von mir aus auch gerne weitere Kriterien dazukommen.

Lübeck wrote:

Wie soll das bei Wanderwegen funktionieren - da sind die valide "ffreier" !

Die Permanent ID könnte z.B. bei Straßen- und Buslinien-Relationen gut funktionieren, bei Wanderwegen ist das sicher schwieriger oder gar nicht anwendbar.

Ich hab mich aber gerade bei Wanderrouten schon gefragt, warum die überhaupt im Wiki aufgelistet sein müssen. Viel schöner fände ich es, wenn man sich über die Overpass API eine Liste dynamisch generieren könnte, z.B. nach Operator oder nach Gebiet. Konkret stelle mir da eine Tabelle als dritten Tab im Overpass Turbo vor. Die Spalten der Tabelle könnte man entweder als Parameter übergeben oder anhand der vorhandenen Tags im Ergebnis dynamisch erzeugen.

Man müsste dann aber die im Wiki gepflegten Meta-Informationen wie Status, "zu prüfen" und Kommentar (note) als Tags an die Relation hängen. Wobei man solche Meta-Informationen eher nicht in der Datenbank haben möchte, oder? Bei vollständigen Relationen könnte man diese Infos ja aber dann entfernen. Allenfalls noch gar nicht erfasste Routen würden als ToDo-Liste noch im Wiki bleiben, da man sonst leere Relationen ohne geographischen Bezug anlegen müsste.

Was meint ihr?

Gruß,
Norbert

Danke Walter, manches ist nun klarer geworden. Richtig überzeugt bin ich aber ehrlich gesagt nicht.

Vorweg: Ich weiß nicht, ob Du meine Aufzählung vielleicht ein wenig mißverstanden hast: ich habe einige Fälle aufgeführt, in denen die "Lösung" mit OSM-IDs nicht funktioniert, und wollte unvoreingenommen wissen, wie sich UUIDs in diesen Fällen nach Deiner Vorstellung schlagen - nicht im Voraus behaupten, daß diese auch nicht helfen.

Noch einmal zu einigen der numerierten Punkte:
ad 1. Was, wenn vor dem Zusammenfügen beide Ausgangswege eine uuid=* hatten? Bei Bearbeitungen mit unserem geliebten Potlatch geht unweigerlich eine verloren, bei JOSM hängt es vom Nutzer ab. Aber im Idealfall steht im neuen Objekt uuid=xxx;yyy. Dann könnte das Objekt zwar noch unter beiden UUIDs gefunden werden, aber nicht mehr per einfachem Key/Value-Vergleich, sondern man müßte schon nach Substrings suchen, bzw. bei der Overpass API per Regex.
ad 3./4. Wenn das Aufspalten grundsätzlich problematisch ist, muß der Editor eine klare Vorgehensweise beherrschen bzw. eine Handlungsempfehlung an den Nutzer geben. Wie soll diese aussehen? Ich kann mir nicht vorstellen, wie per Algorithmus auch nur einigermaßen zuverlässig entschieden werden kann, welches der Tochterobjekte nun das "bedeutsame" ist, welches die UUID behalten soll.

Meines Erachtens steht schon die Verwendung von UUIDs in OSM (mit seiner Arbeitsweise) im Widerspruch zum UUID-Konzept. UUIDs sollen eindeutig sein, daher werden sie (in anderem Zusammenhang) für jedes Objekt automatisch vergeben, und zwar so, daß zwei Objekte (praktisch) nie dieselbe UUID bekommen. Tags in OSM sind im allgemeinen nicht eindeutig (etwa name=Bahnhofstraße); und selbst wenn man initial eindeutige Werte vergibt, kann (lies: wird) etwa durch Kopieren von Objekten oder Merkmalen sowie Aufspalten von Wegen die Eindeutigkeit verloren gehen. Die schon genannten AND_nosr_r-Tags (sowie AND_nosr_p und AND_nodes) waren ursprünglich wohl mal dazu gedacht, ein Import-Update durchführen zu können. Es gab sicher auch noch andere Gründe, warum es dazu nie gekommen ist, aber den Objekten mit diesen Tags sind genau die oben aufgeführten Bearbeitungen widerfahren, die sie zur Identifizierung unbrauchbar gemacht haben.

Ein weiteres Problem hast Du schon selbst angesprochen: kryptische Tags. Den zur eindeutigen Identifizierung gedachten Tags von AND, TMC, openGeoDB et al. ist gemein, daß "der normale Mapper" sie nicht versteht (bzw. mangels Dokumentation nicht einmal eine Chance dazu hat). Eine bessere Dokumentation wäre zwar möglich, dennoch würde es UUIDs m.E. ähnlich ergehen. Selbst ein fortgeschrittener "normaler Mapper" (ganz zu schweigen von einem Anfänger) braucht sie in der Regel nicht, noch dazu sind UUIDs nicht unbedingt ein intuitives Alltagskonzept, das jeder sofort versteht. Also würden sie bei Bearbeitungen einfach links liegen gelassen, was genau falsch sein kann. Oder gelöscht, was (außer nach dem Kopieren) immer falsch ist.

Allerdings sehe ich auch keinen Weg, die Tags weniger kryptisch zu formulieren. uuid=* ist für "Uneingeweihte" unverständlich, aber mit einem furchtbar langen (dafür erklärenden) Schlüssel ("this_object_has_the_following_unique_identifier_please_edit_carefully"=*) ist niemandem gedient (würde noch nicht einmal helfen, da viele Leute bei OSM des Englischen nicht hinreichend mächtig sind). Aber auch ein Wert wie uuid="da7b4de1-4c68-40ca-9735-53e559fcce54" sieht erst einmal wie Bitmüll aus und ist schon deswegen in Löschgefahr.

wambacher wrote:

ps: was ist denn mit "meiner" 1111111?

War nur von allen denkbaren Beispielen für eine komplette Umdeutung das, welches Dir am besten vertraut sein dürfte. Es wäre ja theoretisch möglich, daß die Relation vorher ebenfalls für ein "bedeutsames" Objekt stand.

ikonor wrote:

Man müsste dann aber die im Wiki gepflegten Meta-Informationen wie Status, "zu prüfen" und Kommentar (note) als Tags an die Relation hängen. Wobei man solche Meta-Informationen eher nicht in der Datenbank haben möchte, oder? Bei vollständigen Relationen könnte man diese Infos ja aber dann entfernen. Allenfalls noch gar nicht erfasste Routen würden als ToDo-Liste noch im Wiki bleiben, da man sonst leere Relationen ohne geographischen Bezug anlegen müsste.

Was meint ihr?

Da trffst du bei mir voll ins Auge; genau das ist meine Intention bei dieser ganzen leidigen Diskussion:

warum immer wieder manuell irgendwelche Tabellen im Wiki pflegen, wo die Daten dazu doch in der OSM-DB liegen oder liegen könnten?

Hast du zufälligerweise den aktuellen Thread Bundestraßen und deren Routing verfolgt? Da hab ich das bereits angeregt (tag: checked=*). Der wird benutzt und auch ausgewertet - aus technischen Gründen aber leider noch nicht im Wiki.

Gruss
walter

Ich möchte natürlich jetzt nicht anregen, jeden Pups in die DB zu klopfen aber note, description oder während eines Projektes "checked" sollte doch wohl drin sein.

Oli-Wan wrote:

Danke Walter, manches ist nun klarer geworden. Richtig überzeugt bin ich aber ehrlich gesagt nicht.

ich auch nicht mehr. Die Probleme beim Editieren UUID-ter Objekte sind so mannigfaltig, daß das wirklich keinen Sinn - auch für mich - macht.
Schade. Bleibt nur die Hoffnung auf Api 0.8, denn in 0.7 kommt das sicher nicht rein - wann immer es die mal geben sollte.

wambacher wrote:

ps: was ist denn mit "meiner" 1111111?

War nur von allen denkbaren Beispielen für eine komplette Umdeutung das, welches Dir am besten vertraut sein dürfte. Es wäre ja theoretisch möglich, daß die Relation vorher ebenfalls für ein "bedeutsames" Objekt stand.

Ne ne, die ist ab Version 1 nie was anderes gewesen. Hatte eines Nachts gemerkt, daß die Id bald vergeben wird und in daher in den letzten Sekunden vorher 3-4 neue Rels angelegt - und Glück gehabt. Ist zwar nicht die feine Art aber jetzt kann ich das wohl beichten 😉

So, jetzt geht ich mal uuid begraben und warte auf die 0.8.

Gruss
walter

wambacher wrote:

Hast du zufälligerweise den aktuellen Thread Bundestraßen und deren Routing verfolgt? Da hab ich das bereits angeregt (tag: checked=*).

Den Thread hab ich nur überflogen. Für neu angelegte Relationen, die nach dem Vier-Augen-Prinzip von einem Zweiten überprüft werden sollen (z.B. das "überprüft von" bei Autobahnen), hätte ich die Logik analog zu einem Fixme Tag eher umgedreht: der Erfasser fügt das Tag hinzu (fixme:check=yes, to_be_checked=yes oder so) und der Prüfende entfernt es wieder, User und Datum sind durch das Changeset definiert. Hätte den Vorteil, dass nach Abschluss des Erfassungs-/Bearbeitungs-Prozesses die dazu benötigten Meta-Informationen wieder entfernt werden können.

ikonor wrote:

User und Datum sind durch das Changeset definiert. Hätte den Vorteil, dass nach Abschluss des Erfassungs-/Bearbeitungs-Prozesses die dazu benötigten Meta-Informationen wieder entfernt werden können.

Tags können von automatischen Auswertungen halt viel einfacher gelesen werden als die History.
Die checked-Tags können nach (überwiegender) Durchführung des Projektes auch in der jetzigen Form entfernt werden.

ikonor wrote:

Den Thread hab ich nur überflogen.

Mach ich bei anderen genauso - obwohl mich Netzwolf dafür ja bedauert 😉

Für neu angelegte Relationen, die nach dem Vier-Augen-Prinzip von einem Zweiten überprüft werden sollen (z.B. das "überprüft von" bei Autobahnen), hätte ich die Logik analog zu einem Fixme Tag eher umgedreht: der Erfasser fügt das Tag hinzu (fixme:check=yes, to_be_checked=yes oder so) und der Prüfende entfernt es wieder, User und Datum sind durch das Changeset definiert. Hätte den Vorteil, dass nach Abschluss des Erfassungs-/Bearbeitungs-Prozesses die dazu benötigten Meta-Informationen wieder entfernt werden können.

Das war vor ein paar Tagen ein Schnellschuß mit der Option, den Namen und die Bedeutung von checked=* noch anzupassen. Insofern würde ich das nicht so eng sehen.

Derzeit bedeutet das in etwa "Ich, ..., hab mir das zuletzt ... angesehen und da war wohl alles ok" Das dann in dieser kleinen Grafik mit ausgewertet und dann weiss jeder, wo noch was zu tun ist - und das fast ohne Wiki 😉

Gruß
walter

seichter wrote:

ikonor wrote:

User und Datum sind durch das Changeset definiert. Hätte den Vorteil, dass nach Abschluss des Erfassungs-/Bearbeitungs-Prozesses die dazu benötigten Meta-Informationen wieder entfernt werden können.

Tags können von automatischen Auswertungen halt viel einfacher gelesen werden als die History.
Die checked-Tags können nach (überwiegender) Durchführung des Projektes auch in der jetzigen Form entfernt werden.

Wer wann geprüft/bearbeitet hat ist aber vermutlich eher nur bei Einzelfällen, z.B. bei Unstimmigkeiten, interessant. Für automatische Auswertungen wären ja gerade die Objekte, die noch ein "zu prüfen" Tag haben, relevant. Was in der Praxis besser funktioniert weiß ich nicht. Für Mapping-Aktionen an vorhandenen Objekten wie bei den Bundesstraßen ist das checked Tag vermutlich schon die bessere Variante.