Usuwanie zduplikowanych numerów telefonów

Cześć.

Dawno mnie tutaj nie było, bo na komputerze z systemem operacyjnym, z którego na co dzień korzystam nie mogłem już korzystać z forum społeczności OSM z mojej podstawowej przeglądarki (Windows 7 64-bit i Mozilla Firefox 115.38.0 ESR) . Jednak udało mi się znaleźć zamiennik, z którego mogę się zalogować i pisać (przeglądarka r3dfox), więc postanowiłem, że napiszę, bo sprawa (w dalszym ciągu) leży mi na wątrobie.

Chodzi o akcję pod nazwą: Fix phone number issues: missing country code, incorrect separators, extra characters, duplicate phone numbers

Pisałem już o niej w tym temacie ( Edycja numerów telefonicznych ), w nieco innym kontekście (chodziło bardziej o sposób zapisu - formatowanie liczb; teraz stosuję zapis popularny i charakterystyczny dla Polski), ale nadal widzę, że usuwane są zduplikowane numery telefonów z POI - tylko, że raz usuwane są tagi phone i/lub mobile a zostawiane są contact:phone i/lub contact:mobile , a innym razem odwrotnie: usuwane są te z prefiksem contact: a zostają same phone i/lub mobile.

Ma to oczywiście związek z tą akcją: Raport o niepoprawnych numerach telefonicznych w OSM - Polska i widzę, że była dyskusja na ten temat Using both phone and contact:phone on the same object. Is that an error? ale bez wyraźnego rozstrzygnięcia, bo dyskusja się urwała, a praktyka sugerowana w akcji Phone Report jest kontynuowana.

Wk… denerwuje mnie to, że jakoś inne zduplikowane tagi (np. email, czy adres strony internetowej) autorowi akcji nie przeszkadzają, ale z uporem maniaka promuje usuwanie duplikatów numerów telefonicznych.

Czy jedyne co mi pozostało to dodawanie numerów do POI przy okazji ich edycji? Nie będę specjalnie poprawiał POI tylko po to, by dodać duplikat numeru z innym tagiem, ale szlag mnie trafia, jak po stworzeniu nowego POI albo edycji jakiegoś starego, który w ogóle nie miał numerów, niedługo potem widzę pousuwane tagi - i tylko te tagi dotyczące telefonów.

Dodaję numery telefonów z contact i bez i będę to robił, dopóki OSM nie uzna tradycyjnego phone i mobile za przestarzałe i nie będzie jakiejś operacji masowej zmiany / usuwania tagowania.

Jak narzędzie QA zachęcam do robienia edycji które uważasz za głupie - zgłaszałeś to autorowi tego narzędzia?

Jak powyższe nie wystarcza - o jakie konkretne edycje chodzi? Dasz linki do changesetów?

Narzędzie, które zostało użyte to OSM Phone Report (ver. 5.24.1). Przynajmniej to widzę w zestawie zmian, w którym zauważyłem zmiany edytowanych wcześniej przeze mnie POI - Changeset: 186031937 | OpenStreetMap

Od razu, gdy zauważyłem te zmiany to napisałem prywatną wiadomość po angielsku do użytkownika geomaster01 | OpenStreetMap , ale odpowiedzi się nie doczekałem. Dalej edytuje w ten sposób, z użyciem tego narzędzia, tyle że w innych częściach globu.

Wysłałem jeszcze przed chwilą jedną wiadomość do tego użytkownika z linkiem do tego tematu: Using both phone and contact:phone on the same object. Is that an error?

Dodałem również komentarz z tym linkiem w jego zestawie zmian.

ja bym napisał do autora narzędzia, nie do autora edycji

ewentualnie napisał do DWG że komentarze pod zestawem zmian są olane

Olane, bo to narzędzie z linii komend (CLI) i gość może w ogóle nie czytać wiadomości z OSM, a tym bardziej komentarzy w zestawach zmian. Do autora oczywiście mogę napisać (choć dyskutowałeś z nim przecież w inkryminowanym wątku), ale obawiam się, że to nic nie da, skoro autor bawi się w najlepsze swoim softem - Announcing a new phone number validator

Tu przy okazji lista zmian, które poprawiałem ponownie, a które są wskazane jako błędne - do korekty przez OSM Phone Validator. Widać tam moje ostatnie edycje przywracające poprzedni stan - Raport o niepoprawnych numerach telefonicznych w OSM - Podlaskie

