[Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Wolfgang Hinsch
osm-listen at ivkasogis.de
Do Nov 13 17:01:16 UTC 2014
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)
Mehr Informationen über die Mailingliste Talk-de