Hurtowe psucie czy poprawianie mapy?

Przyglądam się czasem w statystykach osobom wysyłającym miliony nodów tzw “czyścicielom”, czy ich praca wnosi cokolwiek do mapy poza zmniejszaniem jej objętości.

Nie będę tu wymieniał wszelkich możliwości, bo nie czytam forum gdzie się uzyskuje akceptację dla działania takich skryptów.
Tak z grubsza to żaden automat nie zastąpi człowieka i nie ma prawa niczego prostować.
Można np. wyrzucić zdublowane nakładające się nody czy obiekty.
Można wyrzucić nieotagowane samodzielne nody ale tego wcześniej nie robiono co widać było np w Keepright. Widocznie komuś gołe nody mogły być przydatne np. jako znaczniki przy rysowaniu skomplikowanych kształtów, kalibracji itd.
Warto by automatem usunąć ogonki (przy prostokątach) bo wtyczka building_tolls słabo współpracuje z funkcją trasowania w JOSM i gdy np kąt prosty budynku minimalnie różni się od 90 stopni to przy przeciąganiu (trasowaniu ściany ) powstają 2 ogonki (czasem 1). Jest serwis, który wyłapuje takie ogonki ale skoro render mapy podstawowej (i inne) sobie z nim radzi to szkoda czasu na te poszukiwania.

Pytanie czy warto skryptem minimalnie odchudzić bazę z małego ułamka promila, skoro przy okazji można dużo napsuć?
Dotąd miałem zaufanie, że jeśli tym czyszczeniem zajmują się milionerzy to te skrypty są sprawdzone i zaakceptowane przez DWG.

Dopuszczam możliwość, że nowy skrypt coś namiesza i że szybko ktoś zgłosi jego wady i wycofają.
Jednak jeśli w jednym przejściu skrypt robi kilka rzeczy i popełnia 2-3 błędy (jeśli nie więcej) to zaczynam być przeciwnikiem przeorywania mapy w poszukiwaniu duperelków, które ani bazy nie odchudzą ani żadnemu renderowi czy innej funkcjonalności nie pomogą.

Mogę zrozumieć, że zepsuto coś czego się nie dało przewidzieć ale jeśli psuje się coś oczywistego co rozumie maper po 5 minutach od wejścia na OSM, to zaczynam się bać i zastanawiam się czy DWG nad tym panuje i czy część prac czyścicieli nie jest samowolką skoro są czynione przedszkolne błędy.

Parę dni temu zauważyłem że bardzo aktywny od dawna czynny turbomaper (nie wiedziałem że jest czyścicielem) uruchamia skrypt, który zmienia geometrię obiektów oraz grzebie w typowych tagach.

Nie chce się wierzyć, że ktoś tyka tak delikatnych kwestii i na dodatek robi to łącznie.
Już bez wnikania w materię nawet laik powie, że to niemożliwe i niedopuszczalne, bo musi narobić więcej szkód niż pożytku.Szkód wszystkich nie wymienię, bo skryptu nie analizowałem.

Weźmy sobie mapera z innego kraju, który zmieni wam tag source:geometry albo source:building.
W czym pomoże i w czym poprawi bazę?
Czy takie tagi są udziwnione?
Albo jeśli w skomplikowanym kształcie budynku będzie wam usuwał nody i to nie nody na prostej ale na łuku, czym diametralnie zmieni kształt obiektu?
Wydaje się to niedopuszczalne, bo w dobie micromappingu nie można mówić jakie odstępy nodów są dopuszczalne na obrysie.

Wczoraj widziałem prosty budynek, który dostał kształt łódki (skryptem) i już nie sprawdzałem, które nody skrypt poprzesuwał a co usunął , bo wiem że w tym changesecie ów czyściciel potraktował setki lub tysiące obiektów więc wiedza jak powyginał jeden budynek nie wyjaśni mi algorytmu skryptu. Zresztą kiedyś wpadłem na jego changeseta być może własnie tego i nie dało się go zrewertować zdaje się z powodu rozmiaru.
Budynek przerysowałem na nowo ale zastanawiam się ile takich powykoślawiał. Martwi mnie to szczególnie, bo w 2D pokrzywiony budynek dalej będzie budynkiem, ale w 3D drobna zmiana geometrii może spowodować złe współgranie płaszczyzn dachów a akurat wziąłem się za 3D.

