Что означает "2gis" в комментарии к пакету?

changeset/82379022

Вижу, что на момент данной правки всё ещё в силе было мнение про то, что все эти магазины маленькие, а если они не маленькие, то это исключение, сколько бы этих исключений не найти. Я их специально полигонами стал рисовать, чтобы было видно насколько они маленькие. Исходя из того, что вы написали "Вместе это маленький алкомаркет", я считаю, что вы их путаете с "Близко".

Это из-за того, что в Vespucci на вкладке Properties есть кнопки с заготовками, на которые можно случайно нажать. Vespucci об этом никак не предупредит, и никак не изобразит добавившийся тег, если уже есть другой.

Hello.

You again deleted the Moscow-Riga train routes:

relation/10988874
relation/1203910

You were asked about this before but you did not answer:

changeset/88211283

Are you deleting them because they are suspended or for some other reason?

Best regards
Anton Khorev
Data Working Group

Если телефонов несколько через точку с запятой, вы только последний форматируете?

node/7133464307/history

In this changeset you moved Diomidous (Διομήδους) street for about 7 meters to the north.

The result matches better unaligned Maxar imagery, but the match with Strava heatmap became worse. This is why I asked you about the imagery offset you're using, but you didn't answer about it.

changeset/87262573

Without knowing the correct imagery offset, how can you be sure that you're improving the data?

osm.wiki/Good_practice#Align_aerial_imagery_before_tracing

Why do you prefer Maxar imagery to Bing in this area? What imagery offset are you using?

Bing seems to have a better angle here, tracing it would cause less distortions.

Как раз исправлять всё, что редактор считает ошибками, и не следует. Это всем сэкономит много времени, позволяя вам просто не делать такие пакеты правок с якобы исправлениями, а всем остальным - не исправлять эти якобы исправления. Авторы редактрора iD имеют мнение, как что должно быть отмечено, которое вовсе не обязательно совпадает с мнением других участников. Но у авторов iD есть возможность подсунуть пользователем кнопочку, нажатие на которую их мнение реализует.

Например, авторам iD не нравится, что коридор соединён с точкой магазина. Они показывают пользователю предупреждение по этму поводу и дают кнопку, позволяющую извлечь точку из линии. Но точка была добавлена в линию не просто так:

@Anton%20Khorev/diary/45247#poi-1

Собственно, зачем она была добавлена, если нас, например, не интересуют абстрактные соответствия магазинов входам? Посмотрим на вот этот Coffee Like:

node/6494911750

Есть компания, занимающаяся импортами подобных точек. Проблема в том, что её сотрудники на самом деле не знают, где эти точки находятся. Знать они могут, допустим, адрес, и точку они ткнут в любое место здания. Если нас не устраивает случайное расположение точек, можно потом их деятельность проверить и поставить всё на место. И вот чтобы всем было понятно, где именно находится точка, я отмечаю вход в здание, перемещаю точку ко входу и соединяю её со входом коридором. Так всем будет ясно, что положение точки теперь не случайное. Дело, вроде бы, сделано.

Но дальше является пользователь iD, занимающийся исправлениями по мнению авторов iD. Авторам iD не нравится точка, соединённая коридором. Пользователь iD нажимает на кнопку "сделать как нравится авторам iD", и отсоединяет точку. Потом снова приходят импортёры, которые по-прежнему не знают, где находится их точка. Поскольку она никак не закреплена, они опять перетаскивают её в случайное место здания. Теперь мы вернулись к тому, с чего начали.

Hello. You have already received similar messages. One of them was discussed here:

changeset/86759637

Another user commented that you shouldn't add addr: tags to streets. But there's one more reason why your edits are being detected as errors.

Buildings may have addresses, but they should not have both addr:place and addr:street tags. You happen to have edited buildings that had addr:place tag set before. Once you added addr:street tag to those buildings without removing addr:place, the error was detected.

At this point there are two possibilities:

1. The houses are actually not numbered along the street, each house has unique number in the entire village, addr:place tag was set correctly - in this case you shouldn't have added addr:street tag.

2. The houses are numbered along the street, addr:place tag was set incorrectly - in this case you should have deleted addr:place after adding addr:street.

For more information see:

osm.wiki/Addresses#Addresses_without_street_names

addr:place=*

Best regards
Anton Khorev
Data Working Group

(automatyczne tłumaczenie)

