[Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

[Wolfgang Hinsch]

Hallo,

Am Mittwoch, 12. November 2014, 09:49:45 schrieb Joachim Kast:

> 
> > ... denn von dem Network-Vorschlag  halte ich persönlich für nicht optimal
> > (Änderung eines Verwendungszweckes eines Tag's, müsste auch erst
> > ausführlich diskutiert werden).
> Es mag sein, dass network=* nicht so optimal ist, aber mir fällt
> momentan auch nichts besseres ein. Bei der Analyse der
> network-Werteverteilung [1] findet man jedoch so ein wohlgeordnetes
> kreatives Chaos, dass es auf ein network=eBusinesslotse eigentlich auch
> nicht mehr ankommt.
> 
> Ziel dieser wie auch immer aussehenden Kennzeichnung soll sein, die
> dezentral eingegebenen Daten für eine App "einzusammeln". Das könnte man
> prinzipiell auch über die Auswertung des Anfangs des Name-Tags bei einer
> einheitlichen Namensgebung machen, aber ich finde eine eigene key/value
> Kombination dennoch besser.
> 
> 
> Sollte jemand eine optimalere Lösung anstatt "network=eBusinesslotse"
> haben, dann möge er seinen Vorschlag hier bitte präsentieren.
> 

Letztlich läuft es immer wieder auf das gleiche Problem hinaus, über das seit 
mehreren Jahren diskutiert und für das immer wieder eine Lösung abgelehnt 
wurde: Eindeutige Verweise auf OSM-Daten aus anderen Datenbeständen heraus.

Alles schreit nach externen Datenbanken ("Nicht alles in OSM kippen"), aber 
eine Lösung gibt es bis heute nicht, so dass letztlich Insellösungen gebastelt 
werden, die individuell Tags festlegen, mit denen dann die Daten 
referenzierbar sein sollen. Wenn das so weiter geht, haben wir bald ein 
schönes Sammelsorium von verschiedensten Tags, für jede Anwendung ein paar.

Ich schlage daher vor, über _ein_ objektbezogenes Referenz-Tag nachzudenken, 
dass in eindeutiger Form, wo notwendig, vergeben wird und das dann jeder 
Nutzer für seine Anwendung benutzen kann.

Ich werfe mal ein Tag in den Ring:

externel_reference_id=[nwr]{derzeitige-id-Nummer}

also ein Tag, das bei Bedarf jederzeit mit den Editoren erzeugt werden kann 
und dessen Wert einfach der derzeitigen Objekt-ID entnommen wird,
also z.B. für Ways 

externel_reference_id=w1234567890

"ERID" im Folgenden

Für Relationen und Nodes eben mit n bzw. r

Ich könnte mir vorstellen, dass es ohne besonderen Aufwand möglich wäre, die 
Editoren entsprechend zu erweitern. Das Tag sollte nur vergeben werden, wenn 
tatsächllich Bedarf für eine externe Refernenz besteht, dann aber einheitlich 
von allen Interessenten nutzbar sein.

Vorteil gegenüber dem heutigen Gebastel: Ein Tag für alle und gut.
Vorteil gegenüber der ID direkt: Wird das Objekt geteilt oder verschmolzen, 
bleibt das Tag im Gegensatz zur ID erhalten, es überlebt auch eine Änderung 
des Datentyps, z.B. von Node auf Way. 

Natürlich bleiben noch Fragen. Was passiert, wenn zwei Referenzobjekte 
verschmolzen werden.

Man könnte die ERIDs dann mit Trennern aufzählen, aber das führt 
möglicherweise zu Datensalat.
Besser wäre es, wenn das neue Objekt eine eigene ERID bekommt oder eine der 
ERIDs fortführt. Die Kontinuität ist gegeben,wenn in der letzten Version der 
untergehenden ERID ein Tag mit einem Hinweis auf die Folge-ERID gesetzt wird.

Eine Abfrage nach einer Referenz muss also immer nach der ERID mit der 
maximalen Versionsnummer suchen. Steht dort ein Verweis auf die neue ERID, 
wird im Datenbestand des Nutzers der Verweis entsprechend aktualisiert und er 
sucht nach dem Datensatz mit der neuen ERID.

Letzlich also: Extern verlinkte Objekte haben 2 zusätzliche Tags (ERID und 
ERID-Version), und damit gut für alle. 

Nur für den Fall, dass der Verweis in ein anders Objekt überführt wurde 
(Verschmelzung etc.), gibt es in der letzten Version des alten Objekts ein 
extra-Tag mit einem Hinweis auf die neue ERID.

Der Vorschlag ist nicht perfekt und nicht zu Ende gedacht. Ich habe das jetzt 
nur mal so aus dem Ärmel geschüttelt, aber wenn echtes Interesse an einer 
endgültigen Lösung besteht, könnte man ein Proposal im Wiki anlegen und die 
Sache von allen Seiten beleuchten.

Gruß, Wolfgang

(der das Problem auch schon hatte)