Nie mam czasu na śledztwa w takich wielkich changesetach ale z grubsza można się domyślić na wskazanym przykładzie. Przyjrzyjcie się tym 3 słupom z prawej strony.Zostawiłem tylko 3 ( z 20-tu) i przesunąłem je na bok dla zobrazowania zmian więc proszę na razie nie kasujcie aby każdy zrozumiał jak można powyginać.
Filary miały okrągły kształt jak te wszystkie pozostałe, które wrysowałem na nowo.
Okrąg był zbudowany z 9 nodów a po przejściu skryptu okrągła kolumna zamieniła się w pięciokąt o nierównych bokach

http://demo.f4map.com/#lat=51.1078254&lon=17.0744313&zoom=21&camera.theta=40.989&camera.phi=-108.862

Czyli wyrzucając 4 nody z 9-ciu, pięć pozostawionych powinno stać w poprzednim miejscu i dać wielokąt foremny.
Nie pojmuję jak można i wywalać i przesuwać na złe miejsce. Chyba w tym changesecie lub sąsiednim (czyścicielskim) inny maper zwracał mu uwagę dlaczego myli tagi source z source:building i nie było ani odpowiedzi ani wycofania zmian.

Wiele osób nie czyta komentarzy do changesetów, bo co poniektórzy używają ich do publicznego wylewania frustracji, ale jeśli robi się tak wielkie zmiany to trzeba sprawdzać czy ktoś nie zgłasza problemów.

Nie sprawdzam innych przykładów choć widziałem wcześniej na pomorzu rzeczy które mnie zaniepokoiły choć poważnych szkód nie robiły.
Jednak jeśli ktoś zamiast mapować robi sobie zabawę z hurtowych zmian geometrii i tagów, to można powiedzieć, że jeśli skrypt jest do wszystkiego to jest do niczego. Hurtowe zmiany wzbudzają niepokój, bo trzeba sprawdzać kto i po co grzebie.
Jednak tak poważne błędy stawiają pod znakiem zapytania jakość innych hurtowych zmian. Dlaczego ten przypadek czy inne ma mnie zmuszać do poświęcenia prywatnego czasu na ponowne wrysowania?
Jak po czasie DWG ma zmienić takie zmiany gdy wiele obiektów zostało wrysowanych ponownie?

Czy istnieje jakiś mechanizm aby sprawdzać skutki mapowania botem? Czy jeśli ktoś grzebie w wielu krajach to czy społeczność nie powinna być o tym uprzedzana?
Przykładowo program powinien mnie poinformować, że skrypt zmienił kilka tysięcy moich obiektów z wyszczególnieniem kategorii zmian.
Może takie zmiany powinny być sygnalizowane na forach narodowych a tymczasem nie wiem czy była zgoda DWG, oraz czego jeszcze można się spodziewać w przyszłości.

Ciekawi mnie czy ktoś kiedykolwiek zauważył poprawę renderu czy innych funkcjonalności dzięki takim poprawiaczom?

Jak to bywa w podobnych przypadkach jestem w stanie się założyć, że i tu podobnie intencje twórcy skryptu były szczytne to zawsze pozostanie pytanie czy autorowi - nie chciało się / nie umiał / nie zdawał sobie sprawy z zagrożenia - skryptu rozbudować o kolejne warunki, które wykluczały by eliminacje poprawnie dodanych obiektów to bez względu na powody jest to kolejny dowód na to, że automatyzm musi być użyty z rozwagą.

IMHO istotne jest by zauważyć że nawet jak by automat rozbudować o kolejne tysiąc przypadków to jestem przekonany, że jednak w 100% nie wyeliminuje błędów i nadmiarowych interwencji. Niniejszym niezbędne jest posiadanie możliwości otrzymania zautomatyzowanej informacji o zmianach we wprowadzonych przez siebie obiektach by w razie czego móc zainterweniować, a działanie samego skryptu prześledzić co do innych wykonanych zmian czy również nie miał destrukcyjnego efektu w innych miejscach.

Czym się zajmuje ten maper?
https://www.openstreetmap.org/changeset/46822260

