Да, это задачка скорее для математиков, чем для программистов. Известно, что аудиокодеки, например Vorbis использует Linear prediction для того, чтобы избежать артефактов в начале и конце трека(в случае, когда они начинаются/заканчиваются не тишиной). А тут поневоле придётся изобретать Bilinear prediction.
usm78-gis, внутри geotiff’a мешать jpg и png? Это ещё страшнее
Суть вопроса как раз не в том, чтобы раздавать конечную мозаику в jpeg (там, как раз, ничего страшного, если на границе чёрного с цветным что-то вылезет - кому надо, попросят у wms png), а в том, чтобы при хранении/выкладке в интернеты один геотифф занимал не 50-200 мегабайт, а 4-10, как исходная фотография.
Тогда все равно придется декларировать новый (приватный) кодек
для геотиффа и читать его никто не сможет.
Впрочем убогие программы и deflate то не понимают
Выкладывайте тогда
уж jpeg2000, хотя я в душе тоже скорее сторонник обновленного геотиффа
тупые программы не поймут jpeg вообще (они нас и так не интересуют, всё на базе gdal его умеет);
программы, не умеющие читать сжатую битовую маску NODATA - покажут всё, и по краям нарисуют разводы размером с jpeg-овский блок - неприятно, но и нефатально;
target-программы (gdal 1.8 плюс поддержка mask со стороны софта, mapserver 6.0+ в частности) - покажут только то, что будет разрешено маской, соответственно, на новое раскодированное значение бывших чёрных пикселей глубоко наплевать.
Плюс от такого подхода - убирается “грязь” на склейках.
fserges, речь идет о том, чтобы из данных осм сделать маломальски годную мелкомасштабную карту, в частности, обзорную карту России (а так же карты Мира, Евразии) пригодную для навигации, а не об отыскании Чаши Грааля или Семи Городов Сиболы.
Что-то мне подсказывает (я про генерализацию читал в нескольких темах форума) что требование к генерализации выставлены как раз “об отыскании Чаши Грааля”. Чёткая узкая задача решаема (решена ?), глобальная абстрактная однозначно требует вдумчивого участия картографа.
Обсуждение может менять направление 100 раз. Именно для для этого в шапке темы всегда пишут актуальное состояние проблемы, постановка задачи так сказать …
По поводу картинки я и спросил - а что не так с генерализацией на приведённой странице. Чем алгоритм mapnik плох? Понимание этого позволит задачу поставить чётче.
fserges, mapnik не производит никакой генерализации. Чтобы отрисовать картинку 256х256, из базы достаются те же самые сотни мегабайт информации. Рекомендую посмотреть на конфигурацию сервера, рендерящего тайлы, и сравнить его с конфигурацией любого навигатора.
подозреваю, что имеется ввиду следующее
генерализация - процесс сворачивания гигабайтного файла до 10 метров (например) с возможностью навигации и поиска городов/стран по ним, упрощенными линиями и т.д.
а мапник, чтоб отрисовать тайл на 6-12 масштабе выкачает все данные этого квадрата в оперативку и там их начнет мучить. то-есть сам мапник не делает генерализации, он только рисует самое важное на данном зуме, как в правилах написано.
Вот то что написал Larry0ua гораздо более похоже на постановку задачи для программиста
И всё же я готов поспорить - mapnik делает генерализацию Только его упор - на визуальное представление тогда как я понимаю задача Zkir - сохранение каких-то свойств дорожного графа. Т.е. генерализация для разных задач разная!