Pomijanie części zmian w tagach w określonych sytuacjach

[maraf24]

Proponuję dwie zmiany w działaniu pluginu:

Gdy aktualizuje się już istniejący w OSM budynek:

• pomijanie zmiany tagu building=yes na bulding=garage, gdyż wcale to nie musi być garaż.
  Przykład - https://www.openstreetmap.org/way/889619314 - jest to budynek stacji kontroli pojazdów.

W każdej sytuacji:

• pomijanie wszelkich tagów amenity/leisure/tourism, gdyż nie muszą być one prawdą w dniu wykonywania edycji.

[praszuk]

W każdej sytuacji:

pomijanie wszelkich tagów amenity/leisure/tourism, gdyż nie muszą być one prawdą w dniu wykonywania edycji.

W teorii nic nie musi być prawdą, ale jedno ze źródeł mówi, że jednak prawdą może być, więc bym go nie ignorował od tak, co nie oznacza oczywiście, że zawsze jest to w 100% prawdziwe. Dla tagów nietypowych lub/i specyficznych wyświetlam celowo dodatkowy komunikat, aby mapujący zwrócił na to uwagę i przypadkiem nie pominął.

W pluginie nie dodaję takich tagów. Aktualnie te dane są tożsame z tym co jest na stronie budynków z danych BDOT.
Jeśli uważasz, że któreś jest błędnie przypisane np. building=garage, to proponuję zmianę u źródła w pliku mapującym BDOT->OSM.

Gdy aktualizuje się już istniejący w OSM budynek:

pomijanie zmiany tagu building=yes na bulding=garage, gdyż wcale to nie musi być garaż.
Przykład - https://www.openstreetmap.org/way/889619314 - jest to budynek stacji kontroli pojazdów.

W ten sposób zaktualizujemy budynek tylko częściowo, co jeśli jednak aktualne dane są mało dokładne i np. jest building=yes, a jak najbardziej mogłoby być building=house, albo nawet i jest pierwotnie błędnie oznaczony jako zupełnie inny typ budynku?

Rozumiem, że chodzi Ci o możliwość np. aktualizacji samej geometrii (bez podmiany tagów)? Jeśli tak, to mam tę funkcjonalność zaplanowaną, ale dopiero za jakiś czas.

[maraf24]

W teorii nic nie musi być prawdą, ale jedno ze źródeł mówi, że jednak prawdą może być, więc bym go nie ignorował od tak, co nie oznacza oczywiście, że zawsze jest to w 100% prawdziwe.

To nie tak.
Mamy do czynienia z importem, czyli przy najmniejszej wątpliwości dane należy pominąć lub dać decydować człowiekowi.
Do tego to BDOT, z definicji mało aktualny.
A informacja o budynku, że to jest budynek stacji kontroli pojazdów, nie ma związku z tym, czy ta stacja działa czy nie. Nawet przy niedziałającej stacji ta informacja jest prawdziwa - w BDOT, ale nie jest prawidziwa w OSM.
Dlatego te wszystkie amenity/leisure/tourism należy zawsze pomijać.

Błąd oczywiście na stronie z Budynkami, które te tagi dodają, ale skoro ten plugin jest stamtąd pobiera, to odpowiedzialność spada także ... na plugin.

Najrozsądniej jest taką informację wpisać w inny tag, np. building:description.

Dla tagów nietypowych lub/i specyficznych wyświetlam celowo dodatkowy komunikat, aby mapujący zwrócił na to uwagę i >przypadkiem nie pominął.

Chodzi pewnie o "Detected uncommon tags[...]".

Dla mnie ten komunikat jest dezorientujący, nie wiem co to są nietypowe tagi. Może dałoby się chociaż wymienić, o które tagi chodzi? Czy wręcz pokazać w tym komunikacie jakie zmiany zaszły? Np. "building=yes -> building=garage"?

W pluginie nie dodaję takich tagów. Aktualnie te dane są tożsame z tym co jest na stronie budynków z danych BDOT.

Wiem. Dlatego proponuję ich pomijanie przez plugin.
Błąd w źródle danych nie powoduje, że problemu tutaj nie ma :)

