Написал примитивный роутер для прокладки маршрута по данным ОСМ, тоже столкнулся с тем что надо проверять связность и достижимость вершин графа, обратил внимание на unclassified. Как-то их многовато в одном классе, целая половина от общего числа. А что конкретно Вы имели в виду под проверкой классификации?
Вообще-то их должно быть существенно больше половины.
Сама классификация должна иметь вид пирамиды, в основании которой unclassified, а в вершине - trunk. В идеале количество дорог, приходящихся на один класс, должно экспонециально возрастать от trunk к unclassified.
PS. Честно говоря, не очень понял, как Вам удалось написать роутер, если Вам незнакомо понятие генерализации. Или роутер работает на РС (а не на плншете/смартфоне) и ограничен только национальными рамками?
А под “проверкой классификации” _sev подразумевает проверку соответствия статуса в OSM и значения ref.
Лише для того щоб рендер на різних рівнях масштабування показував все з математичною красою?
Так, на вигляд напевне що буде надзвичайно красиво. Але я вважаю, що це буде різновидом маппінгу під рендер.
Дороги прокладують не за математичними формулами, а під потреби людей в транспорті. І документально закріплюють їх приналежність до мережі доріг районного, обласного і т.д. значення відповідно до їх ролей в транспортній інфраструктурі. Очевидно що кількість доріг в кожному з класів обумовлена об’єктивними географічними і демографічними факторами. Математика мені теж подобається, але “такова c’est la vie” 
ну да, на пирамидку смахивает. Посчитано по экстракту с Украиной от 2012 11 26:
NODE TAG highway COUNT 17266
WAY TAG highway COUNT 334345
W highway VALUE motorway COUNT 68
W highway VALUE motorway_link COUNT 147
W highway VALUE trunk COUNT 3438
W highway VALUE trunk_link COUNT 1424
W highway VALUE primary COUNT 6005
W highway VALUE primary_link COUNT 1420
W highway VALUE secondary COUNT 9827
W highway VALUE secondary_link COUNT 847
W highway VALUE tertiary COUNT 16133
W highway VALUE tertiary_link COUNT 454
W highway VALUE unclassified COUNT 31474
W highway VALUE residential COUNT 115212
W highway VALUE living_street COUNT 3768
W highway VALUE service COUNT 64529
W highway VALUE proposed COUNT 6
W highway VALUE footway COUNT 24221
W highway VALUE track COUNT 33670
W highway VALUE pedestrian COUNT 1801
W highway VALUE steps COUNT 3562
W highway VALUE path COUNT 8658
W highway VALUE cycleway COUNT 54
W highway VALUE bridleway COUNT 132
W highway VALUE road COUNT 6909
есть еще пара десятков битых тагов, с неправильными именами.
С понятием генерализации знаком, но да, роутер на PC и пока работает в пределах этого кусочка.
По поводу валидации тегов ref- с наскоку получилась вот такая картинка для WAYs (если надо - могу детализировать):
H- :primary_link COUNT 1
H- :secondary COUNT 4
H- :primary COUNT 56
O- :tertiary COUNT 15
M- :trunk COUNT 39
M- :secondary COUNT 2
M- :primary COUNT 4
M- :trunk_link COUNT 14
T- :secondary_link COUNT 7
T- :unclassified COUNT 5
T- :tertiary COUNT 27
T- :motorway_link COUNT 1
T- :primary COUNT 37
T- :secondary COUNT 683
C- :residential COUNT 14
C- :unclassified COUNT 36
P- :tertiary COUNT 1
E- :trunk COUNT 1
Отнюдь.
Генерализация - достаточно общее понятие, чтобы не ограничиваться рамками одного применения.
Насколько мне известно, данные OSM преимущественно используются в 3 областях:
- Изготовление карт и планов (если хотите - рендер).
- Маршрутизация и навигация.
- Адресный поиск.
Существуют, конечно, и другие применения, но эти 3, как мне представляется, наиболее распространены.
Если Вы приведете другие сферы применения, попытаюсь объяснить, как в них можно использовать генерелизацию.
Тепеь по этим трем: - Коль скоро Вы сами упомянули о рендере, думаю, зачем генерализация нужна рендеру, Вам объясныть не нужно.
- Навигация/маршрутизация, как правило, осуществляются при помощи маломощных портативных устройств с небольшим объемом оперативной памяти и малой производительностью центрального процессора. Поэтому “переварить” дорожный граф целиком такое устройство просто не в состоянии. Поэтому обычно используется комбинированный метод, при котором “короткие” маршруты строятся по небольшому локальному фрагменту карты, а “дальние” - разбиваются на три участка: начальный - по локальному фрагменту вблизи точки старта, средний - по обзорной карте, конечный - по локальному фрагменту вблизи точки финиша. Так вот, обзорная карта - и есть результат генерализации дорожного графа. Разумеется, кроме описанного выше упрощенного подхода может быть использование не одной обзорной карты, а генерализованных карт нескольких уровней.
- А адресный поиск, в отличие от рендера и маршрутизатора, без жесткой генерализации вообще немыслим, хотя бы из-за наличия в разных городах одноименных улиц.
Кстати, генерализация охватывает не только дороги, но и населенные пункты, а также объекты различной природы (внутри одной схемы генерализации), например, страна-область-район-город-микрорайон-улица-дом-квартира.
Однако, следует заметить, что “роль в транспортной инфраструктуре” и “за счет какого бюджета содержится дорога” - не совсем одно и то же.
И принципы, на основе которых строится генерализация, могут не совпадать с принципами, которыми пользуются органы власти соответствующих уровней для “документального закрепления” тех или иных дорог за теми или иными бюджетами.
Если объединить *_link с соответствующими основными дорогами (а лучше - вообще их выбросить - на *_link указывать ref вообще не нужно), то картина станет куда прозрачней.
А все отклонения от этой картинки, по сформулированным http://wiki.openstreetmap.org/wiki/Uk:Key:highway правилам являются ошибками и должны быть исправлены.
Правда, лично у меня вызывает некоторое сомнение рациональность такого подхода. По сути у него единственное преимущество - наличие простого и надежного алгоритма верификации по формальным признакам. Все остальное - недостатки.
Нужно ли кому-то детализировать - не знаю. Лично мне - нет, я и так могу собрать любую нужною мне статистику в пределах БСССР. Больше статистики, чем я способен переварить.
Якісь трохи замалі числа… Ви мабуть латинське Н писали замість кириличного?
Можна також порівняти протяжність всіх ліній адже серєдня довжина trunk і primary ліній більша ніж у residential.
Відредагував основну статтю. В основному оновлював інформацію, використовуючи зміни, що відбулися за цей час в російській версії, зокрема додав кілька емпіричних правил для визначення статусу доріг. Із суттєвого, це написав, що С-###### дороги можуть бути як tertiary, так і unclassified (яскравий приклад - це Донецька область, в якій чомусь майже немає О-###### доріг, і більшість доріг віднесена до категорії С, хоча всі вони мають бути tertiary).
Плохо их выкидывать.
Общую длину дороги будет тяжелее контролировать при сравнении с документами