Czy strazakosm:sender_id jest OK na obiektach?

Wydaje mi się że https://taginfo.openstreetmap.org/keys/strazakosm%3Asender_id#chronology nie powinno być na obiektach w OSM a na zestawach zmian.

Pytam się bo chcę się skontaktować z autorami edytora co to dodaje + skasować istniejące i chcę potwierdzić że tego nie powinno być.

Nie jest ok, tak samo jak pojawiające się czasem source:user=* z powtórzonym nickiem z changesetu. Możesz chyba pisać do @jendrusk z pytaniami o to

A czemu nie jest OK?
Mamy wszak zasadę - Any tags you like
Co do source:user= , hmm - ja nie mam potrzeby ekstra zaznaczać że to ja coś wprowadziłem na mapę, ale jak już ktoś musi…
Z tego co widać zasadniczo problem dotyczy tylko jednego usera.
Pytanie oczywiście na ile wartość tego tagu jest wciąż aktualna ? :confused:

Nie traktował bym zasady ATYL jako pozwolenia na wpisywanie czegokolwiek - mamy np. ze starych importów tagi building:usage:pl=*, które usuwam jeśli są odwzorowane w building=.
A tagi typu source:user=
nie wiadomo kiedy można potem usunąć - dopiero jeśli zmienimy wszystkie tagi i lokalizację wszystkich węzłów? Ta informacja jest i tak w opisie changesetu, przy punktach tylko przeszkadza nic nie wnosząc.
Tak w ogóle nie wiem czy nie jest to jakaś pozostałość po tej dawnej-dawnej funkcji: https://wiki.openstreetmap.org/wiki/Anonymous_edits

I dokładnie te kwestie przemawiają, jak dla mnie, za usunięciem tego tagu.

Akurat tu nie mam problemu z konkretnym tagiem ale z pomysłem zapisywania tej informacji w tagach obiektu - zamiast zestawu zmian.

Nie powinno ich być, bo to nie jest właściwość obiektu. W zestawach zmian powinny być. To co kto zmieniał, widać w historii.

Cześć

Już wyjaśniam. Jest sobie aplikacja StrazakOSM. Aplikacje może pobierać każdy i za jej pomocą zbierać w terenie pozycje hydrantów lub pikietaży. Jak już pozbiera może taki zestaw danych przesłać na serwer Abakusa gdzie są one automatycznie weryfikowane i dodawane do OSM. Użytkownik nie ma żadnego konta w aplikacji, nie jest to też w żaden sposób powiązane z kontami w OSM. Żeby możliwa była jakakolwiek identyfikacja osoby przesyłającej dane i ewentualny kontakt z nią podczas przesyłania musi on podać swój numer telefonu lub adres email. Oczywistym jest że tych danych nie mogę przepchnąć do OSM, więc anonimizuję je - i to jest właśnie identyfikator o który pytacie - on pozwala mi dojść do tego jak skontaktować się z człowiekiem który przesłał ten hydrant. Teoretycznie wszystkie te dane mam również na serwerze i mógłbym do tego dojść również tak, nie mniej dla mnie jest łatwiej w ten sposób. Nie uważam, żeby ten tag jakoś bardzo przeszkadzał, a identyfikator jest krótkim intem więc i baza od niego nie puchnie.

Nie chodzi ani trochę o rozmiar bazy, a racze o to że jest to coś co (nieco) utrudnia życie i jest jeszcze jedną rzeczą która nowa osoba musi się nauczyć.

Czy jest jakiś powód który uniemożliwia dodawanie tego tagu na zestawie zmian? (poza “to nie zaimplementuje się samo, zejdzie na to X godzin roboty”)

Czy byłoby OK usuwanie tego tagu biorąc pod uwagę że zostanie on w historii?

Nie za bardzo jest tutaj coś nowego do uczenia się… poza zasadą - nie wiem co to więc nie ruszam. Dodawanie tagu na zestawie zmian nie działa bo ja te hydranty zbieram i dodaje w ramach jednego zestawu kilku(nastu) użytkowników na raz. Nie uważam, żeby jakoś te tagi utrudniały życie, jak poznikają to nie będę za nimi płakał, co najwyżej jak kiedyś trzeba będzie się dowiedzieć kto dodał jakieś hydranty to po prostu tego nie zrobię, bo o ile 10 minut żeby sprawdzić czyje to ID zawsze się znajdzie to godzina żeby szperać po bazie i weryfikować czy to na pewno to już niekoniecznie…

A nie dałoby się po stronie serwera Abakusa trzymać tabeli, zawierającej [OSM_id], [change_id (jeśli w aplikacji da się również modyfikować)], [kontakt]?

Wtedy w OSM będzie tak anonimowo, ze bardziej się nie da, a na serwerze Abakusa nadal da się łatwo znaleźć…

Tutaj mamy taką sytuacje z dobrze znanym i zasłużonym dla OSM projektem, ale uważam że na przyszłość powinniśmy być przeciwko takiemu tagowaniu - takie dane powinny być przechowywane w zewnętrznym systemie, a najlepiej opisie chansetu i tu chyba nie ma problemów technicznych z implementacją tego