Jeśli uważasz, że któreś jest błędnie przypisane np. building=garage, to proponuję zmianę u źródła w pliku mapującym >BDOT->OSM.

Masz rację, to jest ewidentnie złe przypisanie w tym pliku. Być może chodzi tutaj o "garage" w sensie warsztat - tyle że to nie jest definicja osmowa.
Tam takich błędów z garage jest więcej.

Gdy aktualizuje się już istniejący w OSM budynek:
pomijanie zmiany tagu building=yes na bulding=garage, gdyż wcale to nie musi być garaż.
Przykład - https://www.openstreetmap.org/way/889619314 - jest to budynek stacji kontroli pojazdów.

W ten sposób zaktualizujemy budynek tylko częściowo, co jeśli jednak aktualne dane są mało dokładne i np. jest >building=yes, a jak najbardziej mogłoby być building=house, albo nawet i jest pierwotnie błędnie oznaczony jako zupełnie >inny typ budynku?

Urok importu. Dane zastane mają wyższą wartość od danych importowanych. Należy dane z importu zignorować lub spytać się użytkownika.
Czasem się przecież pojawia okienko z listą tagów. Już się nauczyłem wówczas sprawdzać wartość building. Z jakichś powodów przy wskazanym budynku kontroli pojazdów się ono nie pojawia i nie zorientowałem się, że nastąpiła zmiana na garaż.

Rozumiem, że chodzi Ci o możliwość np. aktualizacji samej geometrii (bez podmiany tagów)? Jeśli tak, to mam tę funkcjonalność zaplanowaną, ale dopiero za jakiś czas.

To by było przydatna funkcja.
Jednakże ja jak najbardziej chcę też aktualizować rodzaj budynku.

[praszuk]

A informacja o budynku, że to jest budynek stacji kontroli pojazdów, nie ma związku z tym, czy ta stacja działa czy nie. Nawet przy niedziałającej stacji ta informacja jest prawdziwa - w BDOT, ale nie jest prawidziwa w OSM.

Ok, z tym się zgadzam, może być faktycznie jako "disused:".

Błąd oczywiście na stronie z Budynkami, które te tagi dodają, ale skoro ten plugin jest stamtąd pobiera, to odpowiedzialność spada także ... na plugin.

Proponowałbym mimo wszystko jednak zacząć od strony podesłanego wcześniej pliku z repo gugik2osm, a jeszcze wcześniej, może warto to najpierw skonsultować ze społecznością? Nawet prosta ankieta na Discordzie może sporo dać.

Ja oczywiście mogę pomijać te tagi w pluginie, mimo, że dla każdego i tak wyskakuje komunikat, ale nie wiem, czy dużo to zmieni, jeśli przez stronę budynków będą i tak importowane dalej masowo, gdzie szansa na ich pominięcie jest dość spora – nawet u mapujących, którzy przeglądają co importują, a nie oszukujmy się nie każdy to niestety robi.

Chodzi pewnie o "Detected uncommon tags[...]".

Dla mnie ten komunikat jest dezorientujący, nie wiem co to są nietypowe tagi. Może dałoby się chociaż wymienić, o które tagi chodzi? Czy wręcz pokazać w tym komunikacie jakie zmiany zaszły? Np. "building=yes -> building=garage"?

Odpowiedziałem częściowo tutaj #2

Masz rację, to jest ewidentnie złe przypisanie w tym pliku. Być może chodzi tutaj o "garage" w sensie warsztat - tyle że to nie jest definicja osmowa.
Tam takich błędów z garage jest więcej.

Mimo wszystko jeśli widzisz, że można coś tam poprawić, to zachęcam do PR/issue w tamtym repo.

Urok importu. Dane zastane mają wyższą wartość od danych importowanych. Należy dane z importu zignorować lub spytać się użytkownika.

To zależy (niżej).

Czasem się przecież pojawia okienko z listą tagów. Już się nauczyłem wówczas sprawdzać wartość building. Z jakichś powodów przy wskazanym budynku kontroli pojazdów się ono nie pojawia i nie zorientowałem się, że nastąpiła zmiana na garaż.