Wykorzystuje maproulette do zmian w całej Europie.
Chodzi o samo przecinające się relacje?
Skrypt usuwa zdublowane budynki przykładowo budynek jako relacja składający z pociętego obrysu na dwa outer.
Jakiś magik zresztą nie jedyny w Polsce tak rysuje budynki.
Ale skrypt jest taki mądrym że wie które budynki usunąć z tych zdublowanych.
Na dodatek integruje adresy z obrysami ale o tym sza w opisie changeseta.

Pytam, bo mam obawy w sprawie usuwania np. ogonków od budynków, czy budynków na budynku (lub w budynku).
Pisałem ostatnio w wątku o dokładności zapisywania obiektów w bazie że w związku z zaokrągleniem geolokalizacji nodów do 7 miejsc w bazie OSM, obiekty jakie rysujemy w josmie potrafiącym rysować z dokładnością do 11 miejsc po przecinku powoduje że np narożniki budynkowi są automatycznie przesuwane do rastra czyli pewnej siatki przecinających się linii.
Oznacza to, że żaden budynek nie ma kątów prostych no chyba ze jego ściany są dokładnie poziome i pionowe czyli trzymają azymut 0 i 90 stopni

Każdy obiekt ma nody w innym miejscu niż je narysowaliśmy a zniekształcenia geometrii np, kątów są tym większe im mniejszy obiekt.
Szczególnie to dotyczy tak małych obiektów jak np. filary czy słupy.

Daje to różne efekty np. dwa budynki przylegające do siebie mogą się przecinać.
Albo jeśli zapiszmy prostokątny obiekt to on w bazie już nie jest prostokątny i jeśli przesuwamy ścianę tzn trasujemy funkcją X to budynek może dostać ogonki a w pewnych sytuacjach obrys może się sam przecinać np. po użyciu funkcji (shift+P) .

Często takie przecinania się budynków są tworzone celowo albowiem aby uzyskać efekt trójwymiarowy wielu przesuwa obrys budynku tak aby wystający dach załapał się jeszcze w obrysie podstawy.
Często robi się tak aby się linie nie sklejały tym automatycznym mechanizmem przesuwania linii czyli nodów do rastra siatki to linie wewnątrz budynku a opisujące części budynku jako building:part leżące bardzo blisko obrysu budynku,celowo nie skleja się tych linii aby odwzorować kilka pieter budynku w 3D .

Rysuje się je możliwie blisko np w odległości 1.5 -3 cm aby nawet gdy automat po zapisie przesunie nody ok 11 mm,te linie się nie przecięły ani nie skleiły a można było je zaznaczać bez odklejania przy kolejnych edycjach…

Skoro rendery 2D radzą sobie małymi ogonkami czy z lekko nachodzącymi na siebie budynkami np. na 2 cm, to bezsensowne wydaje się stosowanie automatów do zmniejszania ilości nodów, usuwania ogonków (czy co tam jeszcze), bo może spowodować przesunięcie linii większe niż 11 mm.

Powoduje to przy kolejnych zapisach że pozostawione przez skrypt nody znów będą przesunięte do rastra a i te nody które będą w rastrze, po skasowaniu ogonka spowodują że linie będą łączyć teraz inne nody tzn, że linie dostana inne kąty czyli się trochę przesuną.

Jeśli przesunie się zewnętrzną linię building=yes a na starym miejscu pozostawi wewnętrzną linię building:part to oczywiste, że mogą się przeciąć, a to oznacza, że model 3D się rozsypie gdyż jak pisałem części składowe budynku nie mogą wychodzić poza jego obrys gdyż render 3D je pominie.

Dodatkowo widzę, że w wielu krajach stosuje się mapowanie uproszczone 3D tzn budynki wewnątrz większych budynków nie są przerabiane na building:part podobnie jak część budynków jest dzielona na pół aby odwzorować ze są to różne wysokosci (coś jakby przybudówki)
Są też i inne powody subtelniejsze ale wystarczą powyższe do postawienia tezy że zmienianie geometrii automatem nawet minimalne w granicach 1 cm psuje zamysł autora obiektu czyli psuje mapę i bazę.

