[Polska] Propozycja automatycznego usunięcia klucza created_by

Communities Polska (Poland)
1

Chciałbym usunąć klucz created_by ze wszystkich obiektów znajdujących się w Polsce.
Klucz ten ma status discardable sugerujący aby takie wejścia usuwać.

Aktualna liczba obiektów to 17.6k.

Proces usuwania byłby iteratywny, zaczynaszwy od JOSM. Po usunięciu created_by=JOSM przeanalizuję popularność pozostałych wartości i ponowię proces usuwania. Zależy mi tutaj na tym, aby usunąć wartości te, które pochodzą od znanych edytorów. Jeśli jakiś użytkownik dodał tag created_by mając na myśli co innego, zostanie to wykryte.

4 Likes
2

Nie protestuje, ale to jest coś co jest przez edytory ukrywane i automatycznie usuwane przy innych edycjach.

3

O dziwne, bo ja właśnie to w iD zauważyłem jak edytowałem tagi przejścia :stuck_out_tongue:.

4

hmm, może bug w iD? Albo tam był jakiś ekstra znak?

5

Ekstra znaku raczej nie zauważyłem. A bug w iD jak zawsze możliwy. Ale jeśli raz na zawsze pozbędziemy się tego tagu to wszystkim wyjdzie na dobrze. Nie tylko aktualnym projektom, ale również przyszłym.

6
1 Like
7

Aktualna liczba obiektów to 17.6k.
Wg taginfo >20k (ciekawe z czego wynika różnica).

Ogólnie takich kluczy jest więcej, choć akurat nie wszystkie występują w Polsce. U nas jeszcze jest bardziej widoczny odbl wg taginfo >1.2k.

Nie bez powodu są jednak oznaczane jako discardable – właśnie tak jak napisał Mateusz, żeby edytory mogły je usuwać same (po cichu) przy okazji np. w JOSMie się nie wyświetlają w tabelce tagów, ale zmiana je usuwa.

Takie założenie nie podbija sztucznie historii obiektu – w zasadzie pewnie to jest jedyny powód dla którego nie zostało to automatycznie usunięte wszędzie. W skali globalnej jednak to już są miliony(created_by, tiger:*) i jak każdy kraj zacznie tak usuwać, to efekt będzie podobny.

Pomijając sztuczne zmiany, to zostawienie tego ma taką zaletę, że istnieją narzędzia, które pokazują obszary dawno niemapowane. Dotykając takich obiektów mocno je odfiltrujemy na kolejne lata (niestety).

Ogólnie to te tagi jakoś mocno nie przeszkadzają, gdyby było inaczej, to by dawno zostały usunięte :wink:

Patrząc na to z innej strony:

Spojrzałem sobie na swoją okolice, którą intensywnie mapuję i sporo ich widzę. Kawałek ścieżki, którą edytowałem jakiś czas temu nadal to posiada. Wynika to z tego, że modyfikowałem linię, a nie węzły, więc na nich to zostało.
To jest problematyczna rzecz do przemyślenia, czy może nie warto spróbować zaostrzyć reguły usuwania przez edytory (zamiast usuwać jednorazowo – patrząc globalnie). Np. żeby w przypadku modyfikacji linii sprawdzone też zostały wszystkie węzły. Na pewno zwiększyłoby to zestawy zmian, ale pewnie przyśpieszyłoby to również pozbywanie się ich.

Jeśli mimo wszystko mielibyśmy usuwać te tagi, to bym nieco przefiltrował dane:

  • tylko z węzłów
  • obiekt nie może posiadać innych tagów (np. mamy 400+ obiektów highway) – w ten sposób odfiltrujemy obiekty, które pewnie powinny zostać przejrzane. Tu potencjalne kombinacje.

Resztę można by spokojnie wrzucić nawet w jakieś maproulette jak by ktoś miał chęć “Przegląd starych obiektów”, albo zostawić tak jak teraz :slight_smile: W sumie to maproulette można i teraz z tego zrobić do “nie węzłów”.

Moja propozycja jest następująca, aby najpierw mimo wszystko spróbować przynajmniej dla JOSMa i iD założyć issue/ticketa i spróbować zaostrzyć reguły usuwania tych tagów – żeby działało to bardziej zaraźliwie, bo to węzły stanowią problem. Dopiero w przypadku odmowy/braku poparcia społeczności rozważałbym usunięcie ich z powyższych kryteriów jakimś botem, albo i po prostu zostawienie jak jest ze względu na praktycznie zerową szkodliwość.

Na koniec warto pewnie jeszcze wrzucić statystyki na wykresie:

image
image1152×430 31.4 KB

Globalne jest tutaj: created_by | Keys | OpenStreetMap Taginfo

2 Likes
8

Mam kilka przemyśleń na temat argumentu wzbraniającego automatycznych edycji, ponieważ podbijają one datę edycji. Jak dla mnie, to że, jakieś oprogramowanie nie radzi sobie z przetworzeniem takiej informacji, nie jest wystarczającym argumentem. Tak jak nie mapujemy pod render, nie powinniśmy mapować pod aplikację. Ja osobiście nie widzę powodu, dla którego te aplikacje nie mogłyby korzystać z bardziej zaawansowanej logiki sprawdzania aktywności, niż samej daty ostatniej zmiany. Przykładem byłoby tutaj sprawdzanie diffów, utworzonych przez Overpass-a.

Aktualne podejście do tego problemu sprawia, że ogranicza się możliwości edycyjne na dużą skalę, ale również jest bardzo prosto wandalizowane. Przykładowo, ostatnio ktoś masowo usuwał klucze name:ru z Ukrainy, podbijając datę edycji bardzo wielu obiektów. Zmiany te zostały wycofane, ale jedna rzecz jakiej nie da się wycofać to właśnie wersja obiektu oraz data edycji. Uważam że aplikacje które za mocno opierają się na jednej z tych 2 wartości (których nie da się revertować), powinny przemyśleć swoją implementację.

Jakakolwiek zmiana automatyczna podbija datę edycji okolicy. Np. automatyczny import budynków działa na obszarze całej Polski bez wyjątków. Czy więc wypadałoby zaprzestać takim automatycznym edycjom, ponieważ niektóre oprogramowanie nie radzi sobie z tym? Uważam że nie, i argument ten stagnuje rozwój OSM. Ten “bug” powinien zostać naprawiony w aplikacji, a nie bezpośrednio na danych.

9

Myślę, że tutaj głównym argumentem przeciwko usunięciu takich tagów jest tworzenie kolejnych wersji obiektów na OSM które zwiększają rozmiar bazy OSM, przy masowej edycji, może być to znaczące zwiększenie, a jako, że tag jest raczej neutralny, nie widzę sensu jego automatycznego usuwania.

1 Like
10

Te tagi są zupełnie bezużyteczne, jak dla mnie można je od strzała usunąć.

A tak pytając trochę obok - jakie jest wasze zdanie o kluczach addr:city:simc=* i addr:street:sym_ul=*?

Są redundantne wobec zwykłych addr:*=*, są w sprzeczności z ogólną zasadą “human readable” na OSM - potrzebujemy ich w ogóle?

11

I tak i nie.

Tak - zwiększy się historia obiektów, a za tym full-history planet dump. Co ważne tych obiektów jest 17k więc skala jest nieznaczna. To niecałe 2 pełne zestawy zmian.

Nie - zmniejszy się ilość danych w aktualnym planet dump. Czyli tym, zachowującym tylko ostatnią wersję obiektów (będzie mniej zbędnych tagów). Tutaj argument o skali też się aplikuje, różnica będzie nieznaczna.

1 Like
12

Ja osobiście nie widzę sensu w tym tagowaniu. Jest to ciężkie w utrzymaniu, brakuje toolingu, a użyteczności nigdy nie zauważyłem ale może nie miałem okazji.

1 Like
13

nie protestował bym, byłbym chyba za, ale nie jestem na tyle pewien by usuwać samemu

