Мультиполигоносрач

<тупо отметиться>
очень часто рисую связки из зданий, заборов, landuse’ов и т.п. мультиполигонами без inner’ов (и соприказающихся outer’ов). В одной из последних версий JOSM’а появилась команда “превратить в мультиполигон” - автоматом генерится релейшн, теги переносятся с вея на релейшн. Остаётся только резать и крошить в свое удовольствие :slight_smile:

Спасибо! :slight_smile:

Да я больше переживал за то что сделал что-то вроде правильно а оно порушило существующее. Ну и откат без предупреждения тоже вещь двоякая. Перерисовать что-то второй раз обычно не хочется …

А переживаю я больше за то, что уж очень легко ненароко случайно ломаются эти хрупкие мултиполигоны. Я сейчас начинаю массово переходить на мультиполигоны и думается что если я легко поломал такое то и мои мультиполгоны могут точно также легко быть сломаны. То есть проблема системная. JOSM должен был бы хотя бы ругнуться что “Вы изменили отношение, убедитесь что …”. Встроенное проверки замкнутости мультиполигонов нет, хотя мультиполигон - вещь замкнутая :slight_smile:

Да блин, мультиполигон это много полигонов :slight_smile: А полигон (согласно Википедии) по-русски многоугольник - геометрическая фигура, определяется как замкнутая ломаная. Это должно быть очевидно и для базы и для инструментов.

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

Кто виноват - мользователь, инструмент или модель данных?

OK, я твою точку зрения хорошо понимаю. И в общем, даже поддерживаю. Корректная база в любой момент времени - это действительно важно. Но это палка о 2-ух концах:
1-ая крайность - “место для поднятия ЧСВ и самовыражения/удовлетворения графоманского зуда”
2-ая - огороженная песочница для взращивания монгольских космонавтов (Как в том анекдоте: “Всё хорошо. Только руки очень болят. Русские все время по рукам били: это не трогай, это не нажимай”)

“А причина одна - безблагодатность” ©
То есть валидация перед загрузкой должна быть очень жёсткой. Особенно в отношении данных, уже занесённых в базу. Пришли к тому же.

Встроенный валидатор JOSM прекрасно проверяет мультиполигоны на замкнутость. Если его внимательно читать перед загрузкой на сервер, то всех косяков можно избежать.

Нда?
Если правка на 1000 объектов, а задет один мультполигон - может таки лучше замкнуть это мультиполигон чем откатывать правку на 1000 объектов?

Если например откатят мою правку из-за поломатого мультиполигона леса где-нибудь в глуши Волховского р-на - я второй раз уже на то место возвращаться не буду. Или скорее откачу откат - и замкну полигон ибо это правильнее.

Давайте все-таки хоть немного учитывать важность и объем данных прежде чем откатывать чужое.

Угу, поэтому и проверяться эта корректность должна на уровне API - это же классика. Вопросы целостности данных на клиенте никогда не решались, и не смогут решиться :slight_smile:

Т.е. если правка (коммит) размыкает мультиполигон, то сервер ее просто заворачивает. Может попытаемся такое протолкнуть, а? Вроде никаких изменений в самом интерфейсе (API) для этого не требуется…

Zkir, да, в теории именно так.

Только вот мультиполигон для таких проверок - абсолютно неподходящий объект.

Это не реализуемо в текущем API, так как нет никакого коммита (в смысле транзакции), а есть набор никак не связанных между собой правок конкретных объектов. Да и большинство изменений мультиполигонов сейчас проходит через состояние в котором он не валиден, т.е. вначале вей разделяется на две части (в МП остается только одна из них) и только потом вторая часть включается в МП.

Вроде бы каждый osmChange применяется как раз в транзакции, нет?

http://wiki.openstreetmap.org/wiki/API_v0.6#Diff_upload:POST.2Fapi.2F0.6.2Fchangeset.2F.23id.2Fupload

Это да, только есть еще http://wiki.openstreetmap.org/wiki/API_v0.6#Elements_2 - тоже вполне себе часть API.

Вообще-то если сервер будет каждый раз проверять валидность границы Франции - наступит апокалипсис…

Но при увеличении базы осм скоро почти все будет полигонами, ведь в жизни мало что не стыкуется. Так что надо этот вопрос всё таки решить.
По поводу проверки можно и JOSM с портлатчем (не знаю насколько это возможно, но портлатч как я понимаю тоже часто ломает) научить валидировать.
Если серверу дать такую работу, то действительно, нагрузка на него тогда будет не малая. А у клиента как то проще.

Что скажите, в портлатче реально это поправить? тогда как временное (а может и постоянное :wink: ) решение проблемы.

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

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

[offtop]
ГИС существуют не первый десяток лет. Есть логические операции работы с полигонами (объединение, вычитание, пересечение и пр.), позволяющие создавать идеально сопряженные полигоны. Но ОСМеры зачем-то придумали мультиполигоны из отдельных отрезков (спасибо автокаду), теперь придумывают методы валидации этого “добра” на сервере.
ИМХО полезнее было бы вернуться к проверенным методам и внедрять нормальные операции для работы с нормальными полигонами в редакторе. А сейчас, получается, любому пользователю данных (конвертер, рендер и пр.) требуется выкачать полуфабрикат, потом соединить полилинии (точнее списки точек) с учетом направления, потом проверить замкнутость, потом подставить координаты вместо нодов. Уффф, полигон получен :slight_smile:
Самое главное непонятно в чем экономия: путаницы больше, выгода минимальная. Я уже высказывал мнение что всё должно быть к месту. Хорошее начинание мультиполигонов (для логических вещей типа границ) извратили до неузнаваемости.

Дык о чём и речь.

Никакой экономии. Просто тяжёлое наследство mysql-а, от которого теперь уже не могут избавиться :slight_smile:

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

Я со своей стороны предложил валидацию на клиенте, будет время - обдумаю как её теоретически реализовать. По перестроению в корне работы с мультиполигонами ничего сказать не могу - с ГИС почти не знаком.

P.S. но надо что то делать, скоро у нас все будет в мультиполигонах

Думаю, что именно такая структура как раз и является наиболее оптимальной и универсальной для хранения исходный данных, не ангажированных под какую-либо одну ГИС-идеологию , ГИС-систему, ГИС-формат и т.д.

Можете кинуть в меня камень, но мне структура с иерархичными одноранговыми данными в чём то даже симпатизирует, но говорить, что она идеальна для ГИС или геоданных типа OSM я не буду.

Нет, к сожалению. Реальной пользы от такой структуры нет ни с одной стороны.

Для контрибьюторов приходится ломать моск, чтобы перевести привычные абстракции в этот ужос, и всё равно всё ломается от каждого чиха, нет нормальной истории etc; для пользователей данных - много-много гемора, чтобы перевести этот ужос обратно в привычные абстракции, подходящие для обработки. Даже для самого API больше проблем с выборками и с той же валидацией (которой нет и не будет).