Relation

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.

Edit:

Anstelle des jetzigen Textes

würde ich schreiben

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 .

edit: Hab mal (analog zum Genehmigungsverfahren für Eilentscheide, das ich aus der Uni-Selbstverwaltung kenne) ein nachträgliches Voting im Wiki erstellt: http://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet#Deprecation_.22blessing.22 .

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. :slight_smile:

Viele Grüße

Michael

machen wir doch einfach noch ne associatedPostcode-Relation. Eine einzige Relation pro PLZ und alle, aber wirklich alle Häuser drin.

Oder noch einfacher: Alle Häuser einfach als Member in die PLZ-Boundary rein. Dann brauchen wir keine neue dafür.

Duck und Weg
walter :wink:

Das Thema ist auf Tagging angekommen. Talk-de habe ich gestern Abend darüber informiert.

Hi,

sa ich mich auch grad mit einer Auswertung der Hausnummern bekomme ich auch mit, dass die associatedStreet-Relationen so einige Tücken haben. Auf dem letzten Hackweekend mit gislars schon überlegt, welcher Straßenname denn für die Adresse genommen wird, wenn dieser unterschiedlich ist. Denn man hat die Roll street, wo an dem Way ein name dran ist, dann gibt es noch den tag name in der Relation sowie einige house-Member haben selsbt auch (in dem Fall überflüssigerweise) add:street was eingetragen.
Auch die Auswertung ist wie schon angesprochen sehr schwierig, denn man muss zu den house-Member die street-Member Suchen. In einige Fällen fehlen den Relationen auch eindeutige Rollennamen. So sind manchmal nur Häuser vorhanden, ohne street-Rolle. Oder es ist in der Relation nur ein Object ohne Rolle vorhanden. Die kann ich ja mal für Deutschland Statistisch auswerten, wenn nachher fertig ist, da kann ich ja mal zählen wieviel Relationen deutschland hat und in wie vielen Fällen die einzelnen Rollen fehlen. Oder kann man sowas mal durch die Overpass-API analysieren lassen?

@wambacher: übrigends wenn du eine associatedPostcode Relation haben möchtest, dann kann man doch auch für city und suburb eine Relation erstellen. Dann braucht man nur die Hausnummer ans Haus packen den Rest über Relationen lösen, das wäre am “schönsten”. :stuck_out_tongue: duck

Christopher

+1. Danke!

Es sieht so aus als würde eine Mehrheit für das Deprecation stimmen.

Meine Vorschlag: Relation:associatedstreet geht in Relation:street auf. Dort wird dringend empfohlen Adressen mit addr:street zu taggen, verschiedene Aspekte eines Straßenzugs zu vereinigen soll im Vordergrund stehen.

Hört sich vernünftig an. Mein “Kill-Kriterium” der fast unmöglichen Wartbarkeit trifft bei den Street-Rel ja wohl nicht zu. Die Straßenteile sind überschaubar und relativ statisch. Splitten und Löschen behandeln die Editoren relativ gut (iD?) und Neuzugänge bei Straßenteilen - also wirklich neue Straßenstücke zusätzlich zu den vorhandenen) kommen ja nicht so oft vor.

Hoffen 'mer mal alles Gute.

BTW: Der Terracer-Plugin in Josm müsste dann natürlich dringenst angepasst werden.

Gruss
walter

Geht doch noch eleganter: Alle gleichen Hausnummern in eine Relation packen (für Straßennamen gab es das doch schon) und dann hat man alles über Relationen gelöst :wink:
Im Ernst: Relationen sind ein mächtiges Werkzeug, ohne das sich vieles kaum oder gar nicht darstellen ließe, so sie denn vernünftig genutzt werden (können).

Der Rest der Welt scheint eher ein Fan von associatedStreet. Einige kritisieren auch das Hoppla-Abstimmen ohne Proposal.

So Jungs,
mein import ist schief gegangen (Platte voll), hab ich mal schnell für Brandenburg eine Statistik gemacht. Berlin ist auch mit drin:

Gesamt 1255 Relationen associatedStreet:

  • 817 nur ohne Rolle street (mit house)
  • 18 nur ohne Rolle house (mit street)
  • 20 ohne Rollen street und house
  • nur 400 sind OK!!!

Hätte echt nicht gedacht, dass es wirklich so schlimm aussieht, gut möglich dass es auf ganz DE betrachtet oder Weltweit besser aussieht. Aber nur 1/3 mit gültigen Inhalten find ich schon sehr schlecht. Also wenn die associatedStreet erhalten bleiben soll, dann wäre es wirklich sinnvoll mit den street-Relation zusammen zu führen. Vielleicht schaff ich es ja übers Wochenende die Platte zu säubern, dann kann ich mal eine DE-Statistik erstellen.

Christopher

Hallo,

kurzer Zwischenstand: 23 Ja, 10 Nein und 7 WAT (eine Art starkes Nein).

Ich fasse mal die Argumente von Pro- und Kontraseite zusammen. Achtung, das ist einen parteiisch gefärbte Zusammenfassung!

