associatedStreet-Relationen entfernen?

Also irgendwie werden in der Optionsebene Associated Houses Dinge mit dargestellt, die mit dem Thema nicht zu tun haben dürften…https://wambachers-osm.website/associatedStreet/#zoom=11&lat=51.8834&lon=13.9505&layer=OpenStreetMap.org&overlays=FFFT

Ach so… ja…

Hier sind es reine Adress-Nodes… https://wambachers-osm.website/associatedStreet/#zoom=15&lat=51.88929&lon=14.15824&layer=Openstreetmap.org%20Grayscale&overlays=FFFT
Hier ein noexit=yes: https://wambachers-osm.website/associatedStreet/#zoom=18&lat=51.949887&lon=13.877513&layer=Openstreetmap.org%20Grayscale&overlays=FFFT

Hier ein Windrad: https://wambachers-osm.website/associatedStreet/#zoom=18&lat=51.866705&lon=13.555068&layer=Openstreetmap.org%20Grayscale&overlays=FFFT

Sven

Jo, sieht wirklich merkwürdig aus.

Mach ich mich morgen mal ran. Hab noch andere Baustellen und dieser “Quickie” hat mich viel ungeplante Zeit gekostet.

Gruss
walter

Ruhig Blut… Ich wollt ja nur drauf hinweisen :slight_smile: Wie ich schon oben schrieb… Südbrandenburg dürfte seit Jahren keinerlei as-Releationen mehr haben… Darum war und ist das für mich eine kleine Testregion…

Gruß,
Sven
Edit schenkte mit ein kleines t

Jo, sieht wirklich merkwürdig aus.

Mach ich mich morgen mal ran. Hab noch andere Baustellen und dieser “Quickie” hat mich viel ungeplante Zeit gekostet.
Jo, der Collector kommt manchmal bei Buildings bzw. Nodes durcheinander.

Gruss
walter

hab es wohl gefunden. Collector läuft gerade. Sollte bald wieder gehen.

sauber :slight_smile:

https://wambachers-osm.website/associatedStreet/#zoom=9&lat=51.907&lon=12.849&layer=OpenStreetMap.org&overlays=FFTT

Gruss
walter

@wambacher: Super, dass man jetzt so weit herauszoomen kann – da erkennt man sehr schön die “Nester”.

Ich habe gerade die Liste der redundanten* associatedStreet-Relationen von Berlin durchgeschaut:


Inspected file: berlin-latest.osm
associatedStreet-relations: 187
hereof redundant: 91 (49%)
---------------
IDs of redundant associatedStreet-relations
---------------
11482
11698
14210
23680
50974
52475
374415
417598
418147
418166
420461
1074802
1076188
1076190
1085321
1105481
1166111
1166112
1179929
1179930
1187860
1202369
1202370
1212770
1212777
1212786
1240065
1250126
1250128
1269531
1521582
1671615
1672625
1672629
1688083
1688084
1688085
1693109
1700466
1700684
1700685
1700887
1701462
1701463
1701468
1702484
1702495
1702496
1702990
1704318
1704320
1707012
1709078
1709080
1709240
1709960
1712773
1712774
1712802
1712803
1712804
1712806
1712807
1712808
1712809
1713188
1713189
1714042
1714050
1717649
1717650
1720193
1720194
1732254
1736817
1736818
1871362
1946898
2521040
2521041
2521055
2521056
2521060
2521061
2521062
2521065
2521066
2891618
2891619
3183206
4202078

Ich konnte keine Entdecken, bei der Information verloren gehen würde, würde man sie löschen.

Kann das vielleicht jemand gegenprüfen?

Am einfachsten kann man das mit JOSM über “Datei->Objekt herunterladen” und dann die Liste einfügen.


  • Redundant bedeutet:
  • Alle Tags der Relation (bis auf type=associatedStreet) kommen an allen Membern der Rolle “street” vor.
  • An allen Membern der Rolle “house” existiert das Tag “addr:street” und es stimmt mit dem name-Tag der Relation überein.
  • Es gibt nur die Member-Rollen “house” und “street” in der Relation.

Das ist zuviel.
Auch alle Tags der Relation, die an allen Gebäuden vorhanden sind (im wesentlichen addr:*) müssen (und sollten auch nicht) an den Straßen sein.
Man muss mMn die “Gebäude”-Tags und die “Straßen”-Tags auseinander halten.

Abgesehen davon plädiere ich dafür, sich die Situation manuell anzusehen, bevor man as-Relationen löscht. Da gibt es oft genug Beifang wie falsche Umrisse, fehlende Hausnummern und Gebäude, falsche PLZ usw. Die gibt es zwar woanders auch, aber wenn man schon mal dabei ist …

