Diese Variante ist auf jeden Fall besser als die Alte/Andere, aber aus meiner Sicht immer noch nicht ganz optimal.
Eigentlich funktioniert eine Datenbank ja so: man hat seinen, für den Anwendungsfall eindeutig passenden Schlüssel, über den man dann die Daten zielgenau abrufen kann.
Mal angenommen, ich will als LKW-Fahrer das maxspeed=* für eine Straße wissen, dann kann ich je nach Modell entweder maxspeed:hgv:conditional=* als Schlüssel benutzen, wobei die Unterscheidung auf :forward/backward:conditional dann als zusätzliche Info mit im Wert stehen muß (und natürlich für den Menschen länger und damit fehleranfälliger zu erfassen ist) oder man definiert von vorn herein auch: bei der Abfrage brauch ich zwingend die Fahrtrichtung und dann ist immer maxspeed:hgv:forward:conditional= zusammen mit maxspeed:hgv:backward:conditional=* zu erfassen, aber in diesem Fall dann nie maxspeed:hgv:conditional=*.
Nach aktuellem Proposal kann man aber alle drei Varianten wahlweise und auch zusammen benutzen, was zum einem heißt, das man im Zweifelsfall 3x nach den gleichen Daten fragen muß statt 1x. Das ist aber noch nicht mal das Schlimmste, denn die Daten können auch noch inkonsistent sein:
maxspeed:hgv:conditional=80 @ wet
maxspeed:hgv:forward:conditional=50 @ (10:00-18:00), 60 @ wet
maxspeed:hgv:backward:conditional=60 @ (06:00-22:00), 50 @ (length>5)
Da weiß man doch immer, was korrekt ist. Das Problem gibts aber in OSM nicht nur hier, sondern noch öfter, was die Sache aber nicht wirklich besser macht, aber andererseits seh ich die Mapper schon über noch mehr vermeintlich nutzlose und lange Tags (z.B. health_object=* (hatte ich anfänglich aber drin)), jammern…
Natürlich kann ich auch nur Daten im Key haben, die ich zum Zeitpunkt der Abfrage zweifelsfrei weiß, denn der bekannte Key soll mir ja gerade immer die Nutzdaten für den Anwendungsfall liefern, welche ich nicht weis. Da will ich keine Schlüsselratespiele veranstalten müssen.
So, das erst mal als Hinweise von mir zum Proposal.