Актуальные задачи, требующие искусства программирования

Я так-то знаю, но там какая-то секретная ссылка раньше была чтобы смотреть все данные ОСМ. Сейчас что-то изменилось?

Короче, там флеш.

Ну а раз тайлы уже есть, задача упрощается, надо просто красиво их показывать :slight_smile:

Чуток добавил. Хотелось бы всё же видеть результат и тогда уже набивать туда информацию.

По-хорошему, сделать бы online-разбор этого перевода. Т.е. какая-либо страничка на вики, куда народ постит значения новых тегов, перевод их, значки их и это дело онлайн-рисовалка-искалка тегов подхватывает и тут же отрисовывает. В таком режиме можно будет силами сообщества отточить “смотрелку карты” “до блеска”.

Ну и модульность и гибкость кода ресурса, чтобы не переписывать в будущем, а дописывать… :slight_smile:

П.С. сам в веб программировании ни бум-бум. Только си и баш. :frowning:

Что-то поиска там не нашёл по тегам. На kosmosnimki.ru поиск адреса не работает.

Это было только к вопросу о тайлах, на которых хорошо видны дороги и НП. Ещё там есть супер-вещь, названия дорог рендерятся не на их кусочках, а полностью на дороге!

Вот эта задача мне актуальна в рамках другой, собственной задумки. Не знаю, выделю ли когда-либо время на её реализацию, но всё-таки.

Дык вот первый же возникший вопрос - а есть ли источник тайлов (с покрытием хотя бы по России) без прорисованных POI и названий? Или придётся свои рендерить? :slight_smile:

PS: Если вопрос банальный/некорректный - просьба ногами не пинать, с миром OSM тесно не знаком (так, рисую родной город потихоньку, да немного другие по результатам поездок), а технологическая фрагментированность в опенсорсе очень высока, сложно сходу найти ответы на многие вопросы :slight_smile:

LinFor, насколько мне известно нет, поэтому и собирались делать свой тайловый сервер, но до него еще руки не дошли.

Простейший вариант. В левую руку берём cloudmade… Правой настраиваем его под себя. Нам нужен рендер совсем без POI. Это легко, тысячи их. Я себе недавно вот такой накрутил:
http://maps.cloudmade.com/?lat=55.771733&lng=37.592543&zoom=17&styleId=43412
У простого способа, как водится большие минусы:

  • Редактор Cloudmade мягко говоря “не очень гибкий”.
  • Обновляется Cloudmade c боооольшой задержкой.

Что такое “эталонный маршрут” и откуда он берется?
Хотя полезным будет даже сравнивать длину кратчайшего маршрута с расстоянием по прямой - позволит выделить для последующего ручного анализа места, подозрительные на предмет удаления или просто отсутствия участков дорог, которая должны были бы быть.

Как обычно при автоматическом тестировании, за эталон принимаются результаты первого прохода программы, в данном случае - валидатора. Если результаты 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 для таких тайлов, и использовать png ?

usm78-gis, внутри geotiff’a мешать jpg и png? Это ещё страшнее :slight_smile:

Суть вопроса как раз не в том, чтобы раздавать конечную мозаику в jpeg (там, как раз, ничего страшного, если на границе чёрного с цветным что-то вылезет - кому надо, попросят у wms png), а в том, чтобы при хранении/выкладке в интернеты один геотифф занимал не 50-200 мегабайт, а 4-10, как исходная фотография.

Тогда все равно придется декларировать новый (приватный) кодек
для геотиффа и читать его никто не сможет.
Впрочем убогие программы и deflate то не понимают :wink:
Выкладывайте тогда
уж jpeg2000, хотя я в душе тоже скорее сторонник обновленного геотиффа :slight_smile:

Хм, покажите реальную статистику пользователей 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+ в частности) - покажут только то, что будет разрешено маской, соответственно, на новое раскодированное значение бывших чёрных пикселей глубоко наплевать.

Плюс от такого подхода - убирается “грязь” на склейках.

Как-то так.

Открываю книгу (простенькую, но всё же …) - Берлянт А.М. Картография, М.:2001, стр. 129.

Господа программисты, вперёд :wink:

fserges, речь идет о том, чтобы из данных осм сделать маломальски годную мелкомасштабную карту, в частности, обзорную карту России (а так же карты Мира, Евразии) пригодную для навигации, а не об отыскании Чаши Грааля или Семи Городов Сиболы.