Argumente für die Deprecation (also für ein künftiges Abraten/für ein künftiges Für-Veraltet-Erklären)

  • wambacher meint, sie seien schwerfällig/umständlich.

  • Es würden eh nie alle Editoren associatedStreet-Relationen unterstützen [addr:street am Node hingegen schon] (AndiG88)

  • Tordanik meint, dass Anwendungen bislang keinen Vorteil daraus [aus den Relationen] ziehen konnten. Skorbut sieht es ählich.

  • Es brächte mehr Aufwand für den Mapper als addr:street an den Nodes, meint Imagic. Skorbut meint das Gleiche, spricht jedoch von Newbies.

  • Es brächte mehr Aufwand für den Datennutzer als addr:street an den Nodes, meint Imagic.

  • Es wäre eine fragiles Datenkonstrukt, meint Imagic.

  • wambacher, M-Reimer und Imagic meinen, sie seinen meist nicht vollständig.

  • Fkv meint, man solle Relation nur dort verwenden, wo es nicht anders geht.

  • Fkv meint, Adressen seien nicht an die Straße gebunden. Es sei egal, wo die Straße verläuft.

  • camelCase-Schreibweise sei Java-, aber nicht OSM-Standard, meint Fkv.

  • “associatedStreet is totally over-engineered and for a lot of people only works on PowerPoint” (auf Deutsch: associatedStreet ist vollkommen überzüchtet und funktioniert bei vielen Leuten nur in Powerpoint) (couchmapper)

  • couchmapper meint, man hätte die Deprecation schon vor Jahren durchführen müssen.

  • Thomersch meint, dass die Verarbeitung dieser Relationen schrecklich sei und er keinen Sinn darin sieht, sie weiter zu behalten.

Argumente gegen die Deprecation

  • Polyglot meint, man könne dann Adressen ohne räumliche Abfragen ermitteln (man bräuchte nur die Relationen). Frederik Ramm widerspricht ihm.

  • Pnorman meint, 20% der Adressen weltweit würden noch dieses Schema nutzen und es sei in manchen Ländern dominant gegenüber addr:street an den Einzelobjekten.

  • SimoneSVC meint, es sei das einzig Vernünftige. (Original-Zitat: “It is indeed the only way we have to normalize addresses and other stuff. The only one that makes sense, at least. It solves so many problems that I can hardly understand how people cannot like it, let alone even think of deprecating.”)

  • Nadjita meint, es sei die einzige Möglichkeit einem Gebäude mehrere Adressen zuzuweisen. Das kommentiert Xxzme mit dem Hinweis auf das Proposal AddrN [1]. Das kontert Nadjita mit dem Hinweis, dass dort noch nicht einmal das Voting begonnen habe.

  • Es sei nicht elegant, addr:street=* nicht auf allen Nodes zu wiederholen, meint PiRK.

  • Es hätte vorab keine Diskussion gegeben, keine Ankündigung des Votings, meint StephaneP.

  • Ecologeek meint, bei Straßenumbenennungen würde man gerne mal ein paar Häuser vergessen. AndiG88 kontert, eine Beschädigung durch Newbies sei hundermal wahrscheinlicher.

  • Gall meint, es gäbe keine gescheite Alternative und ihm fehle die ernsthafte Diskussion vor der Abstimmung.

  • Ineiev würde lieber type=street abschaffen und associatedStreet in seinem Anwendungsbereich ersetzen, da es gebräuchlicher sei.

  • Larry0ua ist von dem Voting überrascht und lehnt deshalb ab.

Sonstige Anmerkungen

  • Xxzme, jojo4u und weitere User möchte die Relation type=street beibehalten. (Anmerkung von mir: Die dient ja auch anderen, sinnvolleren Zwecken.)

  • Stephan75 meint, dass zumindest keine neuen Relationen mehr angelegt werden sollten.

  • Fkv (hat mit Ja gestimmt) möchte keine Massenedits, bloß weil die Relation “deprecated” ist.

Von Sarah Hoffmann (Maintainerin von Nominatim) stammt folgendes Zitat:

+10 von mir.

Ich habe mal die Overpass-API befragt. Beispiel-Abfrage für Baden-Württemberg:

[out:json][timeout:60];
(relation["type"="associatedStreet"](area:3600062611););
out count;

Daten für die einzelnen Bundesländer (Anzahl der Relationen pro 1000 Einwohner in Klammern [2]):
Saarland: 2 (0,0020)
Sachsen: 249 (0,062)
Schleswig-Holstein: 276 (0,098)
Berlin: 344 (0,10)
Sachsen-Anhalt: 426 (0,19)
Thüringen: 452 (0,21)
Niedersachsen: 1747 (0,22)
Mecklenburg-Vorpommern: 391 (0,24)
Bremen: 175 (0,27)
Bayern: 3381 (0,27)
Brandenburg: 911 (0,37)
Hamburg: 702 (0,40)
Rheinland-Pfalz: 1758 (0,44)
Hessen: 4264 (0,71)
Baden-Württemberg: 10689 (1,0)
Nordrhein-Westfalen: 22965 (1,3)
Summe: 48.732
Hausnummern gesamt laut Gehrke am 11. Januar 2015: 7.762.395

Viele Grüße

Michael

[1] Ich mag das Proposal und verbreitet ist es auch schon.
[2] https://www-genesis.destatis.de/genesis/online/data;jsessionid=ACBC64A0E347B38B87F9AC74F48DDC69.tomcat_GO_1_2?operation=abruftabelleBearbeiten&levelindex=1&levelid=1421958132869&auswahloperation=abruftabelleAuspraegungAuswaehlen&auswahlverzeichnis=ordnungsstruktur&auswahlziel=werteabruf&selectionname=12411-0009&auswahltext=%23Z-31.12.2013%23SDLAND-01%2C02%2C03%2C04%2C05%2C06%2C07%2C09%2C10%2C08%2C11%2C12%2C13%2C14%2C15%2C16&werteabruf=Werteabruf

Den speziellen Einführungsartikel zu Relationen für Newbees im Wiki lesen. Eventuelle Kritik an mich.
https://wiki.openstreetmap.org/wiki/Einf%C3%BChrung_Relationen

Gruß
Tirkon