Bei den “real existierenden” gibt es leider soviele kaputte, dass man davon abraten muss, einfach irgendeine als Vorbild zu nehmen.
Hier ein paar Kriterien für moderne (PTv2-) Routen:
es kommen nur die Rollen “stop”, “platform” und “” ohne Zusätze vor. Insbesondere also nicht “forward”, “backward”, “alternate”, “alternative”, “terminal”, “start”, “stop:4”, “backward_stop_5”, …
die leere Rolle kann nur an Fahrwegen vorkommen und die stehen hinter den Haltestellenangaben
die Rolle “stop” kann nur an Punkten vorkommen. Diese sind Punkte der Ways für den Fahrweg. (Es kann aber auch mal sein, dass der Fahrweg dort noch nicht gemappt ist.) Die Rolle “stop” ist nicht verwandt mit dem “stop” in “railway=stop”.
Falls sich jemand für die alten (PTv1-) Routen interessiert … hier entsprechendes für diese:
-Die Rolle “platform” kommt nicht vor
-sie sind nicht Mitglied einer Route-Master-Relation
-es gibt nur eine Route pro Linie
-Elemente kommen nicht mehrfach vor
-pro Halt gibt es nur eine Haltestellenangabe
-alle Haltestellenangaben sind Punkte
-alle Wege sind Fahrwege.
-Relationen kommen nicht als Mitglieder vor
-die leere Rolle an einem Weg bedeutet “Nutzung im Gegenverkehr”. Die leere Rolle kann also nicht an einem Kreisverkehr oder einer anderen Einbahnstraße ohne Sondergenehmigung für Busse vorkommen.
Eine Begründung liefern diverse Aussagen von okilimu (ich habe sie mehrmals mündlich gehört, schriftlich steht das bestimmt auch irgendwo) und ein Change-Comment von ubahnverleih im Wiki. Ich habe die Seite DE:Relation:associatedStreet diesbezüglich jetzt aktualisiert und mit der englischen Variante synchronisiert (und auch umgekehrt). Die XML-Listings und Skizzen habe ich entfernt, da mir ihr Zweck nicht (mehr) einleuchtet. Ich habe mir die Freiheit herausgenommen, associatedStreet-Relationen als “deprecated” (veraltet) zu kennzeichnen (in allen Sprachvarianten) und {{out of date}} und {{out of sync}} in allen Sprachen außer Englisch und Deutsch ergänzt, da ich nur Englisch und Deutsch kann.
Jetzt mache ich mich noch an die Aktualisierung von DE:Karlsruhe_Schema. Da arbeite ich aber mit Samthandschuhen, denn das ist die deutsche Übersetzung des Originalproposals.
Ich dachte bislang, solche Texte wären sakrosant, weil auf Proposals beruhend. Ich würde nämlich gern den Hinweis auf das BBauG ändern, da er rechtlich nicht stimmt., habe ich unlängst hier begründet.
Bist du denn einigermaßen sicher, das das so konsens ist? Ich wäre das nicht, und bevor man >200.000 Relationen für deprecated erklärt braucht es m.E. mindestens soviel Diskussion wie für einen Import - denn das Endergebnis ist im Worst case doch gleich: Datenmüll in Mengen, den niemand nutzen kann.
Meinen Segen hast du (ich kann diese associatedStreet-Relationen nicht leiden, sehe keine Vorteile), aber bloß weil ich nicht überblicke wasfüreinen Vorteil die haben könnten kann ich sie doch nicht einfach so für deprecated erklären. Ich meine, derjenige, der “In bestimmten Fällen sind Relationen zur Verknüpfung von Hausnummern mit Straßen sinnvoll, obwohl sie in der Regel für Menschen weniger intuitiv zu verarbeiten sind.” im Wiki geschrieben hat, hat sich dabei ja (hoffentlich) was gedacht. Einfach aus Jux und Tollerei macht sich doch niemand son Aufwand. Siehe beispielsweise http://article.gmane.org/gmane.comp.gis.openstreetmap.region.de/42106 .
Naja, die “Abstimmung” als Mittel zur Klärung von Tagging-Fragen hat sich auch nicht gerade bewährt.
“deprecated” heißt ja nicht löschen, sondern nur: nicht mehr empfohlen.
Die Idee mag zur Vermeidung von Redundanz mit deren ganzen Nachteilen gut gemeint sein, hat sich in der Praxis aber nicht bewährt.
Mir ist noch fast keine associated-street-Relation untergekommen, die alle Häuser einer Straße oder wenigstens eines sinnvollen Straßenabschnittes enthalten hätte. Meist waren es tagging-Ruinen, die z.B. entstehen, wenn man im terracer-Tool zum Erstellen von Reihenhäusern ein Kreuz in “Relation erzeugen” gesetzt hat (war vielleicht sogar mal Voreinstellung).
Wenn jemand irgendwo einen zwingenden Vorteil für die Anwendung von associated-street sieht, bleibt es ihm unbenommen, so zu mappen. “deprecated” heißt ja nicht “verboten”.
Aber wenn jemand irgenwo einen zwingenden Vorteil sieht, dann fände ich das sinnvoll, so ein Tagging auch zu empfehlen. Denn wenn etwas besser ist, sollten wir es auch nutzen. Daher ja meine Unsicherheit: ich habe keine Ahnung, wozu man diese Rels brauchen kann. Ich mappe sie nicht, sehe aber eventuell ein sie zu benutzen, wenn mir jemand ein brauchbares Argument dazu liefert.
Ich finde einfach die Art zu sagen “ICH entscheide, das das nicht mehr empfohlen wird” suboptimal.
Die Aussicht, dass das möglicherweise irgendwann irgendwo von Nutzen ist, ist mir zu schwach gegenüber der Gefahr, dass da weiterhin lustig tagging-Leichen produziert werden, wenn auch nur im Prozent- bis Promillebereich.
Ich würde versuchen, Vorgehensweise vom Inhalt zu trennen.
“decprecation” ist etwas stärker als “not recommended”. Als IT-ler heißt für mich Derpecation oft: wird in Zukunft nicht mehr funktionieren. Was wir v.a. aber wollen ist von der Nutzung abraten.
Gerade in Bezug auf die Street-Relation sehe ich noch Diskussionsbedarf. Weil die Bindung verschiedener Wege an den Straßenzug ist für mich ein Thema.
Das Thema haben wir schon dutzende Male durchgekaut:
associated_street-Rels sind Sammelrelationen, deren 100%-ige Vollständigkeit nie und nimmer garantiert werden kann.
Es gibt keine Mechanismus, der sicherstellt, das JEDER - also auch Newbies - die Member einer Sammelrelation “sauber hält”. Dies gilt besonders beim Erfassen neuer Objekte (z.B. Neubauten), da es sehr oft garnicht bekannt ist, dass es dort eine SR für gibt, in die dieses Objekte aufgenommen werden sollen. Einzig und allein beim Löschen eines Members kommt von manchen Editoren eine Warnung - das ist alles.
Nochmals mein letztes Beispiel aus einem anderen Thread:
Knatschige Grüße
walter
ps: Dass man die ganz gut gebrauchen könnte, wenn sie denn “sauber” wären, ist unbestritten - nur das sind sie halt nicht.
Von mir aus “not recommended” statt “deprecated”, da hängt mein Herz nicht dran. Wie damit umgegangen wird, steht sowieso auf einem anderen Blatt.
Da wird u.U. mit Straßenflächen, Gassen, getrennt gemappten Bürgersteigen etc. der Bedarf schon noch zunehmen, aber die Häuser gehören da nicht notwendig dazu.
Ja, das stimmt. Aber building=entrance statt entrance=* haben wir auch für “deprecated” erklärt. Außerdem sind die Mapper nicht alle IT-ler.
Ich habe meinen Edit jetzt auf allen Übersetzungen dieser Seite rückgängig gemacht ({{out of date}} und {{out of sync}} habe ich stehen gelassen).
Vor meinem Edit habe ich mir Gedanken über eine Deprecation gemacht. Zwar schrieb tyr_asd vor zwei Jahren auf der deutschen Diskussionsseite, dass es Fälle gebe, wo man diese gebrauchen könne, z.B. mehrsprachige Gebiet, aber seine eigene Heimat-/Mappinggegend (Südtirol) widerlegt das. Meistens sehen Adressen dort so aus:
addr:street = Unterrainer Straße - Strada Riva di Sotto
addr:housenumber = 10
addr:city = Eppan a.d. Weinstr. - Appiano s.s.d.v.
addr:postcode = 39057
addr:hamlet = St. Pauls - S. Paolo
addr:street:de = Unterrainer Staße
addr:street:it = Strada Riva di Sotto
addr:city:de = Eppan a.d. Weinstr.
addr:city:it = Appiano s.s.d.v.
usw.
Anmerkung: In Südtirol wurden Adressen importiert.
Geht also auch ohne Relation.
Laut okilimu dauert das Auswerten von associatedStreet-Relationen sogar länger als das Auswerten von addr:street an den Gebäuden.
Ich bin nachher auf dem Karlsruher Stammtisch, mal schauen, was man dort dazu denkt.
