Wie fehlende DHID verzeichnen?

Communities Deutschland (Germany)
1

Hey :slight_smile:

Als Teil meiner Tätigkeit übertrage ich die Deutsche Haltestellen-ID (DHID) aus dem Deutschen Haltestellen-Verzeichnis (DHV) in OSM. Diese Verknüpfung erfolgt über den Schlüssel ref:IFOPT. Nun bin ich auf ein Problem gestoßen, für das ich keinen Präzedenzfall in OSM finden konnte und wollte wissen wie ihr es lösen würde bzw. was ihr von meiner Lösung haltet.

Es gibt Haltestellen, die haben keine DHID. Wie verzeichne ich das?

Der Hintergrund ist: Ich möchte natürlich zu QA-Zwecken aber auch als ganz normalen Teil der Daten gerne Verzeichnen können, dass ich überprüft habe, was die die DHID einer Plattform ist, und festgestellt habe, dass es keine gibt.

Ich weiß, es gibt immer viele Diskussionen darüber, ob und wie man verzeichnet, dass etwas nicht existiert.

Es gibt zum Beispiel opening_hours:signed=no, name:signed=no etc., die zeigen dass ein bestimmter Umstand nicht ausgeschildert ist. Also warum nicht ref:IFOPT:signed=no? Die DHID ist leider nicht “Ausgeschildert” an der Haltestelle, weswegen ich signed für keinen guten Ausdruck halte.

Ich dachte an ref:IFOPT:given=no, ref:IFOPT:exists=no oder ähnliches, aber konnte keine Präzedenz finden, weil normalerweise verzeichnen wir ja nichts in OSM, was nicht vor Ort ersichtlich ist.

Ich möchte noch erwähnen, dass durch einen solchen Schlüssel kein Spam entstehen würde, wir sprechen meiner Erfahrung nach von <1% aller Haltestellen, die keine DHID/IFOPT haben. Für diese kleine Menge ist mir aber halt wichtig, dass ich irgendwie verzeichnen möchte “Nein, hier fehlt nichts. Diese Haltestelle hat keine DHID”

Meine Lösung, die ich bis jetzt verwende ist check_date:ref:IFOPT=[Datum] und dann keinen ref:IFOPT-Schlüssel. Damit sage ich: “Ich habe am [Datum] überprüft, dass die derzeitige Erfassung von ref:IFOPT (also: Es gibt keine) richtig ist.”

Was haltet ihr davon? Habt ihr andere Ideen?

2

Spricht was gegen ref:IFOPT=none ?

3

Gegen ref:IFOPT=none spricht, dass ein Key ref:xxx eigentlich immer nur die “ref[:xxx]” als Value haben sollte, niemals aber etwas anderes.

Ich weiß, diese Sichtweise ist diskutabel.

Nur deswegen haben wir halt
maxweight:signed=no, wenn kein maxweight ausgeschildert ist (“no” ist keine Gewichtsbeschränkung)
ref:signed=no, wenn man eine ref erwarten würde, aber keine ausgeschildert ist (“no” ist keine ref)
opening_hours:signed=no, wenn man Öffnungszeiten erwarten würde, aber keine ausgeschildert sind (“not_signed” sind keine Öffnungszeiten)
de:strassenschluessel:exists=no, wenn man einen Straßenschlüssel erwarten würde, es aber keinen gibt (“none” ist kein Straßenschlüssel).

Natürlich gibt es auch Gegenbeispiele (maxspeed=none z. B. ).

Das Beispiel mit de:strassenschluessel:exists=no kommt dem Ganzen denke ich am nächsten.
Ich würde daher definitiv zum Sub-Key ‘exists’ tendieren.

Zumal ein Straßenschlüssel zumindest ungefähr vergleichbar ist mit einer IFOPT-Nummer für Haltestellen, von daher würde das wirklich 1 A ins Schema passen.

1 Like
4

Ha ha ha, habe ich an der Stelle gelacht :joy:

Nein Spaß, du hast Recht – ist nicht böse gemeint, bitte nicht falsch verstehen :sweat_smile:

5

wenn man sicher ist dass ein x nicht vergeben wurde, ist ein Schema nox=yes, zB. noname=yes
nohousenumber=yes

1 Like
6

Spricht was gegen ref:IFOPT=none ?

dass “none” kein ref:IFOPT ist? Dass “none” theoretisch ein solches sein könnte?

1 Like
7

Ja, entweder das oder eben wie gesagt xxx:exists=no.

norefIFOPT=yes halte ich irgendwie für einen ein bisschen “unübersichtlichen” Key, ist aber Geschmackssache.

8

Nur wenn langfristig gesichert ist, dass Objekt A nicht im zuständigen Kataster x auftauchen wird (z.B. wg. spezieller Typologie), reicht imho sowas wie
ref:[Kataster x]:exists=no