Może to miało sens kiedyś ale nie w dobie mikro mapowania i 3D.
Nie wiem czy ów maper robi to skryptem, bo wysyła w drobnych changesetach pojedyncze zmiany ale widząc w ilu krajach mapuje mam podejrzenia że pracę automatyzuje.

Jeśli robi to ręcznie to i tak bardzo dziwne, bo robiąc to na całym świecie w 149 krajach marnuje swój czas.
Dlaczego przy dublach kasuje pierwszą wersję obiektu a zostawia ostatnią mimo że tę ostatnią poprawia bo maproulette wskazuje mu ją jako błędną?

Kto takie akcje inicjuje jeśli to nie jest jakaś idee fixe pojedynczego mapera?

Oczywiście moje obawy w tym przypadku mogą być na zapas i gdyby dotyczyły 2D to podniósłbym larum dopiero przy szkodach ale zamierzam robić w 3D misterne modele nawet z dokładnością rysowania 2 mm co nie byłoby trudne jeśli nie trzeba było się wpisać w raster 11 mm jaki oferuje baza OSM.
Taki obiekt można rysować wiele dni stosując dziesiątki, setki a nawet tysiące parametrów czy to z pomiarów w realu i zdjęć, czy to z interpolacji czyli wyliczeń wymiarów z proporcji w arkuszu kalkulacyjnym.
Często przy takim modelowaniu trzeba ze sobą skleić kilka warstw i jeśli ktoś lub skrypt coś tam zamiesza to odklejanie czyli dokopanie się do linii pod innymi liniami jest trudne i przypomina poprawianie dolnej karty w domku z kart.

Przy mojej słabej znajomości języków trudno jest mi doszukać się na forach jaka potrzeba ludźmi kieruje, że zamiast mapować sterują robotami. Dodatkowo zaniepokoiło mnie, że JOSM jakoś integruje się z maproulette w ostatniej wersji, czyli że pewne działania nie będą nadzorowane czy inspirowane przez DWG a mogą być nieudanymi testami tej funkcjonalności.

Tak to hazardzisci z maproulette zaczynają harce
http://www.openstreetmap.org/way/336753148

Czym się zajmuje ten maper?
https://www.openstreetmap.org/changeset/46822260

Wykorzystuje maproulette do zmian w całej Europie.
Chodzi o samo przecinające się relacje?
Skrypt usuwa zdublowane budynki przykładowo budynek jako relacja składający z pociętego obrysu na dwa outer.
Jakiś magik zresztą nie jedyny w Polsce tak rysuje budynki.
Ale skrypt jest taki mądry, że wie które budynki usunąć z tych zdublowanych.
Na dodatek integruje adresy z obrysami ale o tym sza w opisie changeseta.

Pytam, bo mam obawy w sprawie usuwania np. ogonków od budynków, czy budynków na budynku (lub w budynku).
Pisałem ostatnio w wątku o dokładności zapisywania obiektów w bazie że w związku z zaokrągleniem geolokalizacji nodów do 7 miejsc w bazie OSM, obiekty jakie rysujemy w josmie potrafiącym rysować z dokładnością do 11 miejsc po przecinku powoduje, że np narożniki budynków są automatycznie przesuwane do rastra czyli pewnej siatki przecinających się linii.
Oznacza to, że żaden budynek nie ma kątów prostych no chyba ze jego ściany są dokładnie poziome i pionowe czyli trzymają azymut 0 i 90 stopni

Każdy obiekt ma nody w innym miejscu niż je narysowaliśmy a zniekształcenia geometrii np. kątów są tym większe im mniejszy obiekt.
Szczególnie to dotyczy tak małych obiektów jak np. filary czy słupy.

Daje to różne efekty np. dwa budynki przylegające do siebie mogą się przecinać.
Albo jeśli zapiszmy prostokątny obiekt to on w bazie już nie jest prostokątny i jeśli przesuwamy ścianę tzn trasujemy funkcją X to budynek może dostać ogonki a w pewnych sytuacjach obrys może się sam przecinać np. po użyciu funkcji (shift+P) .

Często takie przecinania się budynków są tworzone celowo albowiem aby uzyskać efekt trójwymiarowy wielu przesuwa obrys budynku tak aby wystający dach załapał się jeszcze w obrysie podstawy.
Często robi się tak aby się linie nie sklejały tym automatycznym mechanizmem przesuwania linii czyli nodów do rastra siatki to linie wewnątrz budynku a opisujące części budynku jako building:part leżące bardzo blisko obrysu budynku,celowo nie skleja się tych linii aby odwzorować kilka pieter budynku w 3D .

