Ну так неужели не было заметно, что соседний парк пропал с карты? 
Да, валидации мультиполигонов перед загрузкой там явно не хватает.
Золотые слова! Я, к примеру, до сих пор не въеду, как работать с этими мультиполигонами 
А мне джосм несколько раз перед загрузкой заявлял в предупреждениях что “мультиполигон не замкнут”…
Т.е. какие-то зачатки валидации есть.
Это слишком сурово - из-за одного полигона всю правку откатывать.
Это как раз нормально. Правку, которая что-то ломает самое правильное откатить, а потом уже разбираться.
Ну, правка там была не столь эпична, чтобы сильно переживать - 2 residential. Но я их вернул для восстановления справедливости.
А я тоже считаю, что reverter - это скорее инструмент, помогающий разобраться что и когда пошло не так. А вовсе не оружие немедленного возмездия.
Если что-то сломалось, есть повод поговорить с “ломальщиком” и разъяснить что к чему, в первую очередь. Ну а коль скоро человек окажется невменяемым… Тогда, да BFG к бою!
Ничего против мультиполигонов без inner не имею, сам так леса с болотами рисую.
Правда, когда в первый раз увидел творчество Felis Pimeja, мысли были примерно такой тональности: “БЛ*, ЗАЧЕМ?!”.
Не осуждаю, каждый имеет свой fun как хочет :))
Если OSM - это место для поднятия ЧСВ и самовыражения/удовлетворения графоманского зуда - то это один разговор. А если OSM это база данных, пригодная для использования, то она должна находиться в корректном состоянии всегда. Во всяком случае, время нахождения полигонов в поломатом состоянии должно быть минимальным.
Исправил ошибку, пусть даже откатом, а потом разговаривай с ломальщиком хоть до посинения -если самому поправить не получилось
<тупо отметиться>
очень часто рисую связки из зданий, заборов, landuse’ов и т.п. мультиполигонами без inner’ов (и соприказающихся outer’ов). В одной из последних версий JOSM’а появилась команда “превратить в мультиполигон” - автоматом генерится релейшн, теги переносятся с вея на релейшн. Остаётся только резать и крошить в свое удовольствие 
Спасибо!
Да я больше переживал за то что сделал что-то вроде правильно а оно порушило существующее. Ну и откат без предупреждения тоже вещь двоякая. Перерисовать что-то второй раз обычно не хочется …
А переживаю я больше за то, что уж очень легко ненароко случайно ломаются эти хрупкие мултиполигоны. Я сейчас начинаю массово переходить на мультиполигоны и думается что если я легко поломал такое то и мои мультиполгоны могут точно также легко быть сломаны. То есть проблема системная. JOSM должен был бы хотя бы ругнуться что “Вы изменили отношение, убедитесь что …”. Встроенное проверки замкнутости мультиполигонов нет, хотя мультиполигон - вещь замкнутая
Да блин, мультиполигон это много полигонов А полигон (согласно Википедии) по-русски многоугольник - геометрическая фигура, определяется как замкнутая ломаная. Это должно быть очевидно и для базы и для инструментов.
Мультилиния не должна быть замкнутой, но это другой геометрический примитив.
Кто виноват - мользователь, инструмент или модель данных?
OK, я твою точку зрения хорошо понимаю. И в общем, даже поддерживаю. Корректная база в любой момент времени - это действительно важно. Но это палка о 2-ух концах:
1-ая крайность - “место для поднятия ЧСВ и самовыражения/удовлетворения графоманского зуда”
2-ая - огороженная песочница для взращивания монгольских космонавтов (Как в том анекдоте: “Всё хорошо. Только руки очень болят. Русские все время по рукам били: это не трогай, это не нажимай”)
“А причина одна - безблагодатность” ©
То есть валидация перед загрузкой должна быть очень жёсткой. Особенно в отношении данных, уже занесённых в базу. Пришли к тому же.
Встроенный валидатор JOSM прекрасно проверяет мультиполигоны на замкнутость. Если его внимательно читать перед загрузкой на сервер, то всех косяков можно избежать.
Нда?
Если правка на 1000 объектов, а задет один мультполигон - может таки лучше замкнуть это мультиполигон чем откатывать правку на 1000 объектов?
Если например откатят мою правку из-за поломатого мультиполигона леса где-нибудь в глуши Волховского р-на - я второй раз уже на то место возвращаться не буду. Или скорее откачу откат - и замкну полигон ибо это правильнее.
Давайте все-таки хоть немного учитывать важность и объем данных прежде чем откатывать чужое.
Угу, поэтому и проверяться эта корректность должна на уровне API - это же классика. Вопросы целостности данных на клиенте никогда не решались, и не смогут решиться
Т.е. если правка (коммит) размыкает мультиполигон, то сервер ее просто заворачивает. Может попытаемся такое протолкнуть, а? Вроде никаких изменений в самом интерфейсе (API) для этого не требуется…
Zkir, да, в теории именно так.
Только вот мультиполигон для таких проверок - абсолютно неподходящий объект.
Это не реализуемо в текущем API, так как нет никакого коммита (в смысле транзакции), а есть набор никак не связанных между собой правок конкретных объектов. Да и большинство изменений мультиполигонов сейчас проходит через состояние в котором он не валиден, т.е. вначале вей разделяется на две части (в МП остается только одна из них) и только потом вторая часть включается в МП.
Вроде бы каждый osmChange применяется как раз в транзакции, нет?
Это да, только есть еще http://wiki.openstreetmap.org/wiki/API_v0.6#Elements_2 - тоже вполне себе часть API.
Вообще-то если сервер будет каждый раз проверять валидность границы Франции - наступит апокалипсис…
Но при увеличении базы осм скоро почти все будет полигонами, ведь в жизни мало что не стыкуется. Так что надо этот вопрос всё таки решить.
По поводу проверки можно и JOSM с портлатчем (не знаю насколько это возможно, но портлатч как я понимаю тоже часто ломает) научить валидировать.
Если серверу дать такую работу, то действительно, нагрузка на него тогда будет не малая. А у клиента как то проще.
Что скажите, в портлатче реально это поправить? тогда как временное (а может и постоянное 
) решение проблемы.