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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третья страница подходит к концу, а адекватных предложений ни сюда, ни в вики в копилку идей для api 0.7 так и не поступило. Одни стоны.

Всё тебе надо разжевать и в рот положить?

Хорошо, разжёвываю: надо наконец отказаться от концепции “вей, состоящий из нодов” в пользу самостоятельных геометрий.

А теперь давай вместе посмеемся над шансами такого предложения :slight_smile:

Я знаю, что надо бы — сам постоянно везде об этом говорю. Вот только за три страницы я надеялся на более конкретные мысли, чтобы можно было сделать раздел в идеях для api 0.7. Так что да, разжевать и в рот положить, либо не молоть языками, аки бабки на лавочке.

А на более конкретные мысли я бы не советовал надеяться раньше, чем будет принято принципиальное стратегическое решение. Пока я не заметил, чтобы они кого-то интересовали

liosha, напоминаю, в осме установилась делократия ака do-ocracy.

Если кто-то может предложить более хорошую схему, чем текущие мультиполигоны - его с радостью выслушают.

Кроме того, в процесе миграции нужно будет:

  • написать (стабильную) миграцию для railsport (без потери данных/истории);
  • сделать (стабильный) патч для osm2pgsql;
  • сделать патч средней степени стабильности для josm, potlatch.

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

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

Komяpa, не поверишь, но я прекрасно знаю, что в осме установилось. И даже в курсе, что надо для всего этого сделать, и хочу ли я в это болото соваться.

И вынужден напомнить, уже как модератор, что тут не уютный личный бложик, а публичный форум, aka место для обсуждений. Каждый тут сам в состоянии решить, что ему говорить и что ему не говорить. Zverik, тебя это тоже касается.

Должен напомнить, что OSM делаем мы. И стратегические решения, внезапно, принимаем тоже мы — сообщество. OSMF тоже может принимать стратегические решения (причем в другой плоскости), но не только он.
Есть вполне конкретные шаги, которые можно предпринять. Написать драфт 0.7, вылизать, устроить голосование (да-да, о принятии API), реализовать в коде. А потом надавить всем сообществом на OSMF и зафорсить переход на 0.7.

А как ты будешь обозначать пересечения дорог, когда они станут самостоятельными геометриями? При помощи особой сущности “рутинговая нода”, как в мп?

Zkir, представь, что координаты точки - это и есть её id. А дальше всё то же самое

А адрес прописки — это ИНН.

С одной стороны выглядит довольно реалистично, с другой стороны как-то очень оптимистично. Не могу пока похвастаться своими достижениями, но я работаю над адаптацией БД под свои цели. У меня получается валидация довольно специфичных вещей, поэтому наружу ничего не высовываю.

Так вот пока я пользуюсь стратегией импорта из ОСМ c последующей очисткой. То есть сырые данные выкачиваются, потом запускается нормализация данных. Делаются вполне очевидные вещи - сносятся created_by, тег building=entrance преобразуется в entrance=yes и т.п. Highway у меня это только элементы графа (highway=crossing это другая сущность потому и другой ключ). У мультиполигонов к слову веи объединяются, т.е. если у мультиполигона два outer значит мультиполигон очевидно имеет два внешних контура. Заодно и делается проверка на самопересечения. Нормализованная база гораздо более удобна в обработке нежели сырая.

Я к чему … человеку решающему практические задачи гораздо проще извратиться и что-то поменять в структуре своих данных чем начать борьбу с ветряными мельницами.

Всё это чисто моё представление о положении вещей. Проекты типа ОСМ очень хороши в плане пошаговой эволюции (маленькая новая фичка каждый день, например, ввести ёмкость мусорного бачка) но не революции (а давайте создадим действительно разумный API 0.7).