Rysuje się je możliwie blisko np w odległości 1.5 -3 cm aby nawet gdy automat po zapisie przesunie nody ok 11 mm,te linie się nie przecięły ani nie skleiły a można było je zaznaczać bez odklejania przy kolejnych edycjach. Minimalizuje się te odległości bliskich poligonów aby nie było brzydkich szczelin podczas renderowania 3D.

Skoro rendery 2D radzą sobie małymi ogonkami czy z lekko nachodzącymi na siebie budynkami np. na 2 cm, to bezsensowne wydaje się stosowanie automatów do zmniejszania ilości nodów, usuwania ogonków (czy co tam jeszcze), bo może spowodować przesunięcie linii większe niż 11 mm.

Powoduje to przy kolejnych zapisach że pozostawione przez skrypt nody znów będą przesunięte do rastra a i te nody które będą w rastrze, po skasowaniu ogonka spowodują że linie będą łączyć teraz inne nody tzn, że linie dostana inne kąty czyli się trochę przesuną.

Jeśli przesunie się zewnętrzną linię building=yes a na starym miejscu pozostawi wewnętrzną linię building:part to oczywiste, że mogą się przeciąć, a to oznacza, że model 3D się rozsypie gdyż jak pisałem części składowe budynku nie mogą wychodzić poza jego obrys gdyż render 3D je pominie.

Dodatkowo widzę, że w wielu krajach stosuje się mapowanie uproszczone 3D tzn budynki wewnątrz większych budynków nie są przerabiane na building:part podobnie jak część budynków jest dzielona na pół aby odwzorować ze są to różne wysokości (coś jakby przybudówki)
Są też i inne powody subtelniejsze ale wystarczą powyższe do postawienia tezy że zmienianie geometrii automatem nawet minimalne w granicach 1 cm psuje zamysł autora obiektu czyli psuje mapę i bazę.

Może to miało sens kiedyś ale nie w dobie mikro mapowania i 3D.
Nie wiem czy ów maper robi to skryptem, bo wysyła w drobnych changesetach pojedyncze zmiany ale widząc w ilu krajach mapuje mam podejrzenia że pracę automatyzuje.

Jeśli robi to ręcznie to i tak bardzo dziwne, bo robiąc to na całym świecie w 149 krajach marnuje swój czas.
Dlaczego przy dublach kasuje pierwszą wersję obiektu a zostawia ostatnią mimo że tę ostatnią poprawia bo maproulette wskazuje mu ją jako błędną?

Kto takie akcje inicjuje jeśli to nie jest jakaś idee fixe pojedynczego mapera?

Oczywiście moje obawy w tym przypadku mogą być na zapas i gdyby dotyczyły 2D to podniósłbym larum dopiero przy szkodach ale zamierzam robić w 3D misterne modele nawet z dokładnością rysowania 2 mm co nie byłoby trudne jeśli nie trzeba było się wpisać w raster 11 mm jaki oferuje baza OSM.
Taki obiekt można rysować wiele dni stosując dziesiątki, setki a nawet tysiące parametrów czy to z pomiarów w realu i zdjęć, czy to z interpolacji czyli wyliczeń wymiarów z proporcji w arkuszu kalkulacyjnym.
Często przy takim modelowaniu trzeba ze sobą skleić kilka warstw i jeśli ktoś lub skrypt coś tam zamiesza to odklejanie czyli dokopanie się do linii pod innymi liniami jest trudne i przypomina poprawianie dolnej karty w domku z kart.

Przy mojej słabej znajomości języków trudno jest mi doszukać się na forach jaka potrzeba ludźmi kieruje, że zamiast mapować sterują robotami. Dodatkowo zaniepokoiło mnie, że JOSM jakoś integruje się z maproulette w ostatniej wersji, czyli że pewne działania nie będą nadzorowane czy inspirowane przez DWG a mogą być nieudanymi testami tej funkcjonalności.

Tak to hazardzisci z maproulette zaczynają harce
http://www.openstreetmap.org/way/336753148