Обсуждение может менять направление 100 раз. Именно для для этого в шапке темы всегда пишут актуальное состояние проблемы, постановка задачи так сказать …
По поводу картинки я и спросил - а что не так с генерализацией на приведённой странице. Чем алгоритм mapnik плох? Понимание этого позволит задачу поставить чётче.
fserges, mapnik не производит никакой генерализации. Чтобы отрисовать картинку 256х256, из базы достаются те же самые сотни мегабайт информации. Рекомендую посмотреть на конфигурацию сервера, рендерящего тайлы, и сравнить его с конфигурацией любого навигатора.
подозреваю, что имеется ввиду следующее
генерализация - процесс сворачивания гигабайтного файла до 10 метров (например) с возможностью навигации и поиска городов/стран по ним, упрощенными линиями и т.д.
а мапник, чтоб отрисовать тайл на 6-12 масштабе выкачает все данные этого квадрата в оперативку и там их начнет мучить. то-есть сам мапник не делает генерализации, он только рисует самое важное на данном зуме, как в правилах написано.
Вот то что написал Larry0ua гораздо более похоже на постановку задачи для программиста
И всё же я готов поспорить - mapnik делает генерализацию Только его упор - на визуальное представление тогда как я понимаю задача Zkir - сохранение каких-то свойств дорожного графа. Т.е. генерализация для разных задач разная!
Есть открыть всю Россию, сделать поиск highway=* и сменить всё на highway=trunk - то мы неожиданно поймём, что собственно генерализацию делает не мапник, а мапперы, которые ставят trunk на очень небольшое количество не очень плотно расставленных дорог.
Нет конечно. Тут плохо ВСЁ. Во-первых я не вижу Волгу - а она ведь самый крупный (длинный) объект в Европейской части России. Где Ока, Москва-река, Клязьма?
Дороги отобраны правильно (trunk/primary), но отображаются слишком бледно, их едва можно разобрать.
При всем этом карта практически лысая - в Тверской области из городов показана только Тверь, во Владимирской области есть Ковров, но нет самого Владимира и.т.д.
Если это политическая карта, можно раскрасить области в разные цвета, а если физическая - показать лес.
Это что касается визуализации.
В том то и проблема, что нет у мапника никакой модели. Он просто пытается отрендерить то, что есть в osm-базе, отфильтровав определенные типы объектов.
Угу, а поскольку одно без другого невозможно, уже с 8-го уровня начинается полный бред, какой просто стыдно называть картой.
Да, примерно так. Требуется породить файл разумного размера (10-50 мб) с векторными данными, содержащий геометрию и атрибуты, чтобы эту карту можно было отрендерить и строить маршруты между городами.
Почему геометрия должна быть упрощенной, мне казалось довольно очевидно. Например, береговая линия России (Северный ледовитый и Тихий океаны), содержит многие тысячи, а может уже и миллионы точек. А если нужно показать всю Россию целиком, на экране пусть даже не навигатора, а компьютера, с разрешением 1600x1200, столько просто не нужно.
задача 5:
-менять все полигоны городов/поселков на точки
-оставить транки, примари со сьздами. Тут сложней, стандарты на классы дорог различны внутри и снаружи городов (как мне кажется), поэтому придется понижать дороги внутри городов.
-составить список обектов кому место на общей карте
-упростить линии, например ST_Simplify (постгис), но тут есть другие грабли, нужно тщательно подбирать коэфициенты и алгоритмы, т.к. упрощая, например границу России, я сократил количество точек до нужного (не помню сколько), но Кгд обл. упростилась до 5 точек (може преставить как она выглядела)
реки тоже упростить до way
P.S. это так, краткий очерк, вдруг кому будет полезно
shadowjack, генерализация дорог без потери роутинга. с фишками типа схлопывания двухвеек в синглвейки и трансформации при этом запретов поворотов. роутинг какой-никакой, всё-таки, уже есть, как и генерализация всяких лендъюзов
неплохо, если получится сделать это на базе osm2pgsql в --slim-импорте.
PS: сломанные ноги - это весело, сам так два раза лежал :3
Давай подумаем, какие операции нужны для такой генерализации:
Склейка веев по длине
Двухвейка в одновейку
Упрощение геометрии
Схлопывание развязок
Нужно ли сохранять, скажем, в п.п. 1 и 4 ограничения скорости и прочие атрибуты дорожной сети на кусках дорог?
По п.2 - как определить, что два набора веев - это на самом деле одна дорога?
EDIT: Вот еще подумал. Кажется, не с того конца беремся. Смысл упрощать OSM->OSM с сохранением роутинга? Не лучше ли отдельно упрощать роутинговый граф (а фиг его упростишь кроме тривиальных вещей) и отдельно векторный слой карты. Во втором случае можно с двухвейками особо и не морочиться - подумаешь, будут два вея поверх друг друга отрисованы. Упростить геометрию, да и дело с концом.
Единственный момент - какие хайвеи выбросить. Выброшеные хайвеи не должны влиять на связность сети, а могут влиять только на локальный роутинг. По этому поводу у меня где-то была статья по теме “Highway hierachies”. Кстати, там они получали роутинг по полной статической карте европейской страны за время в единицы миллисекунд.
Это самый главный вопрос и есть. Видимо, по близости, при том что объединяемые веи односторонние и разнонаправленные. Одинаковые значения name/ref тоже должны намекнуть.
Затем, чтобы получить обзорную карту разумного размера, пригодную для навигации (в навигаторах). OSM->OSM здесь для того, чтобы можно было сделать OSM->MP стандартными средствами, а не изобретать импорт из постгис/шейпов.
Разумеется, генерализация дорожного графа и лесов-болот - две разные подзадачи.
Во втором случае дороги вообще не актуальны. Важен первый случай.
Выбрасывать по статусу. Для начала выкинуть tertiary и ниже.