Hi, ich habe nochmal so eine Grafik mit den Hexagonen produziert. Die Letzte ist mittlerweile auch fast 3 Monate her: http://silicon-verl.de/home/flo/tmp/20150618-flo-missing-addr-perc-owl-hexag... Und hier die alte: http://silicon-verl.de/home/flo/tmp/20150328-missing-addr-perc-owl-hexagon.p... Ein unterschied ist das Hexagone OHNE Adressen jetzt grün sind und nicht verschwinden. Irgendwann mache ich auch eine "Webkarte" da draus - Ist ja eh alles schon in der Datenbank ... Flo -- Florian Lohoff f@zz.de We need to self-defense - GnuPG/PGP enable your email today!
Wo wir grad dabei sind ... wie wollen wir mit den vorhandenen associated_street Relationen weiter vorgehen, besonders aber nicht nur in Bielefeld? Ich bin grad mal wieder darüber gestolpert während ich eigentlich nach Hydranten ohne Referenznummer gesucht habe (sprich: nach solchen wo nur der Hydrant aber kein passendes Schild gefunden wurde). Nomatrix hatte da die "interessante" Angewohnheit da nicht etwa ref=... einfach freizulassen sondern hat diese mit ref=00000 eingetragen ... und wie sich herausstellte hat er auch associated_street mit ref=... versehen. Die ID sind dabei wohl die internen Straßennummer der Stadt wie sie zB. in den Straßenlisten zur Kommunalwahl zu finden sind, und auch hier wurde dann bei nicht bekannter Straßennummer 00000 eingetragen. Die ganze ref=... Geschichte ist natürlich mal wieder undokumentiert und in kommentarlosen Changesets erfolgt :( Nun aber die eigentliche Frage: ich habe die associated_street Relationen bisher weitgehend ignoriert, d.h. da wo ich Gebäude neu erfasst oder in Einzelfällen gelöscht und neu gezeichnet habe fehlen diese in den entsprechenden Relationen. Wollen wir diese Relationen (die eh so halb auf der allgemeinen Abschussliste stehen) behalten? Wenn ja dann müssten wir irgendwie eine Auswertung für "Gebäude mit Adresse in Straße X fehlt in associated_street Relation der Straße X" basteln ... Oder können wir uns darauf einigen die Dinger einfach über Bord zu werfen? -- hartmut
On Thu, Jun 18, 2015 at 02:11:27PM +0200, Hartmut Holzgraefe wrote:
Wo wir grad dabei sind ... wie wollen wir mit den vorhandenen associated_street Relationen weiter vorgehen, besonders aber nicht nur in Bielefeld?
[ ... ]
Nun aber die eigentliche Frage: ich habe die associated_street Relationen bisher weitgehend ignoriert, d.h. da wo ich Gebäude neu erfasst oder in Einzelfällen gelöscht und neu gezeichnet habe fehlen diese in den entsprechenden Relationen.
Wollen wir diese Relationen (die eh so halb auf der allgemeinen Abschussliste stehen) behalten? Wenn ja dann müssten wir irgendwie eine Auswertung für "Gebäude mit Adresse in Straße X fehlt in associated_street Relation der Straße X" basteln ...
Oder können wir uns darauf einigen die Dinger einfach über Bord zu werfen?
Ich kenne keine Auswertung die die associatedStreet relation auswerted. Es gibt also keine debugging tools, keien Anwender. Schönes Konzept, kompliziert, ungenutzt und unnütz. Ich halte die für über. Da wo ich editiere schmeisse ich die auch schonmal über Board und lösche die. Und wie du schon sagst - wenn die mal gebraucht wird können wir die quasi automatisch neu erzeugen. Wenn wir (wie ich es mache) immer ein addr:street mit draufpacken auf die nodes/buildings kann man das automatisch erzeugen. Flo -- Florian Lohoff f@zz.de We need to self-defense - GnuPG/PGP enable your email today!
Also ich sehe auch keinen wirklichen Nutzen und meistens sind die Dinger ja eh unvollständig. Und ersetzen lassen sie sich in JOSM ja durch Strg+F. :D Da im allgemeinen auf den Gebäuden und POIs eh schon die komplette Adresse liegt fungiert das eh nur noch als Sammelrelation. Ob löschen oder nicht, da bin ich unschlüssig. Nur weil ich etwas doof und unnütz finde würde ich es noch lange nicht löschen... abgesehen vielleicht von 2 landuses/Grashalm-Geschichten. Anders sehe es natürlich bei Sachen aus, die einfach nur falsch sind. Am 18.06.2015 um 14:18 schrieb Florian Lohoff:
On Thu, Jun 18, 2015 at 02:11:27PM +0200, Hartmut Holzgraefe wrote:
Wo wir grad dabei sind ... wie wollen wir mit den vorhandenen associated_street Relationen weiter vorgehen, besonders aber nicht nur in Bielefeld? [ ... ]
Nun aber die eigentliche Frage: ich habe die associated_street Relationen bisher weitgehend ignoriert, d.h. da wo ich Gebäude neu erfasst oder in Einzelfällen gelöscht und neu gezeichnet habe fehlen diese in den entsprechenden Relationen.
Wollen wir diese Relationen (die eh so halb auf der allgemeinen Abschussliste stehen) behalten? Wenn ja dann müssten wir irgendwie eine Auswertung für "Gebäude mit Adresse in Straße X fehlt in associated_street Relation der Straße X" basteln ...
Oder können wir uns darauf einigen die Dinger einfach über Bord zu werfen? Ich kenne keine Auswertung die die associatedStreet relation auswerted. Es gibt also keine debugging tools, keien Anwender. Schönes Konzept, kompliziert, ungenutzt und unnütz.
Ich halte die für über. Da wo ich editiere schmeisse ich die auch schonmal über Board und lösche die.
Und wie du schon sagst - wenn die mal gebraucht wird können wir die quasi automatisch neu erzeugen. Wenn wir (wie ich es mache) immer ein addr:street mit draufpacken auf die nodes/buildings kann man das automatisch erzeugen.
Flo
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
On Thu, Jun 18, 2015 at 08:20:59PM +0200, tabris wrote:
Also ich sehe auch keinen wirklichen Nutzen und meistens sind die Dinger ja eh unvollständig. Und ersetzen lassen sie sich in JOSM ja durch Strg+F. :D Da im allgemeinen auf den Gebäuden und POIs eh schon die komplette Adresse liegt fungiert das eh nur noch als Sammelrelation. Ob löschen oder nicht, da bin ich unschlüssig. Nur weil ich etwas doof und unnütz finde würde ich es noch lange nicht löschen... abgesehen vielleicht von 2 landuses/Grashalm-Geschichten. Anders sehe es natürlich bei Sachen aus, die einfach nur falsch sind.
Deshalb - Ich entferne die wo ich gerade so unterwegs bin und wo die eine fehlermeldung kommt nach dem motto: "Hallo - Da ist noch eine relation die repariert werden muss" . Dann geht die über den Jordan. Flo -- Florian Lohoff f@zz.de We need to self-defense - GnuPG/PGP enable your email today!
On 18.06.2015 12:22, Florian Lohoff wrote:
Hi, ich habe nochmal so eine Grafik mit den Hexagonen produziert. Die Letzte ist mittlerweile auch fast 3 Monate her:
http://silicon-verl.de/home/flo/tmp/20150618-flo-missing-addr-perc-owl-hexag...
Eines kommt mit etwas komisch vor: Die Innenstadt von Detmold ist Rot , obwohl dort die Adressen vollständig sind. Gruß Martin
On Thu, Jun 18, 2015 at 02:13:58PM +0200, Martin Krüger wrote:
On 18.06.2015 12:22, Florian Lohoff wrote:
Hi, ich habe nochmal so eine Grafik mit den Hexagonen produziert. Die Letzte ist mittlerweile auch fast 3 Monate her:
http://silicon-verl.de/home/flo/tmp/20150618-flo-missing-addr-perc-owl-hexag...
Eines kommt mit etwas komisch vor: Die Innenstadt von Detmold ist Rot , obwohl dort die Adressen vollständig sind.
Die ganzen Adressen in Detmold tragen kein addr:city, addr:postcode und addr:country (gerade eine kurze Stichprobe gemacht) Damit zähle ich die nicht weil unvollständig - Bzw - ich vergleich eigentlich postleitzahlweise - wenn die nicht da ist kann ich die nicht vergleichen - ich habe ja eine Referenzlist. Und Hauptstraße 16, Detmold ist halt was anderes als Hauptstraße 16, Paderborn. Damit markiere ich die als fehlend. Erst später wird das dann über das geocodieren auf die hexagone gemapped. Flo -- Florian Lohoff f@zz.de We need to self-defense - GnuPG/PGP enable your email today!
Hi, hatten wir nicht vor ~2 Monaten mit dem Gedanken gespielt nach Bielefeld uns auch um die Lücken zu kümmern? Das wäre ja ein schöner Job für den Tasking Manager wo man dran arbeiten könnte, wenn man nichts besseres zu tun hat. Das wird ein Job der uns sicherlich ewig begleiten wird :D Im Prinzip könnte es ja schon reichen wenn du die Hexagone die nicht vollständig sind als GeoJSON exportierst. Das können wir dem Tasking Manager dann vorsetzen. Wobei trotzdem der Grid-Modus genutzt werden sollte. Beliebige Polygone kann der TM ja nicht splitten was in den Stadtkernen zu unhandlichen Tasks führen würde. Wobei es ja nicht unbedingt Hexagone sein müssen, aber die hast du ja schon fertig. :o) Hier geisterte ja auch die Überlegung rum ob man nicht die Jobs auf Städte aufteilt. Also ich denke solange der Tasking Manager keine Probleme bekommt können wir das ruhig in einen Job (oder 2,3,4,... Teiljobs) machen. Wenn jemand erstmal seine Stadt erledigen will, dann kann er ja cherry picking betreiben und sich die Tasks raussuchen, die dafür relevant sind, solange bei den Grenztasks sauber gearbeitet wird: Also entweder den kompletten Tasks erledigen oder Kommentar welcher Teil erledigt wurde + Unlock. Vielleicht sollten wir auch solche Sachen wie in Detmold vorher erledigen. addr:city, addr:postcode und addr:country sollten sich ja schnell großflächig nachbessern lassen, wobei natürlich bei der PLZ aufgepasst werden muss, falls es mehrere Bereiche gibt. Das dürfte nämlich viele rote Stellen entschärfen und die Chance das dort dann versehentlich was fehlendes übersehen wird, wird auch geringer. Hier kann man die ja schnell finden: http://osm.lyrk.de/address/#14/51.9427/8.8759 Gibt es irgendwelche Einwände, Ideen etc.? Andreas Am 18.06.2015 um 12:22 schrieb Florian Lohoff:
Hi, ich habe nochmal so eine Grafik mit den Hexagonen produziert. Die Letzte ist mittlerweile auch fast 3 Monate her:
http://silicon-verl.de/home/flo/tmp/20150618-flo-missing-addr-perc-owl-hexag...
Und hier die alte:
http://silicon-verl.de/home/flo/tmp/20150328-missing-addr-perc-owl-hexagon.p...
Ein unterschied ist das Hexagone OHNE Adressen jetzt grün sind und nicht verschwinden.
Irgendwann mache ich auch eine "Webkarte" da draus - Ist ja eh alles schon in der Datenbank ...
Flo
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
On Thu, Jun 18, 2015 at 08:04:07PM +0200, tabris wrote:
Hi, hatten wir nicht vor ~2 Monaten mit dem Gedanken gespielt nach Bielefeld uns auch um die Lücken zu kümmern? Das wäre ja ein schöner Job für den Tasking Manager wo man dran arbeiten könnte, wenn man nichts besseres zu tun hat. Das wird ein Job der uns sicherlich ewig begleiten wird :D
Am Ende muss man systematisch den Datenbestand bei OSM mit ALKIS/DOP vergleichen. Und das wird man auch immer wieder machen müssen. Gebäude werden abgerissen, neu gebaut, hinterbebauung etc. Wir werden da immer ein wenig hinterher rennen. Ich habe für GT das gerade gemacht und viel korrigiert. Gerade mit dem neuen ALKIS. Flo -- Florian Lohoff f@zz.de We need to self-defense - GnuPG/PGP enable your email today!
participants (4)
-
Florian Lohoff -
Hartmut Holzgraefe -
Martin Krüger -
tabris