Это конечно всё ужасно и так далее…
Но есть предложения по решению проблемы, место того чтобы охать и высказывать недовольства. Ведь те кто это создали, думаю другого варианта просто не видели, или не искали. Так может им подсказать?
Я со своей стороны предложил валидацию на клиенте, будет время - обдумаю как её теоретически реализовать. По перестроению в корне работы с мультиполигонами ничего сказать не могу - с ГИС почти не знаком.
P.S. но надо что то делать, скоро у нас все будет в мультиполигонах
Думаю, что именно такая структура как раз и является наиболее оптимальной и универсальной для хранения исходный данных, не ангажированных под какую-либо одну ГИС-идеологию , ГИС-систему, ГИС-формат и т.д.
Можете кинуть в меня камень, но мне структура с иерархичными одноранговыми данными в чём то даже симпатизирует, но говорить, что она идеальна для ГИС или геоданных типа OSM я не буду.
Нет, к сожалению. Реальной пользы от такой структуры нет ни с одной стороны.
Для контрибьюторов приходится ломать моск, чтобы перевести привычные абстракции в этот ужос, и всё равно всё ломается от каждого чиха, нет нормальной истории etc; для пользователей данных - много-много гемора, чтобы перевести этот ужос обратно в привычные абстракции, подходящие для обработки. Даже для самого API больше проблем с выборками и с той же валидацией (которой нет и не будет).
Я знаю, что надо бы — сам постоянно везде об этом говорю. Вот только за три страницы я надеялся на более конкретные мысли, чтобы можно было сделать раздел в идеях для api 0.7. Так что да, разжевать и в рот положить, либо не молоть языками, аки бабки на лавочке.
А на более конкретные мысли я бы не советовал надеяться раньше, чем будет принято принципиальное стратегическое решение. Пока я не заметил, чтобы они кого-то интересовали
liosha, напоминаю, в осме установилась делократия ака do-ocracy.
Если кто-то может предложить более хорошую схему, чем текущие мультиполигоны - его с радостью выслушают.
Кроме того, в процесе миграции нужно будет:
написать (стабильную) миграцию для railsport (без потери данных/истории);
сделать (стабильный) патч для osm2pgsql;
сделать патч средней степени стабильности для josm, potlatch.
Если кто-то возьмётся сделать всё вышеперечисленное, то сделать действительно более удачную, чем текущую, структуру данных для мультиполигонов/площадей, будет достаточно просто.
Если кое-кто-то собирается продолжать ныть “ааай, всё равно никто это не поддержит, зачем я буду что-то делать” - то “закройте свои поганые рты и не воняйте”.
Komяpa, не поверишь, но я прекрасно знаю, что в осме установилось. И даже в курсе, что надо для всего этого сделать, и хочу ли я в это болото соваться.
И вынужден напомнить, уже как модератор, что тут не уютный личный бложик, а публичный форум, aka место для обсуждений. Каждый тут сам в состоянии решить, что ему говорить и что ему не говорить. Zverik, тебя это тоже касается.
Должен напомнить, что OSM делаем мы. И стратегические решения, внезапно, принимаем тоже мы — сообщество. OSMF тоже может принимать стратегические решения (причем в другой плоскости), но не только он.
Есть вполне конкретные шаги, которые можно предпринять. Написать драфт 0.7, вылизать, устроить голосование (да-да, о принятии API), реализовать в коде. А потом надавить всем сообществом на OSMF и зафорсить переход на 0.7.
С одной стороны выглядит довольно реалистично, с другой стороны как-то очень оптимистично. Не могу пока похвастаться своими достижениями, но я работаю над адаптацией БД под свои цели. У меня получается валидация довольно специфичных вещей, поэтому наружу ничего не высовываю.
Так вот пока я пользуюсь стратегией импорта из ОСМ c последующей очисткой. То есть сырые данные выкачиваются, потом запускается нормализация данных. Делаются вполне очевидные вещи - сносятся created_by, тег building=entrance преобразуется в entrance=yes и т.п. Highway у меня это только элементы графа (highway=crossing это другая сущность потому и другой ключ). У мультиполигонов к слову веи объединяются, т.е. если у мультиполигона два outer значит мультиполигон очевидно имеет два внешних контура. Заодно и делается проверка на самопересечения. Нормализованная база гораздо более удобна в обработке нежели сырая.
Я к чему … человеку решающему практические задачи гораздо проще извратиться и что-то поменять в структуре своих данных чем начать борьбу с ветряными мельницами.
Всё это чисто моё представление о положении вещей. Проекты типа ОСМ очень хороши в плане пошаговой эволюции (маленькая новая фичка каждый день, например, ввести ёмкость мусорного бачка) но не революции (а давайте создадим действительно разумный API 0.7).
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 - только для точек границы.