jak mają sens to warto opisać na Key:addr:city:simc - OpenStreetMap Wiki jaki (lub zrobić polską wersję)

2 Likes
14

addr:street:sym_ul – usuwam przy okazji.
Kompletnie bezużyteczny, mało tego mamy pewnie pełno błędnych sym_ul, których nikt nie waliduje/nie poprawia. To miałoby sens, gdyby 1 nazwa ulicy miała unikatowy kod globalnie np. Chopina miałaby w każdym mieście to samo id – tak nie jest…
albo gdyby przynajmniej to id było lokalnie przypisane do ulicy jako miejsca, a tak również nie jest…
tj. zmiana nazwy ulic, to aktualnie zmiana tego id – dlatego jest to kompletnie bezwartościowe.
Musiałby dodatkowy bot to weryfikować na bieżąco, ale nie widzę w tym sensu i zgadzam się, że jest to trudne w utrzymaniu.

Można zerknąć (odnośnie tego powyżej) tutaj.

Ten temat się chyba przewijał chyba kilka razy co najmniej. @RicoElectrico coś o tym pisał wcześniej jeśli dobrze pamiętam.
Aktualnie status tego klucza to deprecated, więc nawet go nie powinniśmy dodawać, a przynajmniej większość go już nie dodaje i ten klucz powoli jest usuwany.

https://wiki.openstreetmap.org/wiki/Key:addr:street:sym_ul

addr:city:simc – uzupełniam zawsze.
Jest to ref urzędowy jakby nie patrzeć, ale ma o wiele więcej sensu niż ten wyżej. Mamy tu zakodowane i województwo i gminę i jej rodzaj i miejscowość w 1. To bardzo przydatne jak ktoś bazuje analizy w oparciu o dane z OSM, a nie GUGiK. W dodatku nie zmienia się losowo.
https://pl.wikipedia.org/wiki/SIMC

Na discordzie padł słuszny argument o tym, że nie wszędzie są uzupełnione granice wsi, a że mamy różne tagowania adresów, raz addr:place, raz addr:city to daje stały wyznacznik do choćby przetwarzania i analizy adresów dzięki swojej niezmienności.
Łatwiej się również dzięki temu edytuje – filtrowanie jest znacznie prostsze. Inna kwestia, że to dodatkowa walidacja pod literówki/błędne zmiany addr:city/addr:place, czy niepełności adresów.
Czasem trafią się też adresy ze “świadomie” błędną miejscowością, mimo, że leżą na innym obszarze, bo tak urząd zarządził, to wtedy też daje dodatkową pewność.

Nie zgodzę się z tym, że jest ciężki w utrzymaniu. Większość adresów i tak pochodzi z importów, więc jak dla mnie nie ma z nim najmniejszego problemu. W swoim powiecie uzupełniłem wszystkie jakiś czas temu.

W sumie to nie wiem jak wygląda proces dodawania discardable tagów, ale może moglibyśmy ten 1 wrzucić skoro i tak jest deprecated?

15

Edytory jak JOSM dodają je do listy automatycznie usuwanych tagów które nawet nie są pokazywane ludziom.

https://wiki.openstreetmap.org/wiki/Discardable_tags

16

To wiem, bardziej mi chodziło, czy musielibyśmy to jakoś przegłosować? Czy po prostu możemy sobie zedytować wiki i zrobić ticket/issue w repo wybranych edytorów?

17

Ja bym otworzył temat. Głosowanie raczej zbędne ale przed masowym usuwaniem warto się ludzi zapytać czy to na pewno dobry pomysł.

1 Like
18

I dlatego moim zdaniem nie ma sensu tego usuwać.

Natomiast sens ma usunięcie z całej Polski tagów source ze starych importów z UMP.
Przyklad: “source=UMP-PL, ./UMP-Szczecin/src/inne.ulice.txt”
Dużo tego, a od czasów tego importu prawie każda droga była już przez kogoś “dotknięta”, wiec to ogólne source prawdziwe nie jest.

11 Likes