Mógłbym jeszcze (spróbować) wycofać wspomniany zestaw zmian. A do kogo z DWG napisać? Jak najlepiej to zrobić?

no to DWG i blokadę dostanie, na początek pewnie 0h

Wyślij na data@openstreetmap.org

tytuł:

user ignores changeset comments

i treść mejla typu

ignored changeset comment: Changeset: 182392288 | OpenStreetMap
they edited in Changeset: 182779385 | OpenStreetMap days later

Do tytułu można jeszcze dorzucić “large-scale undiscussed low-quality automation” lub część która pasuje

warto poświęcić na to te kilka minut - nawet jak oleje to potem będzie łatwiej gdzie indziej (można dodać “using controversial tool that ignores feedback”)

a może poprawi i lepiej nie robić sekatora na zapas?

I am the author the tool, I am sorry for the issues it has caused.

Apologies for writing in English, please use the translate button as necessary.

If using both contact:phone and phone (and mobile, etc.) with the same value is wanted, encouraged or accepted in Poland then I would be able to make an exception.

My report only focuses on phone numbers because they are easy to validate and it is a single purpose QA tool.

This comment got the most likes in that thread, even though the thread was not conclusive or widely engaged with. I did not feel that the thread reached a conclusion that double/duplicate tagging should be encouraged and so made no changes based on it.

@Krystek możesz tam do niego odpowiedzieć jak chcesz tych dubli bronić

no idea, personally I am staying away from that contact: prefix mess

I prefer tagfiddling that has decent chance to be clearly accepted as an improvement

1 Like

Hello @confusedbuffalo Yes, the exception (for Poland, but I think it should be not only for Poland either) would be very appreciated.

Maybe so, but this is a subjective feeling. When the old tags are not depreciated they should not be removed from POIs having them. Old tags may be for backward compatibility with older (online) apps. JOSM allows to input old and new tags. I assume that JOSM is up-to-date when it comes to using tags and if any were outdated, it would remove the option to add them (unless someone adds them manually by editing POIs).

If they will be deprecated we will remove them by mass editing after discuss.

Your app should not be doing mass edition without control.

I would like to see that there is a little more community consensus first, as from the other thread there are definitely voices that think it is an error to have both tagged.

From my point of view, it is not about deprecating one or other tag, but about having duplicate information, which could get out of sync. There are many apps and programs which do not show both tags prominently or at all at once, such that it would be very easy to edit the phone number but in fact be only changing phone and not changing contact:phone due to not noticing it (or the other way round).

The app allows for edits to be made (as does any other editor). I think that the suggestions are generally good, or at least show some data issue. The control is in the hands of the users choosing to make or not make the edits suggested. What limits or controls do you think should be put in place?

1 Like

I don’t see reason to have specific behavior for Poland, but as for me synonymous keys with synonymous values are not worth keeping in database.

Techically JOSM is able to input any key :smiley:
I believe apps should support both contact:phone and phone schemes, however I never hear about deprecating one of those keys in favor of the other.

But I think there is some value in unifying them into one key,there is no point in keeping same info in both of them. Such mechanical edit to remove contact:phone if phone have exactly same value seems fine for me. Unifying them at the same time require some more attention, but as far as I get it that’s what tool is doing.

As far as I understand it’s tool that is being used by a user, it’s not doing mass editions without control.

2 Likes

The tool is not doing any unifying, it is only checking if there is a number that exists in both tags that have the same meaning, e.g. phone=123, contact:phone=123 then suggestion is to remove contact:phone (as it is less common)

So if you have phone=123 and contact:phone=456 then nothing is reported by my tool (maybe it should, and Osmose I believe has flags for this)

2 Likes

So, maybe it will be better for app to determine if tags phone=123 and contact:phone=456 are different and possibly suggest user for correction? And do not indicate on website, when POI has redundant numbers - in phone / mobile and contact:phone / contact:mobile?

Checking if the values are different would be good, I will see about adding that.

But having duplicate tagging and waiting for someone to only change one value, and hoping that someone else then notices the error, analyses the history and then fixes it seems like a bad way to do things, and better to only tag something once in the first place.

1 Like

My point is: your app should not treat duplicated values (redundant tags with those values) in POIs as an error.

I understand, and that was my attempt to explain why I think that duplicated, redundant values are a bad idea

1 Like