Это было только к вопросу о тайлах, на которых хорошо видны дороги и НП. Ещё там есть супер-вещь, названия дорог рендерятся не на их кусочках, а полностью на дороге!
Задача 4. Сделать наконец сервис по POI на основе OSM для пользователей. Должно быть чем то вроде 2gis и Afisha.ru в одном флаконе. Чтобы была онлайн карта, на эту карту можно было поднять все пои определенного типа (например, все рестораны, заправки или супермаркеты), щелкнуть по маркеру пои, посмотреть подробности: название, адрес, телефон, часы работы описание (из тега descripton). Чтобы пользователи имели возможность оставлять комментарии и ставить рейтинг. Ну и чтобы был поиск, по типу, по названию, по телефону, адресу и проч.
Вот эта задача мне актуальна в рамках другой, собственной задумки. Не знаю, выделю ли когда-либо время на её реализацию, но всё-таки.
Дык вот первый же возникший вопрос - а есть ли источник тайлов (с покрытием хотя бы по России) без прорисованных POI и названий? Или придётся свои рендерить?
PS: Если вопрос банальный/некорректный - просьба ногами не пинать, с миром OSM тесно не знаком (так, рисую родной город потихоньку, да немного другие по результатам поездок), а технологическая фрагментированность в опенсорсе очень высока, сложно сходу найти ответы на многие вопросы
LinFor, насколько мне известно нет, поэтому и собирались делать свой тайловый сервер, но до него еще руки не дошли.
Дык вот первый же возникший вопрос - а есть ли источник тайлов (с покрытием хотя бы по России) без прорисованных POI и названий? Или придётся свои рендерить?
Простейший вариант. В левую руку берём cloudmade… Правой настраиваем его под себя. Нам нужен рендер совсем без POI. Это легко, тысячи их. Я себе недавно вот такой накрутил:
http://maps.cloudmade.com/?lat=55.771733&lng=37.592543&zoom=17&styleId=43412
У простого способа, как водится большие минусы:
- Редактор Cloudmade мягко говоря “не очень гибкий”.
- Обновляется Cloudmade c боооольшой задержкой.
Задача 2. Сделать автоматический тест рутинга. Цель таже - обнаруживать вандальные удаления дорог.
Исходные данные: OSM карта в польском формате, в нарезке по областям. (Хотя польский формат более желателен, можно как исходный файл взять и *.osm, в той же нарезке)
Что программа должна сделать: по исходному файлу построить список городов, и между городами построить маршруты (для простоты можно кратчайшие), по дорогам не ниже tertiary. Построенные маршруты сравнить с эталонными. Отклонение от эталонного маршрута может говорить о том, что какой-то вей вандально удален.
Это позволит обнаруживать те некорректные правки, которые не обнаруживаются другими средствами, например валидатором связности. Поскольку графу дорог присуща довольно высокая связность, если даже удалить кусок транка, граф дорог все равно останется связным, но маршрут, проходивший через удаленный сегмент дороги перестроится как-то по другому.
Технология: Любая, которая способна породить исполняемый файл под Win или перл.
Также можно сделать вебморду для показа текущего и эталонного маршрута, а также для того чтобы можно было отметить текущий маршрут как эталонный.
Кому будет полезно: всем кто пользуется рутингом на основе OSM.
Что такое “эталонный маршрут” и откуда он берется?
Хотя полезным будет даже сравнивать длину кратчайшего маршрута с расстоянием по прямой - позволит выделить для последующего ручного анализа места, подозрительные на предмет удаления или просто отсутствия участков дорог, которая должны были бы быть.
Что такое “эталонный маршрут” и откуда он берется?
Хотя полезным будет даже сравнивать длину кратчайшего маршрута с расстоянием по прямой - позволит выделить для последующего ручного анализа места, подозрительные на предмет удаления или просто отсутствия участков дорог, которая должны были бы быть.
Как обычно при автоматическом тестировании, за эталон принимаются результаты первого прохода программы, в данном случае - валидатора. Если результаты N-го прохода отличаются от первого, это значит что рутинг существенно изменился, и надо разбираться, почему.
Про корованы забыли…
Самый главный корован, который надо ограбить - сделать, чтобы в дневниках на osm.org можно было отвечать на комменты, и приходили уведомления об ответах на почту.
А вот ещё интересная задачка.
Дано: растр, libjpeg.
Надо: пропатчить libjpeg/gdal так, чтобы пиксели со значением (0,0,0) не оказывали никакое влияние на тот спектр, который будет записан для блока самим libjpeg.
Подробнее: https://plus.google.com/u/0/101291029394395748419/posts/T5vyUKGkPjF
Если это сделать, то геотиффы с фотографиями (а-ля Великие Луки http://latlon.org/maxi?zoom=10&lat=56.40796&lon=30.54385&layers=0000000000000FF0000FBF)) можно будет спокойно делать не 50-, а 3-4-меабайтными, без боязни того, что на склейках вылезут чёрные края от артефактов сжатия jpeg.
А вот ещё интересная задачка.
Да, это задачка скорее для математиков, чем для программистов. Известно, что аудиокодеки, например Vorbis использует Linear prediction для того, чтобы избежать артефактов в начале и конце трека(в случае, когда они начинаются/заканчиваются не тишиной). А тут поневоле придётся изобретать Bilinear prediction.
без боязни того, что на склейках вылезут чёрные края от артефактов сжатия jpeg.
Не проще ли отказаться от jpeg для таких тайлов, и использовать png ?
usm78-gis, внутри geotiff’a мешать jpg и png? Это ещё страшнее
Суть вопроса как раз не в том, чтобы раздавать конечную мозаику в jpeg (там, как раз, ничего страшного, если на границе чёрного с цветным что-то вылезет - кому надо, попросят у wms png), а в том, чтобы при хранении/выкладке в интернеты один геотифф занимал не 50-200 мегабайт, а 4-10, как исходная фотография.
при хранении/выкладке в интернеты один геотифф занимал не 50-200 мегабайт, а 4-10, как исходная фотография.
Тогда все равно придется декларировать новый (приватный) кодек
для геотиффа и читать его никто не сможет.
Впрочем убогие программы и deflate то не понимают
Выкладывайте тогда
уж jpeg2000, хотя я в душе тоже скорее сторонник обновленного геотиффа
кому надо, попросят у wms png
Хм, покажите реальную статистику пользователей josm, запрашивающих format=image/png.
Тогда все равно придется декларировать новый (приватный) кодек
для геотиффа и читать его никто не сможет.
Cо времён gdal 1.8.0 geotiff умеет хранить битовую маску NODATA в сжатом виде: http://www.gdal.org/frmt_gtiff.html
“Новый” кодек декларировать необязательно:
- тупые программы не поймут jpeg вообще (они нас и так не интересуют, всё на базе gdal его умеет);
- программы, не умеющие читать сжатую битовую маску NODATA - покажут всё, и по краям нарисуют разводы размером с jpeg-овский блок - неприятно, но и нефатально;
- target-программы (gdal 1.8 плюс поддержка mask со стороны софта, mapserver 6.0+ в частности) - покажут только то, что будет разрешено маской, соответственно, на новое раскодированное значение бывших чёрных пикселей глубоко наплевать.
Плюс от такого подхода - убирается “грязь” на склейках.
Как-то так.
ЗАДАЧА 5.
Cоздание компактной обзорной карты России. Данные ОСМ хорошо подходят для создания крупномасштабных и, в меньшей степени среднемасшабных карт.Требуется примерно следующее. Надо выкачивать все дороги секондари и выше, все тауны и выше, ЖД, воду, берег, границы областей и упрощать это всё.
Плюс ко всему, результаты этой трансформации должны регулярно (например ежедневно) выгоняться (и выкладываться в интернет) либо обратно в OSM-файл (чтобы заинтересованные стороны могли его обрабатывать стандартными средствами), либо в mp.
Технология: Любая, но на выходе должне быть OSM или mp.
Открываю книгу (простенькую, но всё же …) - Берлянт А.М. Картография, М.:2001, стр. 129.
Глава 7. Картографическая генерализация
7.1. Сущность генерализации…
Процесс генерализации труднее других картографических процессов поддаётся формализации и автоматизации. Не все этаппы могут быть алгоритмизированы, не все критерии удаётся однозначно формализовать. Качество генерализации во многом зависит от понимания картографом содержательной сущности изображаемых объектов и явлений, умения выявить главные типичные их особенности. Опыт показывает, что автоматизация картографической генерализации должна опираться на интерактивные, диалоговые процедуры, обеспечивающее активное участие картографа.
Господа программисты, вперёд
fserges, речь идет о том, чтобы из данных осм сделать маломальски годную мелкомасштабную карту, в частности, обзорную карту России (а так же карты Мира, Евразии) пригодную для навигации, а не об отыскании Чаши Грааля или Семи Городов Сиболы.
Что-то мне подсказывает (я про генерализацию читал в нескольких темах форума) что требование к генерализации выставлены как раз “об отыскании Чаши Грааля”. Чёткая узкая задача решаема (решена ?), глобальная абстрактная однозначно требует вдумчивого участия картографа.
Например, можно глянуть сюда - http://www.openstreetmap.org/?lat=55.88&lon=38.15&zoom=6&layers=M Тут правильно проведена генерализация?
fserges, речь как бы о генерализации графа дорог. По ссылке его нет - там просто картинка.
liosha, читаем первоисточник
ЗАДАЧА 5.
Cоздание компактной обзорной карты России. Данные ОСМ хорошо подходят для создания крупномасштабных и, в меньшей степени среднемасшабных карт.Требуется примерно следующее. Надо выкачивать все дороги секондари и выше, все тауны и выше, ЖД, воду, берег, границы областей и упрощать это всё.
При этом ключевое слово здесь - упрощать. Т.е. нужно сделать генерализацию данных, чтобы получилась карта масштаба, например 1:1 000 000- 1:10 000 000.
ну а картинка это просто графическое представление модели. Мне же не выдрать данные из которых mapnik создаёт картинку.
fserges, кроме первоисточника неплохо бы ещё прочесть и обсуждение, чтобы понимать, в какую сторону разговор ушёл.
И кстати, если я ничего не путаю, эта картинка ни фига не генерализована, а просто нарисована в мелком масштабе.