Dzień dobry. Otrzymałeś już podobne wiadomości. Jeden z nich został tutaj omówiony:

changeset/86759637

Inny użytkownik skomentował, że nie należy dodawać tagów addr: do ulic. Ale jest jeszcze jeden powód, dla którego zmiany są wykrywane jako błędy.

Budynki mogą mieć adresy, ale nie powinny mieć tagów addr: place i addr: street. Zdarza się, że edytowałeś wcześniej budynki, które miały ustawiony adres add: tag miejsca. Po dodaniu tagu addr: street do tych budynków bez usuwania adresu add: place wykryto błąd.

W tym momencie istnieją dwie możliwości:

1. Domy w rzeczywistości nie są ponumerowane wzdłuż ulicy, każdy dom ma unikalny numer w całej wiosce, adres add: place został ustawiony poprawnie - w tym przypadku nie powinieneś dodawać addr: street tag.

2. Domy są ponumerowane wzdłuż ulicy, tag addr: place został ustawiony nieprawidłowo - w tym przypadku powinieneś usunąć adres add: place po dodaniu adresu add: street.

Aby uzyskać więcej informacji zobacz:

osm.wiki/Addresses#Addresses_without_street_names

addr:place=*

Это не "Правка расположения зданий". Это распиливание здания под адресацию. Почему-то некоторые участники думают, что должно быть соответствие 1:1 даже не адрес-здание, а адресная табличка-здание. То есть, если на здании 4 таблички, они пойдут пилить его на 4 части. В данном случае таблички две.

Для названий типа "Бутерброд" может лучше подходить тег loc_name:

osm.wiki/RU:%D0%9D%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F#loc_name

Is this a square with a pedestrian area in the middle? Why don't you add another polygon with place=square tag covering the entire square instead of retagging the pedestrian area?

No, the ways I pointed out didn't lose their status and didn't became untagged. Also they weren't members of any multipolygon. You can see the tags they had in their history:

way/713660072/history
way/713651725/history

Generally, no lines become untagged if you delete the multipolygon relation that includes them. Usually, but not always, lines are untagged while being multipolygon members because the multipolygon relation has all necessary tags. If you delete the multipolygon, its former members keep whatever tags they had on their own.

Hello,

Recently you made some edits where you deleted and/or redrawn a lot of elements. This changeset is one of such edits.

Allegedly you don't like multipolygons and try to convert them into simple closed ways. To achieve that, you sometimes delete inner contours of multipolygons, which is already questionable. However your edits go beyond that. Why would you delete building parts like these:

way/713660072
way/713651725

They are not multipolygons. Do you think that they are incorrectly mapped or that they are useless?

Anton Khorev
Data Working Group

Please don't delete the buildings that exist on the ground. If you want to indicate that the hut is private, set the access tag to private.

access=private

(automatyczne tłumaczenie)

Nie usuwaj budynków istniejących na ziemi. Jeśli chcesz wskazać, że chata jest prywatna, ustaw tag „access” na „private”.

osm.wiki/Pl:Tag:access%3Dprivate

Вы уверены, что здесь есть памятник? На доступных снимках ничего похожего не видно.

@Stalker61

Пожалуйста, не надо писать про "вандальные правки", "плюете открыто в лицо" и подобное в обсуждениях правок. Ясно, что это не приведёт ни к какому положительному результату. Если вы действительно считаете данных участников вандалами, то чего вы хотите добиться разговором с ними? Если же нет, вы могли бы объяснить, что именно не так с их правками, чтобы им было понятно.

@Lightcyphers

You don't need a detailed analysis to notice that after the discussed edits
this road way/238304253 intersects with this building way/238217052 ,
this road way/266631678 intersects with this building way/238217069 ,
this road way/238217031 intersects with this building way/702177977
and so on.

For Maxar imagery there's about 25 meters difference between offset 0;0 which matches the new road locations and offset -17;45 which matches the old building locations. Why do you think that 0;0 is a correct offset? If you're sure that it is correct, why don't you move the buildings? Do you think it's an improvement to move roads so they intersect with buildings?

Anton Khorev
Data Working Group

К сожалению, вы так и не ответили, по какому принципу вы отмечаете памятники: changeset/83177914

Вы, наверное, не ездите по различным областям и даже странам, чтобы искать памятники. Тогда откуда вы берёте информацию о них?

This changeset has been reverted fully or in part by changeset/85735725 where the changeset comment is: