Структура данных проекта OpenStreetMap, заглянем под юбку сервису

[nerudo]

Топику крайне не хватает фото подстать названию.

[nerudo]

А по делу отлично, спасибо.

[zalexz]

Внести массово популярное изменение в osm весьма проблематично :)

[MaksVasilev]

Если вы про area, то это не так уж сложно и делается. Надо в api 0.7 ввести этот тип, но автоматом ничего не переделывать в поведении софта по умолчанию со старыми типами, а в версии api 0.8 сделать тип area как обязательный для полигонов, а way как тип только для полилиний. Учитывая период жизни одной версии api, вполне достаточно времени, что бы софт, работающий с данными OSM можно было адаптировать к версии 0.8 не спеша.

В идеале даже весь софт, редактирующий данные (josm, онлайн редакторы, merkaartor и т.д.) начиная с версии api 0.7 должны автоматом преобразовывать полигоны в area при редактировании. А оставшееся в базе перед сменой api на 0.8 сконвертить прямо в базе. Как DBA, могу сказать, что это совсем не сложно в плане реализации и не займёт столько времени как перелицензирование :)

[Zverik]

Лучше ничего не делать, чем такие полумеры. Коли ввели тип area — всё, way и multipolygon больше не работают, нужно всё переконвертировать. Переход на новую версию API в любом случае изменит структуру базы, почему бы не добавить алгоритм апгрейда типов данных.

[Komzpa]

Алгоритм апгрейда данных? Вспомним redaction bot.

[MaksVasilev]

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

[MaksVasilev]

Это не полумеры, а процесс нормального эволюционного внесения изменения в API, который позволит пользователям самим на первом этапе преобразовывать типы, точнее оно может преобразовываться автоматом в том же JOSM при редактировании, а уж остатки конвертить ботом на следующей смене API.

Не надо делать революций, к которым окажется не готово 99% софта, работающего с данными да и среди пользователей придётся вести разъяснительную работу, это тоже время займёт. Разом в одном API объявить, что все way теперь только полилинии — это чревато бунтами.

[Zverik]

Тем, кто осилил до конца, подскажу, что тип area — самый вероятный кандидат на реализацию (но только когда закончится затянувшееся перелицензирование). Очень много на этот счёт понаписано в разделе вики The Future of Areas и далее по ссылкам. Одна из не упомянутых там страниц — размышления и наброски алгоритмов Фредерика Рамма.

[za90]

Спасибо. Как раз ссылок статье не хватает.

[jackz]

Спасибо за статью! Хоть я и не интересуюсь OSM (кроме самых меркантильных пользовательских нужд), но статью прочитал на одном дыхании! Очень познавательно и доходчиво.

[MaksVasilev]

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