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

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

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

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).

даже если в 0.7 просто введут тип area == poligon - уже решится море проблем, и это будет гигантским шагом к нормальной схеме данных.

И появятся новые проблемы. Типа тегов building=yes на линиях и barrier=fence на area, которые непонятно как интерпретировать. :slight_smile:

building=yes на незамкнутой линии интерпретируется как бессмысленный тег (но сохраняется, на объекте линия API 0.7). При замкнутой линии объект интерпретируется как тип area API 0.7, тег тоже, конечно, сохраняется.

barrier=fence на area сейчас не бывает, ибо никакого area ещё нет. А если имеется в виду тег area=yes, то применительно к барьеру означает, что барьер обозначен площадным объектом (мало ли, кто-то забор нарисовал), тогда создается 1 объект типа area.
А вот если barrier=fence + highway=sevrice + area=yes, порождается 2 объекта. И барьер должен быть в этом случае линией.

по логике area - замкнутый и заполненный объект, то-есть все теги применительны всем точкам внутри объекта, а бывший в настоящем замкнутый way - только для точек границы.

А пока мы имеем то что имеем :wink:

Вот классический пример “мультиполигона” в ОСМ - http://www.openstreetmap.org/browse/relation/1538520

Валиден ли такой мультиполигон? Почему такие полигоны прекрасно создаются в JOSM?