19. feb. 2012 10.52 skrev Carsten Nielsen <list_re...@toensberg.dk>: > > Den 11-02-2012 22:52, Jonas Häggqvist skrev: > >> >> Det eneste der kan ske/sker automatisk er at punkter som er blevet slettet >> vil blive oprettet igen. >> >> Jeg har umiddelbart svært ved at se dette som værende særligt >> problematisk. Den eneste ulempe er at vi ikke kan påvirke statistikken over >> dækningsgrad ved at fjerne uønskede adressepunkter. Men statistikken er jo >> ikke et mål i sig selv. At vi ender op med et par adresser som ikke (evt. >> endnu) modsvarer noget vi kan finde i virkeligheden (planlagte adresser, >> administrative adresser osv.) er da ikke 100% perfekt, men på den anden side >> heller ikke noget større problem som jeg umiddelbart synes det lyder som om >> det bliver gjort til. > > > Jeg håber jeg misforstår det skrevne. > > Det er for mig helt og aldeles uacceptabelt at eller andet script automatisk > genopretter adresse noder som jeg manuelt har slettet fordi jeg har > konstateret på stedet at adressen er fjernet. Jeg sletter ikke noder for at > påvirke statistikken, men for at afspejle virkeligheden. > > Hvis der er nogen der mener det er rimeligt at behandle mine opdateringer på > denne måde vil jeg behandle deres redigeringer med samme niveau af respekt. > > Carsten >
Hej Carsten Nu er addresse data jo ikke noget man nødvendigvis kan observere i virkeligheden, men noget reelt data som man kan addressere til. At der ikke står fire vægge på matriklen hvor addressel også ligger på er da ikke grund til at slette noden. Jeg kan i hvert fald ikke se logikken i det lige nu. Jeg kan have overset nogen diskussion om emnet, men jeg mener at det er reelt nok at en addresse eksisterer hvis den kommer fra BBR, og jeg synes det er mere hensigts mæssigt at lave et system til fejlmelding af addresse noder til kilden, end at slette elementer man ikke kan verificere på matriklen. Nick _______________________________________________ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
