OSM Fools

Communities Deutschland (Germany)
1

Hi,

Die Fools-Auswertung funzt wieder. Heute manuell und morgen früh wohl automatisch.
https://wambachers-osm.website/fools

Gruss
walter

2

Bei den “Infos” gibt es noch ein paar Todos :wink:
Z.B. könntest du dort auch eine Antwort auf die Frage geben, wie du “Flächen” auswertest (prozentualer Flächenanteil, Mittelpunkt, etc.), v.a. wenn eine PLZ Linie mitten durchläuft: Laut deiner Liste wird das Schaubergwerk Volle Rose angemeckert, obwohl es meinem Auge nach größtenteils in der PLZ Langewiesen liegt und somit korrekt ist/sein sollte.

3

Jo, da muss ich auch mal wieder dran.

Ich benutze die Postgis-Funktion ST_PointOnSurface(geom) und schaue, in welchem PLZ-Bereich dieser Punkt liegt.
Der berechnete Node liegt in der Regel in der Nähe des Schwerpunktes; dabei wird aber dafür gesorgt, dass bei “krummen” Flächen der Node immer innerhalb der Fläche liegt.

hier mal ein Bild:

Das Gelände hat die PLZ 98704 Langwiesen aber mein PointOnSurface (brauner Node) liegt in 98693 Ilmenau. Übrigens liegt das Museums-Icon, das von Carto-Style dargestellt wird, auch an der gleichen Stelle und somit im “falschen” PLZ-Gebiet.

Sorry, da kann ich nix machen. DU könntest allerdings die PLZ-Grenze ein wenig nach Norden verschieben.

Übrigens ist das Haus mit einer Ilmenauer Adresse erfasst. (blauer Node)

Gruss
walter

4

:roll_eyes: … hört sich irgendwie nach “tagging for fools” an :stuck_out_tongue:
habe mir das mal gerade eben im geoproxy von thüringen angeschaut, da läuft die grenze auch irgendwie mittendurch. zusätzlich habe ich mir auch noch die gemarkungen angeschaut, also einfach zuordenbar schaut anders aus :confused:
Vielleicht sollte ich aber auch mal rausfinden, wo das Büro/Museum/Gebäude steht, weil o.g. ist ja der komplette Stollen mit addr erfasst…

5

Wie schön dass die Fools-Auswertung wieder läuft … wenn ich doch nur mehr Zeit-Reserven hätte :slight_smile:

Da fallen jetzt u.a. massig Abweichungen in Niedersachsen auf, alles im Bereich PLZ 3xxxx.

Das stammt wohl aus den dortigen Gemeindefusionen gegen Ende 2016 dort, denk ich.

Auch hat da wer wohl bei etlichen Straßenumbenennungen zwar name=xxx an den Wegen geändert, die addr:street-Tags an den Gebäuden ließ er jedoch so wie vorher.
Gut zu sehen im OSM-Inspector von geofabrik.de → Address-Layer dort.

6

Hab mich mal drum gekümmer. Ob ich alle Adressen erwischt habe, schau ich morgen nach.

Gruss
walter

7

“Tagging for fools/tools” ist das mMn nicht:
Die PLZ-Grenze ist da, wo sich die PLZ ändert. In einem Gebäude also nur, wenn es zwei Eingänge mit unterschiedlicher Adresse und PLZ gibt.

8

Hallo wambacher,
wird “Bremen” in den Fools derzeit nicht aktualisiert (Stand derzeit 2017-02-04, alle anderen 2017-02-08)? Fiel mir nur grad mal wieder auf :wink:

Schöne Grüße!

9

oops, sollte nicht sein. ich schau mal nach.

Gruss
walter

10

Hab mir das mal angesehen:

Ursache ist, dass die beiden Datensätze mit den geschlossenen Fools nicht gelöscht werden. Und wenn die drin bleiben, werden auch Fools für Bremen ausgegeben, obwohl sie uralt sind. Neue Fools für Bremen scheint es nicht zu geben.

Ich hab mal ein paar Testausgaben in die Auswertung eingebaut und hoffe, dass ich morgen mehr sehe. Ich könnte die Datensätze auch einfach löschen aber dann packe ich das Problem nicht.

Gruss
walter

11

Danke schonmal für die schnelle Ursachenforschung - wirklich dringend ist es ja nicht, aber natürlich schön, wenn es von Zeit zu Zeit gelöst ist :wink:

12