Plugin korzysta z tzw. CombinePrimitveResolverDialogu, który obsługuje aktualizację tagów dla obiektu, który już ma jakieś tagi i w domyśle łączy je z 2 źródeł wywołując konflikt (jeśli to koniecznie), co skutkuje własnie tym okienkiem, o którym zapewne piszesz. Jednakże to wywołanie w zasadzie kończyłoby się ciągłymi konfliktami dla nienowych budynków, stąd do pluginu zostały zaprogramowane pewne reguły, które pozwalają na jego pominięcie w przypadku natrafiania określonych zmian kluczy i wartości. Np. zmiana budynku z building=yes na jakąkolwiek inną wartość np. building=house nie wywoła konfliktu. Wszystkie reguły są tutaj (jest ich raptem kilka). Jest tutaj również "anty-reguła", która w przypadku wykrycia tagu source=survey, wywoła okno konfliktu bez względu na inne tagi.

Jednakże ja jak najbardziej chcę też aktualizować rodzaj budynku.

To tego trochę nie rozumiem w czym tkwi problem.

[maraf24]

A informacja o budynku, że to jest budynek stacji kontroli pojazdów, nie ma związku z tym, czy ta stacja działa czy nie. Nawet przy niedziałającej stacji ta informacja jest prawdziwa - w BDOT, ale nie jest prawidziwa w OSM.

Ok, z tym się zgadzam, może być faktycznie jako "disused:".

Ja bym sugerował building:description. Ewentualnie fixme - w przypadku tworzenia nowego budynku.

Ja oczywiście mogę pomijać te tagi w pluginie, mimo, że dla każdego i tak wyskakuje komunikat, ale nie wiem, czy dużo to zmieni,

Jak pisałem, bardziej obszerna treść komunikatu by wystarczyła - dla mnie.

jeśli przez stronę budynków będą i tak importowane dalej masowo, gdzie szansa na ich pominięcie jest dość spora – nawet u mapujących, którzy przeglądają co importują, a nie oszukujmy się nie każdy to niestety robi.

Przez stronę budynków masowo importuje się budynki brakujące w OSM, więc to nieco inna sytuacja. A tutaj można także modyfikować. Przy modyfikacji plugin może dodać np. tourism=hotel do budynku, w którym ktoś wcześniej ten tag usunął, bo hotel się zamknął.
Nb. już ktoś zwracał uwagę na Discordzie, że te tagi z BDOT nie muszą być aktualne i lepiej by ich nie importować. Pewnie i tam trzeba by issue zrobić ;)

Chodzi pewnie o "Detected uncommon tags[...]".
Dla mnie ten komunikat jest dezorientujący, nie wiem co to są nietypowe tagi. Może dałoby się chociaż wymienić, o które tagi chodzi? Czy wręcz pokazać w tym komunikacie jakie zmiany zaszły? Np. "building=yes -> building=garage"?

Odpowiedziałem częściowo tutaj #2

Tak, panel pokazuje te dodatkowe informacje, więc to częściowo dla mnie problem rozwiązuje.
Fajnie by jednak było też dostać te informacje, gdy panel nie jest włączony.

Mimo wszystko jeśli widzisz, że można coś tam poprawić, to zachęcam do PR/issue w tamtym repo.

Spróbuję.

Plugin korzysta z tzw. [CombinePrimitveResolverDialogu]
[...]
Np. zmiana budynku z building=yes na jakąkolwiek inną wartość np. building=house nie wywoła konfliktu.

Dzięki za szczegóły.
Z tą regułą wiąże się inny problem, który zauważyłem - plugin zmienia building=yes na building=construction bez pokazania tego dialogu.
A powinien - bo BDOT jest zawsze lekko nieaktualny, więc skoro ktoś dał =yes, to widocznie budowy już nie ma i nie powinno się dawać construction. Sytuacja odwrotna zdarza się w zasadzie tylko, gdy mapujący ma zwyczaj mapować wszystkie budowy jako zakończone. Dlatego ten dialog w takiej sytuacji byłby przydatny.

[praszuk]

