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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