Hallo wambacher,
noch eine kleine Verbesserungsidee für die “Fools”: Wäre es möglich, die Zeilen mit einer Datumsangabe der letzten Bearbeitung anzugeben? Bei mehreren PLZ würde m.E. das Datum des zuletzt bearbeiteten reichen. So könnte man auf einen Blick sehen, bei welchen nodes, ways, relationen sich etwas seit dem letzten Besuch auf der Seite getan hat/welche hinzugekommen sind, wenn man nur mal alle paar Wochen nachschaut.

Schöne Grüße

13

Theoretisch ja. Ich habe nach dem Crash ja die DB neu aufgebaut und dieses mal auch OSM-interne Daten mit importiert (user, userid, version, timestamp, changeset). D. h. die Daten stehen mir zur Verfügung :slight_smile: ich denke mal drüber nach.

Das Problem mit Bremen besteht immer noch, was ja klar ist, da ich am Algorithmus noch nix geändert habe. Mal sehen, was die Testausgaben sagen.

Gruss
walter

EDIT: Bremen sollte geklärt sein. Die Auswertung ist zwischen dem Land Bremen und der Stadt Bremen durcheinander gekommen. Mal sehen, wie es morgen aussieht.

14

Bremen war wohl nix :frowning:

https://wambachers-osm.website/fools/

Gruss
walter

Edit: Man sollte ein geändertes Programm auch abspeichern und übersetzen - das soll i.d.R. sehr hilfreich sein :open_mouth:

15

na, geht doch - Bremen (und alle Länder ohne Fools) wird nicht mehr angezeigt.

Gruss
Walter

16

Schön, danke!
Würde mich freuen, wenn mein o.g. Vorschlag berücksichtigt würde, wenn Du die Daten eh mitsammelst :wink:

Schöne Grüße!

17

Klaro, kommt. Muss nur erst die Version 4.2 der Boundaries Map fertig stellen.

Gruss
walter

18

Das freut mich, auch dafür danke im Voraus. Eilt ja auch nicht

19

Moin,

ich hab mal die ersten Schritte gemacht - aber nur bei der Datenerfassung, noch nicht bei der Auswertung.


select osm_id,osm_type,postcode,st_astext(geom) geom, osm_timestamp
  from collected_postcodes
 limit 10;
 osm_id | osm_type | postcode |                 geom                 |    osm_timestamp     
--------+----------+----------+--------------------------------------+----------------------
    129 | n        | YO1 8RS  | POINT(-1.0815173 53.9593574)         | 2017-01-20T01:59:05Z
    476 | r        | 8010     | POINT(15.4494234560134 47.0777836)   | 2014-09-24T17:50:00Z
    566 | r        | 3001     | POINT(4.68517165847351 50.8607713)   | 2014-12-20T20:19:22Z
   1148 | r        | 2601     | POINT(149.120144577838 -35.2819704)  | 2016-08-29T11:23:12Z
   1198 | r        | 2600     | POINT(149.130015062231 -35.3023549)  | 2017-01-08T01:45:22Z
   1989 | r        | M5S 3H3  | POINT(-79.3939746287022 43.66393395) | 2015-03-12T19:27:57Z
   2131 | r        | SE5 8AF  | POINT(-0.0890817374933783 51.469975) | 2010-07-10T11:32:35Z
   2828 | r        | 10682    | POINT(23.7329577374838 37.9890123)   | 2015-11-12T22:58:13Z
   3212 | r        | 13403    | POINT(13.3255188775985 52.57338835)  | 2013-09-21T10:19:38Z
   3215 | r        | 14057    | POINT(13.2748570114068 52.50886355)  | 2016-12-27T22:58:53Z
(10 Zeilen)

Damit lässt sich (demnächst) das letzte Änderungsdatum der PLZ berücksichtigen.

Aber: Irrläufer können ja auch durch geänderte PLZ-Grenzen erzeugt werden. Da müsste man also noch den Timestamp der Grenzrelationen berücksichtigen.

Aber2: Wenn ein GrenzWAY geändert wird, muss sich nicht unbedingt der Timestamp der Rel ändern. :frowning:

Aber3: Wenn ein GrenzNODE verschoben wird, … :frowning: :frowning:

Ob und wie ich das hinbekomme, ist mir noch unklar.

Gruss
walter

20

Vermutlich auch ein Problem: Wenn ein Gebäude komplett verschoben wurde, bleibt dann der timestamp des Gebäudes auch erhalten?

Baßtölpel