OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Eigentlich ™ sollten diese im"blauen" Layer auftauchen, was sie jetzt auch machen. War ein Logik-Fehler im Abfrage-SQL, den ich eben (hoffentlich diesmal korrekt) gefixt habe. Danke für den Hinweis :sunglasses:

Gruß, Frank

Wie kompliziert ist es einen Regler für die Duplikate einzubauen?
Also, dass man beispielsweise Duplikate temporär ausschliessen kann, die nur 10 oder 20 Meter auseinanderliegen, sind meist false positive.

Ich dachte das macht der Regler an der linken Seite. Die Schritte sind allerdings aller 50m.

Den hab ich tatsächlich übersehen, aber der macht auch nicht was ich will. Ich will bspw. alles bis 50 Meter ausblenden.

Edit: Argh! Ja. Hab nix gesagt!
Danke!

Hallo Frank,

ich hab heute (vielleicht auch schon immer, keine Ahnung) das Problem, dass der JOSM-Link bei postalcode boundary nicht funktioniert und nur eine Fehlermeldung ausgibt.

Die Anmeldung beim OSM-Server mit der OAuth-Zugriffskennung »...« ist fehlgeschlagen. Rufen Sie bitte den Voreinstellungsdialog auf, um eine neue Zugriffskennung anzufordern.

Alle anderen JOSM-links funktionieren. Habs auch schon mit OAuth-Berechtigung widerrufen und neu anmelden versucht: keine Wirkung. Ist da was anders an den Links?

Gruß Thomas

Hallo Thomas,

der Link war tatsächlich anders aufgebaut, da war noch ein https-Aufruf drin, den ich damals bei der Umstellung auf http übersehen hatte. :roll_eyes:
Anyway, jetzt sollte es gehen. Danke für die Fehlermeldung.

Gruß, Frank

Danke, funktioniert.

Muss mal kurz nachfragen: OSMSuspects in USA in einzelnen Bundesstaaten, mit UI auf Englisch. Geht sowas mit vertretbarem Aufwand?

In der aktuellen Version eher nicht. Da ist viel auf die deutschen Gegebenheiten abgestimmt. Ich bin z.Z. an Vorüberlegungen zu einer von Grund auf neuen Version, einige Sachen kann man besser machen, ein paar verwendeten Bibliotheken sind auch schon gealtert. Da werde ich berücksichtigen, dass man auch andere Länder verarbeiten kann (soweit möglich).

Aber wie es so ist, die Zeit ist knapp.

Die Auswertung ist kaputt.

Laut Statistik wurden gestern 11 Millionen Adressen gelöscht und auf der Karte hagelt es nur so an Fehlern.

Danke. Auf die Schnelle kann ich nix sehen in den Logs, der Download von germany-latest scheint auch ok zu sein, Platte ist 3/4 leer, … und geändert hab ich auch nix.

Was (mir) auffällt:

Irgendwie klappt die Zuordnung zu den Straßen nicht mehr richtig zB: hier
https://osm-suspects.gbconsite.de/map#13/48.4983/9.7346/osm-wrongcity-minimalmissing-wrongstreet-wronghousenumber-outsideplz-falsepositive-dupes
“blau” gibt’s dafür gar nicht, obwohl es die auch geben müsst
“orange”/ Duplikate war früher (gefühlt) auch mehr (gibt es sonst jede Menge)

Und in den Listen sind mir bei “addr:street” unter “0-9” jede Menge Strassen mit beginnender Ziffer aufgefallen, war bisher nicht so.
Bei 2. Gartenweg und 3. Gartenweg hab ich nachgesehen, aus meiner Sicht alles in Ordnung (im Download unter JOSM).

Gruss derBeKri

Ich habe den Eindruck, daß sämtliche Adreß-nodes als wrongstreet angemeckert werden, Flächen aber korrekt behandelt werden.
Baßtölpel

Ich lass den Import und die Auswertungen grad nochmal laufen. Ich vermute einen (unbemerkten) Plattenfehler beim Import (nur 3,x statt 14,x Millionen Objekte mit addr:*). Unser HW-Linux-Spezialist ist leider noch nicht erreichbar, der kann die HW dann mal durchchecken.

Nutzt du diffs-Updates? Zur info: wambacher hat da auch gerade ein Problem

Nö.

Die Platten sind lt. smartctl ok. Anyway, ich hab das gleiche germany-latest nochmal importiert, und jetzt sehe ich auch schon, das statt 3 nun wieder 14 Millionen drin sind. Ziemlich mysteriös, das.

Zur Info: Relativ kurzfristig werde ich von Postgres 10 auf 11 upgraden und die Kiste nach 391 Tagen uptime :sunglasses: mal neu starten. Da wird die Seite mal für 1, 2 Tage offlne sein.

Mut zum Boot :wink:

Viel Glück
walter

melde dich doch bitte mal, wenn der Update durch ist. Müsste ich eigentlich auch machen.

Hardware ok, Software auch. Es waren unglücklicherweise zuviele offene Datenbankverbindungen zu der Zeit.

(Ab und an sollte man die Mails vom Cron-Job auch lesen. :roll_eyes:)


Node stats: total(296965944), max(6270315293) in 329s
Way stats: total(48071240), max(669581619) in 433s
Relation stats: total(640022), max(9313964) in 452s
Committing transaction for germany_point
Committing transaction for germany_line
Committing transaction for germany_polygon
Committing transaction for germany_roads
Setting up table: germany_nodes
Connection to database failed: FATAL:  sorry, too many clients already
FATAL:  sorry, too many clients already

Error occurred, cleaning up

@Walter: Klar, mach ich.

So, der Upgrade auf Postgres 11 ist durch, ein erster Test mit einem kleinen Extrakt (Regierungsbezirk Karlsruhe) verlief erfolgreich. Ich lasse die Seite bis morgen früh im Wartungsmodus, sind eh nicht die deutschlandweiten Daten drin.

@Walter: meine wenigen pg/psql-Prozeduren und die SQLs laufen ohne Änderung, auch sonst nix auffälliges bisher.
Die 10er habe ich in 3 Schritten gedumpt: Rollen/User, Schema only, Daten only. In der 11er dann die Rollen angelegt, und mit pg_restore versucht, die Schema anzulegen. Da zeigt sich gleich, wenn Extensions fehlen und ggf. manuell nachinstalliert werden müssen, bevor man die Daten einspielt - bei mir hatte quantile aus dem pgxn gefehlt. Hilfreich ist es auch, die postgresql.conf vor dem restoren anzupassen - ich hatte es erst danach gemacht-, ansonsten dauert der Restore etwas länger :wink:
Alles easy, dauert nur etwas.

Die Seite ist wieder online. Hat alles einwandfrei geklappt :smiley: