Sprawdzenia te należałyby do innej kategorii i zawierały by one inne treści komentarzy.
Niektóre sprawdzenia wykonywane byłyby tylko na starszych użytkownikach, aby nie straszyć nowych. Np. jednym z takim sprawdzeń byłoby poprawność tagu opening_hours.
Ostatnie sprawdzenie (błędne opisywanie zestawów zmian) zawierałoby listę (+może jakieś proste filtry), wykrywające błędne opisanie zmian: np. “”, “.”, “zmiana”, “poprawka”, itp. Listę rozszerzałbym na bieżąco podczas mojego sprawdzania zmian u nowych użytkowników. Lista będzie bardzo bezpieczna, w sensie, bardzo mi zależy aby nie zawierała ona żadnych false-positiveów. Dodatkowo, to konkretne powiadomienie nie będzie wysyłane pod każdą zmianą, a maksymalnie raz na np. 1-2 tygodnie.
Tak jak w przypadku adresów, powiadomienie będzie wysłane tylko kiedy dany użytkownik dokona błędu, a nie zedytuje obiekt w jakiś inny sposób.
Proszę o waszą opinię oraz o ewentualne sugestie co do dodatkowych sprawdzaczy.
Tworzysz niezły kombajn Kolego!! Jeżeli nie będzie false-positive to na pewno narzędzie będzie bardzo przydatne. Nie jestem pewny, czy autor błędu będzie chętny do jego naprawy, szczególnie gdy będzie to jego 5 edycja w życiu. Jednak changesety z uwagami wpadają do RSSa na Discordzie i ktoś inny będzie mógł pomóc w eliminacji tego błędu.
Osobiście jestem jak najbardziej za takimi narzędziami, które dodatkowo w zrozumiały sposób zwracają uwagę na popełnione błędy. Będzie to takie małe Osmose skupione na changesetach
Jeśli za wczasu wskażemy błędy to będzie to szybka nauka dla edytującego. Zmniejszy się ilość osób która edytuje masowo a potem okazuje się że spora część wymaga poprawek.
Co do zestawów, to proszę o zaufanie. Lista będzie zawierała tylko naprawdę najgorsze opisy . A co do podjazdów - podasz jakiś przykład? Może dałoby radę odfiltrować takie przypadki, bo uważam że jest to dosyć częsty błąd nowych i fajnie byłoby ich o tym powiadamiać. Maxspeed tyczy się np. poprzednia kombinacja jest logicznie poprawna → nowa kombinacja jest nielogiczna (np nowa to 20 + source:maxspeed=PL:urban).
Pytanie, czy nie warto by tego rozszerzyć o highway=track Wydaje mi się (ale nie przyznają sobie w tym temacie absolutnej racji), że jeśli droga ma oficjalną nazwę (więc można przy niej wyznaczać adresy), o powinna być przynajmniej service, jeśli nie residential.
A może za ciosem zrobić walidację takich kombinacji jak tracktype z nawierzchniami niepasującymi do typu (np tracktype=grade1 i surface=gravel, tracktype=2 i surface=sand)?
Są adresy przy obiektach, które nie istnieją, a więc nie prowadzi do nich nawet ścieżka, są też obiekty z adresem, do których prowadzi ścieżka. Co prawda to margines, ale tego typu obiektów nie brakuje.
Nie mam żadnych uwag, podoba mi się. Można jeszcze do przedrostków dodać al., 'pl., a oprócz opening_hours sprawdzać syntax w tagach *:conditional=*
Chcesz sprawdzać czy jest http:///https:// z przodu? Przy obrabianiu danych urzędowych znalazłem sporo danych bez wypełnionego protokołu - importowałem je zaczynając od części www..., często też spotykam takie tagi w OSM. No i czy różne wartości mogą być tu rozdzielane średnikiem?
Zdarzają się wartości typu phone=+48 123 456 789 (wewn. 2) - tutaj trzeba by przygotować jasne instrukcje jak to poprawnie oznaczać.
Nie rozumiem - sprawdzanie czy istnieje?
Ja bym był łagodny w tej kwestii, skoro można wysłać nawet bez opisu, to bym nie krzyczał na krótkie opisy - już prędzej na odniesienia do innych źródeł z których korzystać nie możemy (Streetview itp.).
Jeśli ktoś olał ostrzeżenie w edytorze, to tutaj też pewnie nic z tym nie zrobi, ale dodać chyba nie zaszkodzi.
To też uważam że nie jest dobry pomysł, na pewno gdzieś taka sytuacja będzie poprawna. Może da się znaleźć ew. utworzony fragment ulicy bez nadanej nazwy, przylegający z obu stron do ulic z takimi samymi nazwami?
Dodałbym też sprawdzanie czy name=* jest takie samo jak name:pl=* - w takiej sytuacji jest niepotrzebne.
I może w ogóle spróbować przygotować listę nazw opisowych, o których też można by ostrzegać?
Pamiętaj też o synonimach tagów - przedrostku contact:* i url oprócz website.
Myślę że opening_hours są na tyle skoplikowane, że nie męczyłbym nowych użytkowników komentarzami na ten temat. Zwłaszcza, że i tak nie wytłumaczysz tego w komentarzu tak żeby było krótko i sensownie. Wewnętrzny bot, który by to sprawdzał - ok, ale komentrze bym darował.
Jak chodzi to bota do komentarzy to w zasadzie zależy jak on miałby działać. Komentarz “drobne poprawki” może być poprawny, jeśli faktycznie poprawiłeś kilka drobnych rzeczy, ale nie będzie poprawny jeśli zmienisz autostradę w drogę polną. Jak dla to ten to bot powinien raczej sprawdzać czy ktoś nie wpisuje wszędzie tego samego komentarza. Jedna zmiana o tytule “Aktualizacja” może być poprawna, ale jak ktoś ma 10 zmianę o treści “Aktualizacja” pod rząd, to coś jest nie tak.
A jak o drogi serwisowe chodzi to one mogą mieć nazwy, np. Mieczykowa w Krakowie Way: Mieczykowa (48552325) | OpenStreetMap
Droga w 100% na zamkniętym osiedlu, więc kategoria jest dobra, ale adresy są “Mieczykowa” więc na drodze nazwa też musi być.
Akurat wg Geoportalu ta droga https://www.openstreetmap.org/way/48552325 nie ma nazwy. Zakładam, że nie ma też w rzeczywistości, bo skoro miasto nie nadało nazwy, to kto by miał powiesić tabliczkę z nazwą ulicy?
To że przy tej drodze stoją domy z określonym adresem nie oznacza, że ulica musi mieć taką nazwę. Nazwa ulicy a adres domu, który jest przy tej ulicy, to dwie różne rzeczy.
Staram się poprawiać takie miejsca jak to, tu też nazwy zmieniłbym na to jak jest w danych urzędowych - nie powinno to już popsuć wyszukiwania adresu w Nominatim.
Chyba że to jakiś hack związany z wyszukiwaniem adresów? Może ktoś z większym stażem w OSM ma więcej wiedzy?
Ale przykładów service=driveway z name jest dużo, np.
Byłbym ostrożny ze sprawdzaniem składni adresów ww, godzin otwarcia i telefonów. Zależy, co chcesz uznawać za niepoprawne. Niektóre edytory same formatują wartości tych tagów do niekompatybilnych względem siebie form kanonicznych i to nawet gdy mapujący nie rusza danej wartości. Co miałby w takiej sytuacji zrobić?
Na pewno dobrze sprawdziłeś? Sprawdziłem geoportal - Mieczykowa jest jak byk. (No może nie na tym kikucie który podlinkowałem, ale to byłoby czepialstwo, bo ta droga która ma oficjalnie nazwę to też service)
. A co do podjazdów - podasz jakiś przykład? Może dałoby radę odfiltrować takie przypadki, bo uważam że jest to dosyć częsty błąd nowych i fajnie byłoby ich o tym powiadamiać. Maxspeed tyczy się np. poprzednia kombinacja jest logicznie poprawna → nowa kombinacja jest nielogiczna (np nowa to 20 + source:maxspeed=PL:urban).