@seichter: Ich stimme Dir zu: Das ist zu viel. Aber auf diese Weise werden tatsächlich nur Relationen als redundant ausgegeben, die keinerlei eigene Information tragen. Lieber ein paar zu wenig ausgeben, aber dafür garantiert keine, die etwas enthält, das dadurch verloren gehen könnte.

Auch ich bin für das manuelle ansehen, aber eben zielgerichtet: Sind ist der Liste tatsächlich nur solche die (nach manueller Prüfung) löschbar sind? Auf diese Weise können wir meiner Meinung nach effizienter durchforsten.

Stufe zwei wir dann komplizierter, dann geht es an solche Relationen die Widersprüche enthalten, defekt sind oder tatsächlich Information enthalten, die nicht woanders redundant getaggt ist.

Ich hab mal die aS-Relationen in eine Tabelle importiert und durchgeschaut. Bewerten will ich das jetzt nicht :open_mouth:

Kleine Statistik, welche Typen und Rollen z.Z. in Deutschland in den aS-Relationen vorhanden sind: https://osm-suspects.gbconsite.de/download/associatedstreet.html

Das verstehe ich immer noch nicht! Wieso sollten die addr:* an der Straße hängen? Das wäre ja grottenfalsch, highways haben keine addr:*-Tags. Hier ein Beispiel: https://www.openstreetmap.org/relation/68764 Hier muß geprüft werden, ob die Member mit Rolle “house” die Adress-Tags haben, nicht die Member der Rolle “street”.

Edit Nachtrag: Und hier, wieviele Adressen ergänzt werden können, wenn man die Daten aus den aS-Relationen übertragen würde: https://osm-suspects.gbconsite.de/download/associatedstreet_count.html

Ich finde eine automatische Prüfung gut… müsste ich das ganze manuell Prüfen würde ich weit mehr Fehler machen, vergessen usw. usw… :wink: Mit den zwei Overpass-Abfragen hab ich dann noch tagging defizite gefunden…

Wichtig wäre was die automatische Prüfung abdeckt und was nicht… bzw. wo eventuell noch Prüfungbedarf steckt… die Tagging krativität ist ja bei OSM sehr groß… :wink:

Unbedingt.

@wambacher: Walter, wie oft oder wann werden die aS-Daten ausgewertet und die Kacheln neu generiert? Ich hatte gestern abend ein Dorf “befreit”, die Änderungen sind nach 12+h nicht sichtbar?

Guck mal oben links. Da sollte Version 2.1.0 stehen, wenn nicht: reload oder maximal 10 Minuten warten.

Die Ausgabe des Timestamps ist aber ganz neu, konntest du vorhin noch nicht sehen.

Zum Collector: der läuft jetzt relativ flott (30 Min). Allerdings löscht er zuerst die alten Daten und dann sieht das nicht gerade toll aus. Da muss ich noch ran (collect in neue Tabellen und dann umschalten)

Mach ich jetzt.

Gruss
walter

Supi, der Timestamp.

Bei mir läuft das Filtern und Importieren rund 20 Minuten (auf HDD), ich filtere zuerst mit osmium die aS in ein XML (~2m) und verwurste das dann mit PHP (~18m) in eine (unlogged) Tabelle. Da sind dann halt keine Geometrien dabei, die müßte ich aus den anderen Tabellen joinen, wenn ich sie bräuchte.

Daten sind aktualisert.

11 Minuten, davon 9:50 für die Geometrien. Kann aber wohl noch getuned werden. Demnächst läuft das dann mehrmals am Tag.

Gruss
walter

ps: immer schön auf den Timestamp achten. :wink:

@dktue: Könntest Du eventuell Wambacher’s Link in den ersten Beitrag dieses Threads kopieren, damit man nicht immer so lange suchen muss. :smiley:

EDIT: Und auch den Link zur Abstimmung.

@chris66: Ist erledigt.

OSM-Stand vor 8 Tagen:


Inspected file: germany-latest.osm
associatedStreet-relations: 44541
hereof redundant: 25867 (58%)

OSM-Stand heute:


Inspected file: germany-latest.osm
associatedStreet-relations: 42053
hereof redundant: 24438 (58%)

Ok, wenn’s in dem Tempo weitergeht, sind in 6 Monaten alle weg… :stuck_out_tongue:

Das Problem sind nicht die 24438 redundant, sondern die immer noch 17615 nicht-redundanten.

Btw: Macht die Abstimmung noch Sinn, wenn schon eifrig gelöscht wird.