@nebulon42, danke für den Hinweis, das ist grandios, schöne Arbeit! Genau das 
meinte ich.

Am effizientesten sind solche Tools wenn Sie auch als Web Anwendung zur 
Verfügung stehen.
Wäre fein, ein Webfrontend zu haben, das über eine einfache Schnittstelle 
solche Tools im Web 
verfügbar macht.

snupo

-----Original Message-----
From: nebulon42 [mailto:nebulo...@mailbox.org] 
Sent: Sonntag, 04. Februar 2018 11:58
To: talk-at@openstreetmap.org
Subject: Re: [Talk-at] Adressimport Wien

Ich weiß nicht ob du genau sowas gemeint hast, aber so ein Tool gibt es
bereits: https://gitlab.com/gmgeo/at-address-compare

nebulon42

Am 2018-02-04 um 10:38 schrieb  _:
> Stimme Markus Straub und Kevin Kofler zu.
> Die beschriebene Praxis ist sehr gut.
> 
> Ich denke OSM folgt ungefähr diesem Ansatz:
> * Manuelle Edits zuerst
> * Edits aus Datensammlungen primär zur *Motivation oder *Kontrolle 
> manueller Edits
> * Massenüberschreibung manueller Edits nur nach Test und gründlicher 
> Rücksprache mit der Community Das Überschreiben händischer Edits mit Daten 
> aus Datensammlungen ist grundsätzlich untunlich.
> 
> Die Daten des BEV sind sicher nutzbar für OSM, aber dieser Einsatz schadet 
> mehr als er nützt.
> Sinnvoll wäre zB ein Qualitätssicherungstool zu schreiben, das die BEV Daten 
> zur Qualitätssicherung der bestehenden Daten nutzt. 
> 
> snupo
> 
> 
> -----Original Message-----
> From: Kevin Kofler [mailto:kevin.kof...@chello.at]
> Sent: Sonntag, 04. Februar 2018 06:24
> To: talk-at@openstreetmap.org
> Subject: Re: [Talk-at] Adressimport Wien
> 
> Markus Straub wrote:
>> - es einen Rückschritt Adressen vom Gebäudepolygon auf einen eher 
>> willkürlich definierten Punkt (weil es so aus dem OGD hervorgeht) zu 
>> setzen
> 
> +1
> 
> Bisher wurde das in Wien so gehandhabt: Wenn ein Gebäude nur eine Adresse 
> hat, dann ist diese bevorzugt auf das gesamte Polygon bzw. Multipolygon zu 
> setzen. Nur wenn es mehrere Adressen für ein Gebäude gibt (meistens bei 
> Eckhäusern), dann werden diese auf die Eingänge gesetzt. Ich halte das 
> bereits für den besten Kompromiß, bin also dafür, die bestehende Praxis 
> beizubehalten.
> 
>> - es nicht sinnvoll ist die addr:housenumber dann bei den 
>> Gebäudepolygonen auf addr:unit zu setzen. Die Nummer ist und bleibt 
>> ja die Hausnummer und wird nicht zu Stiege /..?
> 
> +1, das erscheint mir ganz klar.
> 
>> siehe z.B.
>> https://www.openstreetmap.org/changeset/56025822#map=19/48.23615/16.4
>> 7
>> 712 oder https://www.openstreetmap.org/#map=19/48.27661/16.37471
>>
>> Wie seht ihr das?
> 
> Diese Änderungen sind nicht sinnvoll. Gleich auf den ersten Blick im 
> Rendering sichtbar sind viele doppelte Hausnummern. Auf der Datenebene gibt 
> es wahrscheinlich noch mehr Ungereimtheiten.
> 
>         Kevin Kofler
> 
> 
> 
> 
> _______________________________________________
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> _______________________________________________
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 



_______________________________________________
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Antwort per Email an