Угу, поэтому и проверяться эта корректность должна на уровне API - это же классика. Вопросы целостности данных на клиенте никогда не решались, и не смогут решиться 
Т.е. если правка (коммит) размыкает мультиполигон, то сервер ее просто заворачивает. Может попытаемся такое протолкнуть, а? Вроде никаких изменений в самом интерфейсе (API) для этого не требуется…
Zkir, да, в теории именно так.
Только вот мультиполигон для таких проверок - абсолютно неподходящий объект.
Это не реализуемо в текущем API, так как нет никакого коммита (в смысле транзакции), а есть набор никак не связанных между собой правок конкретных объектов. Да и большинство изменений мультиполигонов сейчас проходит через состояние в котором он не валиден, т.е. вначале вей разделяется на две части (в МП остается только одна из них) и только потом вторая часть включается в МП.
Вроде бы каждый osmChange применяется как раз в транзакции, нет?
Это да, только есть еще http://wiki.openstreetmap.org/wiki/API_v0.6#Elements_2 - тоже вполне себе часть API.
Вообще-то если сервер будет каждый раз проверять валидность границы Франции - наступит апокалипсис…
Но при увеличении базы осм скоро почти все будет полигонами, ведь в жизни мало что не стыкуется. Так что надо этот вопрос всё таки решить.
По поводу проверки можно и JOSM с портлатчем (не знаю насколько это возможно, но портлатч как я понимаю тоже часто ломает) научить валидировать.
Если серверу дать такую работу, то действительно, нагрузка на него тогда будет не малая. А у клиента как то проще.
Что скажите, в портлатче реально это поправить? тогда как временное (а может и постоянное 
) решение проблемы.
Ну нельзя же. Схема настолько неудачная, что на сервере её валидировать не получится, потому что нагрузка нереальная, а на клиенте - потому что у клиента просто нет достаточно данных.
Он может отследить конечные точки загруженых линий. Если линия участвует в мультиполигоне, и ранее соединённые конечные точки теперь не соединяются - то выдавать предупреждение. Конечно это не полная валидация, но большую часть ошибок позволит обнаружить.
[offtop]
ГИС существуют не первый десяток лет. Есть логические операции работы с полигонами (объединение, вычитание, пересечение и пр.), позволяющие создавать идеально сопряженные полигоны. Но ОСМеры зачем-то придумали мультиполигоны из отдельных отрезков (спасибо автокаду), теперь придумывают методы валидации этого “добра” на сервере.
ИМХО полезнее было бы вернуться к проверенным методам и внедрять нормальные операции для работы с нормальными полигонами в редакторе. А сейчас, получается, любому пользователю данных (конвертер, рендер и пр.) требуется выкачать полуфабрикат, потом соединить полилинии (точнее списки точек) с учетом направления, потом проверить замкнутость, потом подставить координаты вместо нодов. Уффф, полигон получен 
Самое главное непонятно в чем экономия: путаницы больше, выгода минимальная. Я уже высказывал мнение что всё должно быть к месту. Хорошее начинание мультиполигонов (для логических вещей типа границ) извратили до неузнаваемости.
Дык о чём и речь.
Никакой экономии. Просто тяжёлое наследство mysql-а, от которого теперь уже не могут избавиться
Это конечно всё ужасно и так далее…
Но есть предложения по решению проблемы, место того чтобы охать и высказывать недовольства. Ведь те кто это создали, думаю другого варианта просто не видели, или не искали. Так может им подсказать?
Я со своей стороны предложил валидацию на клиенте, будет время - обдумаю как её теоретически реализовать. По перестроению в корне работы с мультиполигонами ничего сказать не могу - с ГИС почти не знаком.
P.S. но надо что то делать, скоро у нас все будет в мультиполигонах
Думаю, что именно такая структура как раз и является наиболее оптимальной и универсальной для хранения исходный данных, не ангажированных под какую-либо одну ГИС-идеологию , ГИС-систему, ГИС-формат и т.д.
Можете кинуть в меня камень, но мне структура с иерархичными одноранговыми данными в чём то даже симпатизирует, но говорить, что она идеальна для ГИС или геоданных типа OSM я не буду.
Нет, к сожалению. Реальной пользы от такой структуры нет ни с одной стороны.
Для контрибьюторов приходится ломать моск, чтобы перевести привычные абстракции в этот ужос, и всё равно всё ломается от каждого чиха, нет нормальной истории etc; для пользователей данных - много-много гемора, чтобы перевести этот ужос обратно в привычные абстракции, подходящие для обработки. Даже для самого API больше проблем с выборками и с той же валидацией (которой нет и не будет).
Третья страница подходит к концу, а адекватных предложений ни сюда, ни в вики в копилку идей для api 0.7 так и не поступило. Одни стоны.
Всё тебе надо разжевать и в рот положить?
Хорошо, разжёвываю: надо наконец отказаться от концепции “вей, состоящий из нодов” в пользу самостоятельных геометрий.
А теперь давай вместе посмеемся над шансами такого предложения
Я знаю, что надо бы — сам постоянно везде об этом говорю. Вот только за три страницы я надеялся на более конкретные мысли, чтобы можно было сделать раздел в идеях для api 0.7. Так что да, разжевать и в рот положить, либо не молоть языками, аки бабки на лавочке.
А на более конкретные мысли я бы не советовал надеяться раньше, чем будет принято принципиальное стратегическое решение. Пока я не заметил, чтобы они кого-то интересовали