[Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

Mi Jul 18 07:30:47 UTC 2012

Am 17.07.2012 17:52, schrieb Christian Müller:
> Am 17.07.2012 08:38, schrieb Frederik Ramm:
>> Allein schon die einfache Frage: "Ein Way, der in einer Relation 
>> steckt, wird zweigeteilt; wie wirkt sich das auf die Relation aus?" 
>> kann nicht beantwortet werden, ohne die Relation zu verstehen.
> Das sehe ich nicht so.  Fällt Dir ein Beispiel ein?
Abbiegebeschränkungen
>> Oder: "Ein Way, der in einer Relation steckt, wird geloescht. Soll 
>> die Relation mitgeloescht werden, soll sie ohne diesen Way 
>> weiterbestehen, oder muss ein Ersatz-Way in die Relation aufgenommen 
>> werden?"
> Das entscheidet der Mapper - die Software muss hiervor geeignet 
> warnen, bzw. die Auflösung dieser Fälle unterstützen.
Trotz Warnung muss der Mapper aber dann die Relation verstehen - auch 
der blutige Anfänger im Zweifelsfall eine seltene Relation, deren Sinn 
sich ihm nicht einmal erschließt.
> Weiterhin, verzichtet man auf die bbox-Methode und geht das Problem 
> mit den postal_code-boundaries an, eröffnet sich das Szenario, dass an 
> deren Grenzen eine gleichnamige Straße die postal-boundary schneidet - 
> sind das dann zwei verschiedene Straßen oder eine? Zudem müßte hierfür 
> bei der Post erfragt werden, ob Straßennamen pro postal_code per 
> Definition Post wirklich immer eindeutig sind - imho yes, aber genau 
> weiß ich das nicht.
Selbst wenn die Post davon offiziell ausgeht, berücksichtigt sie nur 
Straßen, an denen es Adressen gibt, alle anderen haben nicht einmal eine 
Postleitzahl. Der OSM-Datenbank hilft das also im Zweifelsfall nicht, 
wenn es den gleichen Wegenamen für einen Fussweg mehrfach gibt in der 
gleichen Gemeinde.
> 1) Nehmen wir an, Straßenzshg. werden über type=street durch Mapper 
> modelliert:  Für eine bbox B lassen sich dann alle Straßen mit Namen N 
> einfach per  Overpass oder SQL abfragen.
>
> 2) Nehmen wir nun an, Du hast eine Heuristik entwickelt, die trotz 
> mannigfaltiger Geometrien "in the wild" mittels Bestimmung anhand von 
> nearby- bzw. node-matching Algorithmen halbwegs genau Straßensegmente 
> zu einer Straße zusammenbasteln kann.
>
> ->  Ohne ein neues Objekt in der DB oder in Overpass zu schaffen, 
> welches deine Heuristik kapselt und demzufolge zur Ermittlung mehrerer 
> N in B ersatzweise zu 1) verwendet werden kann, ist das nutzlos.  Denn 
> während ich für die Instanz B=Bayern und N=Goethestraße mittels 1) 
> ohne Probleme Resultate erhalte, kann ich das mittels 2) ohne 
> Kapselung gar nicht oder nur so kompliziert, dass es niemand je 
> benutzen wird.
Warum sollte man notwendigerweise eine solche Abfrage direkt online über 
die OSM-Dienste zur Verfügung stellen wollen?
Die Frage ist hier wie so oft: wie viel Dienstleister ist OSM, oder 
inwiefern ist OSM Datenlieferant mit Tools für Mapper und Showcases für 
User?

Die Abfrage 2) ist auch ohne kapselung machbar, wenn sie in ein 
entsprechendes Tool gepackt werden kann. Nimm die Overpass-API als 
Beispiel, die IMHO recht einfach lokal installiert werden kann auf einem 
mehr oder weniger beliebigen Datenextrakt.
Füttere deine lokale Overpass-API mit dem Bayern-Extrakt (oder 
Deutschland-Extrakt), such dir die entsprechende Query aus einem (noch 
zu entwickelnden) Tool heraus, das das generieren von Queries einfach 
macht und stell die Frage an deine lokale Datenbank.
>
> -> Nehmen wir also an die Heuristik wird gekapselt und sorgt dafür, 
> Straßenzusammenhänge tatsächlich richtig zu ermitteln. Dann erfüllt 
> sie den gleichen Zweck wie Relationen vom Typ type=street.  Mit dem 
> Unterschied, das letztere von Menschen gepflegt wird und erstere von 
> demjenigen, der die Heuristik erstellt - jemandem, der nie lokales 
> Wissen besitzt, aber alle Fälle genügend genau approximieren können muss.
>
> Feststellungen:
>
>     - falls es diese Heuristik gibt und sie befriedigend genau 
> arbeitet, dann muss sie noch entwickelt werden, andernfalls wäre zu 
> fragen, weshalb sie noch nicht für OSM benutzt wird
>     - es wäre ein API-Wechsel, entweder bei OSM oder Overpass, nötig, 
> der die Heuristik als abfragbares Objekt auf dem Server hinterlegt
>     - die Heuristik anzuwenden benötigt Rechenzeit -> 'bottleneck' 
> wurde als Problem bereits angesprochen
- eine Möglichkeit, diese Abfrage lokal durchzuführen, würde das 
Bottleneck auf den Rechner des Users verlagern, die Overpass-API 
entsprechend zu erweitern durch z.B. eine Overpass-Query-GUI, wäre ein 
nettes Projekt.
>     - falls Relationen weiterhin als unnötiges Hexenwerk angesehen 
> werden, wären diese Schritte für eine Zahl weiterer Relationen zu 
> wiederholen (type=waterway e.g.)
...innerhalb des Query-GUI-Tools (oder einer darin eingebundenen 
Scriptsammlung).
>     - _einem_ Entwickler würde die Aufgabe übertragen eine Heuristik 
> zu finden, die genügend genau für _alle_ funktioniert, das dann zu 
> kapseln und als abfragbares Objekt in der DB oder abgeleiteten 
> Projekten zu implementieren
...bzw. im Query-Tool
>> Genauso mit Bundesstrassen - eine Relation, die exakt alle Objekte 
>> mit ref=B10 enthaelt, ist unnoetig. Verlaufen irgendwo die B10 und 
>> die B12 ein Stueck auf dem gleichen Asphalt, dann wird sie sinnvoll, 
>> denn ein "ref=B10,B12" am Way will niemand auswerten.
> Nein, dadurch wird sie nicht sinnvoll.  Denn wenn wir im Wiki 
> schreiben, dass die Angabe mehrerer Values durch Semikola-Trennungen 
> erlaubt ist, haben wir hier ein Musterbeispiel, weshalb es auch bei 
> Auswertungen implementiert werden sollte.
+1
> Tatsächlich wäre die von Peter bereits angegebene Implementierung 
> einer Heuristik, welche diese Relationen ersetzt, machbar und es 
> fänden sich sicher auch genug Aktive, die unterschreiben würden, dass 
> sie "genügend genau" ist.  Er schrieb
>
> "http://www.overpass-api.de/api/interpreter?way[highway=primary][ref=B 
> 10](bbox...)"
>
> würde den Job erledigen.  Das sieht erstmal gut aus - tatsälich 
> brauchen wir aber schon regex, da nicht jeder Abschnitt genau "B 10" 
> enthält - also
>
> <has-kv k="ref" regv=".*B 10.*"/>
...was das ganze ja nun nicht sooo besonders viel schwieriger macht 
(solange overpass reguläre Ausdrücke unterstützt).
>
> Auch das Netz, welches bisher, unter Verwendung von Relationen 
> abgerufen werden kann
>
> "http://www.overpass-api.de/api/interpreter?relation[type=route][ref~'.*B 
> (0-9)\+.*'](bbox...)"
>
> wäre ohne Weiteres abrufbar
>
> "http://www.overpass-api.de/api/interpreter?way[highway=primary][ref~'.*B 
> (0-9)\+.*'](bbox...)"
>
> Diese Heuristik (betrachte die bbox von D und suche im ref-key eines 
> primary, bzw. trunk ways nach "B (0-9)\+" dürfte die 
> Bundesstraßenrelationen tatsächlich überflüssig machen.  Die 
> Komplexität der Erstellung der Relation im Editor ist auch kaum 
> anders:  Suche benutzen, "ref=.." eingeben, Elemente "in die Relation 
> kippen".
>
> Leider klappt das nicht für alle Relationen, denn wie Du imho richtig 
> schreibst: "Jede Relation modelliert eine bestimmte Art von Beziehung, 
> und diese Beziehung muss man verstehen, um sie richtig editieren zu 
> koennen. "
>
> Für mich ist type=street bis dato eine solche Beziehung, die nicht 
> richtig verstanden wurde, um sie durch eine Heuristik abzubilden.
Aber eine Relation, die nicht verstanden ist, kann ich gar nicht 
abbilden oder verwenden - dafür muss ich sie verstehen.
Eine nicht verstandene Relation ist insofern IMHO komplett sinnlos. 
Sobald sie sinnvoll wird, wird sie dann möglicherweise überflüssig, weil 
anders abbildbar.
>> Leider haben wir es bei OSM relativ oft mit Menschen zu tun, die die 
>> Welt in Datenbankmodellen betrachten und denen "wenn schon, dann 
>> einheitlich" auf die Stirn taetowiert ist. Das fuehrt dann dazu, dass 
>> wenn irgendwo in Peru mal zwei Strassen mit unterschiedlichem ref=* 
>> auf den gleichen Ways verlaufen, weltweit fuer alle Strassen 
>> Relationen eingefuehrt werden muessen ;)
> Dieses Problem ist hausgemacht!  Es kommt nicht aus Peru.  Es enstand 
> dadurch, dass die Community sich entschied, zugunsten von 
> Route-Relationen den Kompromiß einzugehen, bis dahin / bis zu dieser 
> Konsens-Entscheidung weitreichend verbundene Wege zu splitten, bzw. zu 
> fragmentieren.  Nicht existierende Heuristiken zu versprechen oder 
> herbeizuwünschen ist sinnlos.  Entweder jemand widmet sich dem Problem 
> irgendwann und löst es - dann hat der/diejenige auch ein wirklich 
> gutes Argument geschaffen, _dann_ überflüssige Relationen zu 
> entfernen, oder es bleibt beim status quo.  Dieser ist, Relationen vom 
> type=street zu verwenden, um der Fragmentierung durch Routenrelationen 
> und andere Bedürfnisse zu entgegnen.
Relationen vom Typ street werden kaum doch verwendet, das splitten der 
Wege funktioniert weitgehend gut, weil man schnell genau sieht, an 
welchem Wegestück man Daten ändert.

Gruß
Peter