Gefiltererte und "ge-aliaste" Osm-Tag Liste irgendwo?

Communities Deutschland (Germany)
1

Ich stehe vor folgendem Problem:

ich will für BRouter die Lookup-Tabelle erweitern, nachdem ich es geschafft habe, die Datenstruktur so zu dynaminiseren, dass ich kein Limit auf die Zahl der zu kodierenden Tags mehr habe.

Das ist einerseits eine coole Sache, weil ich in Zukunft einfach ALLE Tags mit abzählbarem Wertebereich kodieren kann.

Andererseits aber auch eine Mammutaufgabe, weil man nicht einfach das nehmen kann, was man bei TagInfo sieht (oder was ich auch selber scannen kann) und in eine Tabelle giessen. Einerseits wäre diese Tabelle viel zu gross (sooo dynamisch ist meine Datenstruktur dann doch noch nicht), andererseits braucht es einfach ein sinnvolles “Aliasing”, um Werte gleicher oder fast gleicher Bedeutung schon im Vorfeld zu bündeln, sonst würden die Profil-Skripte zu umfangreich.

Beispiele: oneway = yes = true = YES
bicycle = use_cycleway = use_sidepath
bicylce = designated = official

Noch schwieriger wird es bei quasi-kontinurlichen Tags (maxspeed, incline, maxheight, maxwidth), da sind einerseits krumme Werte drin und andererseits auch Einheiten gemischt.

Und jetzt denke ich mir: das muss es doch schon geben, ich bin doch nicht der einzige, der Routing auf diesen Daten machen will. Irgendwie feht mir da ein strukturiertes Vorgehen, um jetzt nicht einfach nur irgendeine Auswahl zu treffen, sondern bisschen systematischer vorzugehen. Glaube man darf da auch nicht einfach nach der Häufigkeit gehen, “use_sidepath” ist z.B. noch ein ganz zartes Pflänzchen, aber ja eine der Gründe warum ich Arbeit in die Erweiterung stecke, andererseits gibts wohl auch Tags mit regionaler Bedeutung (4wd_only im australischen Outback?), die dort den Leuten aber wichtig sind, die aber in einer weltweiten Tag-Statistik jetzt auch nicht unbedingt auffallen.

Ich möchte mit der neuen Version der Lookup-Tabelle möglichst wenig Anwendungen ausschliessen, wheelchair oder horse routing zum Beispiel nicht, aber auch welche, die ich garnicht kenne. Ich fürchte aber, man muss da im Einzelfall Domain-Knowledge einbringen, um die Tag/Value Auswahl und das Aliasing machen zu können?

Kann mir da jemand Tipps geben?

Danke und Gruss, Arndt

2

Ich kann mal aufzählen, was ich fürs Fußgängerrouting in Wald und Wiese auswerte. Willkürlich zusammengesammelt, was mir halt so in den Daten auffiel:

highway
motorroad
access und foot
man_made, wegen man_made=pier
route, wegen route=ferry
sidewalk, weil ein highway=primary besser bewertet wird, wen er einen Bürgersteig hat
footway, weil in einigen Gegenden sidewalk und footway lustig wechseln
sac_scale
trail_visibility
obstacle
via_ferrata_scale

De Mitgliedschaft in Wanderrelationen. Hilft dabei die gemeine Forststraße von der häufig schöneren Fernwanderwegforststraße zu unterscheiden.

Kontinuierliche Tags habe ich gar keine.

barrier wird auch ausgewertet, aber nur beim Import, danach ist da einfach eine Lücke im Weg.

“railway” hab ich noch in der Defaultkonfiguration meines Importprogramms gefunden (osm2po). Bei den Routerherstellern müsste eigentlich was zu holen sein, die liefern ja oft ein Importprogramm mit Beispielkonfiguration aus.

Grüße, Max

PS: diese ganzen der-tag-gilt-doch-nicht-Tags vielleicht auch noch: disused, abandoned …

3

Eine Quelle könnten mkgmap-styles sein. Da ist auch immer ein “Aliasing” drin. Das Problem dabei ist jedoch immer, dass dieses Aliasing unter gewissen Bedingungen erfolgt. Bspw. wäre für Fahrradrouting bicycle=no, access=no und vehicle=no als identisch zu betrachten (nach StVO). Jemand, der sich für eine wassergebundene Oberfläche von Wegen interessiert, fasst surface=asphalt und surface=concrete zusammen etc. Unter dem jeweiligen Blickwinkel passt das. Unter einem anderen Blickwinkel mag das grober Unsinn sein.

4

(doppel-post bereinigt)

5

Danke für die Tipps.

Ich hab mich jetzt für eine vorsichtige Strategie entschieden, bei der ich die Tags nur handverlesen in die lookup-Tabelle schreibe, dafür aber die Kompatibiliäts-Regel flexibler gemacht habe: man kann dann die Tabelle in 3 dimensionen erweitern (neue Tags, neue Values zu bestehenden Tags und neue Aliases zu bestehenden Values) und dabei nur die “minor-Version” erhöhen, die damit berechneten Datenfiles bleiben kompatibel.

So wird die Schwelle für zukünftige Erweiterungen niedrig jund ich kann mich jetzt auf das konzentrieren, was mir einfällt. Hier die aktuelle Tabelle:

https://github.com/abrensch/brouter/blob/master/misc/profiles2/lookups.dat

Bei den access tags ist horse, wheelchair und hgv dazugekommen, das aliasing zwischen “yes” und “permissive” habe ich aufgeoben (das zwischen agricultural und forestry aber nicht) und “use_sidepath” ist dazugekommen.

An quasi-kontinurlichen Tags habe ich “maxspeed” und “incline” diskretisiert.

Bei den Relationen habe ich die Rad-Relationen einzeln aufgeschluesselt nach network-tag, und ich habe hiking, foot und mtb-Relationen dazugenommen (auch per network)

Bei Radwege-Infrastruktur noch “segregated” und “oneway:bicycle”.

Die neue Version von BRouter, die das alles kann, wird denke ich noch so 2-3 Wochen brauchen. Wenn ich wichtige Tags übersehen habe oder jemandem ganz neue Anwenduungen einfallen, für die noch weitere Tags notwendig sind, wäre ich für einen Hinweis dankbar.

Gruss, Arndt

6

Moin,

nur mal so interessehalber:

Ich persönlich würde private wie destination behandeln.
Siehst Du Gründe für die Trennung, die ich vielleicht übersehe?

Gruß
Georg

7

Bitte nicht verwechseln eine Gleichsetzung auf Ebene des Präprozessors (=Aliasing in der Lookup-Tabelle) und eine Gleichsetzung auf Ebene des Routing-Profils. Bei letzterem kann man ja trotzdem private wie destination behandeln (tue ich aber glaublich in den von mir erstellten Profilen nicht…).

Gleichsetzung über Aliasing macht nur dann Sinn, wenn man sich ziemlich sicher ist, dass man sich für den Unterschied bestimmt nicht interessiert. Der Vorteil ist, dass dann dieser Teil der Komplexität schon beim Präprozessing erschlagen ist und die Routing-Profile nicht mehr aufbläht. Der Nachteil ist aber, dass die Information dann auch wirklich weg ist.