wenn dagegen die Möglichkeit besteht, dass Objekt A zukünftig doch in Kataster x auftauchen wird (Kataster-update), würde ich auf das zusätzliche
check_date:ref:[Kataster x]=[yyyy-mm-dd]
keinesfalls verzichten, oder aber das Veröffentlichungsdatum des Katasters mitnotieren
source:ref:[Kataster x] =[freitext yyyy-mm-dd]

1 Like
9

Ah! Von de:strassenschluessel:exists=no hatte ich noch nichts gehört. Das passt wirklich perfekt!

1 Like
10

Das scheint mir tatsächlich die beste Lösung zu sein. :slight_smile:

Bei vielen Haltestellen ist die Situation so, dass ich mir relativ Sicher bin dass es irgendwann eine DHID geben wird (Neubau etc.).

1 Like
11

diesen Key gibt es nicht und hat es noch nie gegeben, was es knapp 2000 mal gibt ist “de:strassenschluessel_exists”
https://taginfo.openstreetmap.org/keys/de%3Astrassenschluessel_exists

da man offenbar sowieso den Schlüssel nachsehen muss, weil jeder tag eine eigene Systematik erfindet, könnte man genausogut de:nostrassenschluessel verwenden.
Etwas komisch die “de” Vorsilbe, müsste das nicht entweder einfach “strassenschluessel” sein, oder “DE:strassenschluessel” (in Deutschland)? Oder DE:Straßenschlüssel bzw. dann DE:keinStraßenschlüssel oder auch DE:kein_Straßenschlüssel
Das verstehen dann zwar die nicht-deutschsprechenden nicht ohne Übersetzer, aber das Interesse dürfte sowieso sehr überschaubar sein.

13

Sorry, hab mich vertan

1 Like
14

Puh, ehrlich gesagt keine Ahnung, wer genau “Verwalter” dieser Straßenschlüssel-Sache ist…

wobei “de:strassenschluessel” schon zusammen gehört und man aber offenbar nicht den ganzen Key auf deutsch machen wollte… Na ja.

Aber es ging ja auch primär um das [xxx]:exists=no

Ob da jetzt ref:IFOPT:exists oder ref:IFOPT_exists besser ist, tja.

Nur bei ref:IFOPT wird der Doppelpunkt bereits verwendet, daher wäre es vlt. sinnvoll, den ggf. ein zweites Mal zu verwenden statt eines möglichen Unterstriches. Müsste man schauen :man_shrugging:

@wielandb-paid
Vielleicht wäre es eine sinnvolle Idee, deine Entscheidung für einen Key für diese Angabe (bzw. sobald du eine Entscheidung getroffen hast) noch im Wiki unter ref:IFOPT zu dokumentieren?

Zumindest, dass es diesen entsprechenden neuen Key dann gibt, weiß nicht, vlt. könnten auch andere Mapper, die mit diesem Thema beschäftigt sind, davon profitieren. (Ich kenne ihn nicht persönlich, aber mir fällt da irgendwie @alan1209 ein). Er ist ebenfalls sehr mit diesem Bushaltestellen-Thema beschäftigt.

15

s. (leicht OT) zu de:strassenschluessel auch
https://wiki.openstreetmap.org/wiki/DE:Key:de:regionalschluessel
https://wiki.openstreetmap.org/wiki/DE:Key:de:amtlicher%20gemeindeschluessel

… ja, das wäre wünschenswert, am besten gleich mit Redirects des gewählten Keys/Tags.

1 Like
17

Das werde machen. :slight_smile:

1 Like
18

Prima, super! :smiley:

19

Kurz nachdem ich mich für ref:IFOPT:exists=* entschieden hatte, wurde ich darauf hingewiesen, dass der key noref= wohl vielfach in benutzung ist und somit noref:IFOPT=yes eigentlich die zu bevorzugende Variante wäre. Ich habe zum Glück noch nicht zu viele Haltestellen mit ref:IFOPT:exists=no getaggt, sodass das leicht zu ändern wäre. Ich wäre geneigt lieber diesen Schlüssel zu verwenden und das ganze im Wiki auch nochmal abzuändern. Was haltet ihr davon?

20

Ach Gottchen, daran hatte ich gar nicht gedacht. Aber jaa, kann ich verstehen :slight_smile:

Von der Bedeutung her dürfte es ja das gleiche sein – es existiert keine IFOPT-Nummer.

Von daher, wenn du meinst, hätte nichts dagegen, solange man sich für einen Key entscheidet, bitte :man_shrugging:

21

Das ist natürlich ganz günstig, je jünger ein Key ist, desto eher hat man noch die Chance ihn ggf. noch möglichst vollständig abzuändern :slight_smile: