Am 17.07.2012 08:38, schrieb Frederik Ramm:
Jede Relation modelliert eine bestimmte Art von Beziehung, und diese
Beziehung muss man verstehen, um sie richtig editieren zu koennen.
+1
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? In JOSM ist der
Standardfall, den dadurch neu enstandenen Weg an gleicher Position
einzufügen. Dieses Verhalten ist mir in den letzten Jahren nicht einmal
negativ aufgefallen - weder bei MPs, noch bei Routen, noch bei sonst
irgendwelchen Relationen..
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. Speziell für Löschungen
sieht JOSM solche Warnungen vor und bietet geeignet Alternativen an -
gerade auch beim split / join von ways mit Relationen, wie es mit
Potlatch aussieht, ist mir unbekannt.
Die Abfrage "Westring, Kiel" liefert etwa 50 einzelne Straßensegmente.
"Ein Way mit dem Namen 'Westring' ist Mitglieder einer Relation. Der
Name des Ways wird nun auf 'Suedring' geaendert. Muss er deswegen aus
der Relation entfernt werden..." ;)
Das kommt darauf an - wenn die Änderung korrekt ist und die Wirklichkeit
reflektiert vermutlich schon.
Eine Relation fuer den Westring in Kiel ist dann sinnvoll, wenn sie
auch Objekte mit anderem Namen als "Westring" enthalten soll. Soll sie
das nicht, dann kann man sich die Relation sparen.
Gibst Du bitte eine Heuristik an, die präzise genug entscheiden kann,
wie der Objektzusammenhang ist? Selbst auf Hausnummern als
unique-Kriterium wäre kein Verlass, denn die sind ggf. doppelt oder gar
nicht in der DB.
Es kann durchaus zwei unterschiedliche Straßen mit gleichem Namen in
Gebieten geben, die nicht durch zwei einfache bboxes auseinanderzuhalten
sind.
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.
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.
-> 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
- 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.)
- _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
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.
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.*"/>
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.
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.
Gruß
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