A informacja o budynku, że to jest budynek stacji kontroli pojazdów, nie ma związku z tym, czy ta stacja działa czy nie. Nawet przy niedziałającej stacji ta informacja jest prawdziwa - w BDOT, ale nie jest prawidziwa w OSM.

Ok, z tym się zgadzam, może być faktycznie jako "disused:".

Ja bym sugerował building:description. Ewentualnie fixme - w przypadku tworzenia nowego budynku.

Źle mnie zrozumiałeś. Ja nie proponowałem tutaj tagu, tylko potwierdziłem, że faktycznie może wydarzyć się tak, że amenity jest "nieaktywne". Dalej uważam w tej sprawie, to co napisałem wyżej, że to nie po mojej stronie powinno to być zmieniane, a i tak zawieram już w tej sprawie dodatkową informację dla użytkownika (w postaci komunikatu), żeby przypadkiem nie pominął, która w moim przekonaniu jest wystarczająca.

Jak pisałem, bardziej obszerna treść komunikatu by wystarczyła - dla mnie.

Jeśli to nawiązuje do tego co wyżej, to w takim razie nie wiem, czy to aktualne, oraz o jaką treść komunikatu chodzi, bo jeśli mowa o "Uncommon tags", to również uległo zmianie w ostatniej aktualizacji i wyświetlają się już specyficzne tagi w komunikacie oraz w panelu bocznym podświetla się, że takowe zostały pobrane.

Przez stronę budynków masowo importuje się budynki brakujące w OSM, więc to nieco inna sytuacja. A tutaj można także modyfikować. Przy modyfikacji plugin może dodać np. tourism=hotel do budynku, w którym ktoś wcześniej ten tag usunął, bo hotel się zamknął.

Niektórzy też masowo podmieniają: przez utilsplugin, albo i niestety usuwając budynki i wklejając nowe. Dla mnie to nie ma w tej kwestii różnicy, bo taki tag może mimo wszystko zostać dodany na różne sposoby. Jeśli było np. to powyższe zmapowane jako disused:tourism=*, a użytkownik mimo wszystko to zignoruje, to nic na to nie poradzę, choć w takiej sytuacji by pewnie to walidatory wychwyciły, ale to ponownie inny temat i nie chcę go tutaj rozwijać...

Nb. już ktoś zwracał uwagę na Discordzie, że te tagi z BDOT nie muszą być aktualne i lepiej by ich nie importować. Pewnie i tam trzeba by issue zrobić ;)

Nie wiem jakie zdanie mają inni mapujący na ten temat. Jeśli chcesz możesz zrobić ankietę/zapytać na Discordzie, tylko, że jeśli większość by stwierdziła, że nie chcemy tych tagów w ogóle, to mimo wszystko pewnie byłoby to najprędzej zmieniane u źródła, także ponownie nie widzę tutaj powodu do jakiejkolwiek zmiany.

Z aktualnością bywa różnie, bywają gminy, gdzie jest to lepsze źródło niż inne i odwrotnie, ale nie chce rozwijać tego tematu, bo ponownie, to nie ode mnie zależy i niewiele to wnosi.

Zawsze finalnie leży to w kwestii mapującego, co uważa za słuszne/warte do zaktualizowania.

Dzięki za szczegóły.
Z tą regułą wiąże się inny problem, który zauważyłem - plugin zmienia building=yes na building=construction bez pokazania tego dialogu.
A powinien - bo BDOT jest zawsze lekko nieaktualny, więc skoro ktoś dał =yes, to widocznie budowy już nie ma i nie powinno się dawać construction. Sytuacja odwrotna zdarza się w zasadzie tylko, gdy mapujący ma zwyczaj mapować wszystkie budowy jako zakończone. Dlatego ten dialog w takiej sytuacji byłby przydatny.

Proszę załóż na to oddzielne issue, bo w tym się dyskusja rozwarstwiła na kilka różnych rzeczy.

--
Nie wiem, czy jest coś jeszcze w tym temacie do dodania/wyjaśnienia. Skłaniałbym się do zamknięcia tego issue z wyżej już wymienionych powodów.