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