Чуток добавил. Хотелось бы всё же видеть результат и тогда уже набивать туда информацию.
По-хорошему, сделать бы online-разбор этого перевода. Т.е. какая-либо страничка на вики, куда народ постит значения новых тегов, перевод их, значки их и это дело онлайн-рисовалка-искалка тегов подхватывает и тут же отрисовывает. В таком режиме можно будет силами сообщества отточить “смотрелку карты” “до блеска”.
Ну и модульность и гибкость кода ресурса, чтобы не переписывать в будущем, а дописывать…
П.С. сам в веб программировании ни бум-бум. Только си и баш.
Это было только к вопросу о тайлах, на которых хорошо видны дороги и НП. Ещё там есть супер-вещь, названия дорог рендерятся не на их кусочках, а полностью на дороге!
Вот эта задача мне актуальна в рамках другой, собственной задумки. Не знаю, выделю ли когда-либо время на её реализацию, но всё-таки.
Дык вот первый же возникший вопрос - а есть ли источник тайлов (с покрытием хотя бы по России) без прорисованных POI и названий? Или придётся свои рендерить?
PS: Если вопрос банальный/некорректный - просьба ногами не пинать, с миром OSM тесно не знаком (так, рисую родной город потихоньку, да немного другие по результатам поездок), а технологическая фрагментированность в опенсорсе очень высока, сложно сходу найти ответы на многие вопросы
Что такое “эталонный маршрут” и откуда он берется?
Хотя полезным будет даже сравнивать длину кратчайшего маршрута с расстоянием по прямой - позволит выделить для последующего ручного анализа места, подозрительные на предмет удаления или просто отсутствия участков дорог, которая должны были бы быть.
Как обычно при автоматическом тестировании, за эталон принимаются результаты первого прохода программы, в данном случае - валидатора. Если результаты N-го прохода отличаются от первого, это значит что рутинг существенно изменился, и надо разбираться, почему.
Самый главный корован, который надо ограбить - сделать, чтобы в дневниках на osm.org можно было отвечать на комменты, и приходили уведомления об ответах на почту.
Да, это задачка скорее для математиков, чем для программистов. Известно, что аудиокодеки, например 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+ в частности) - покажут только то, что будет разрешено маской, соответственно, на новое раскодированное значение бывших чёрных пикселей глубоко наплевать.
Плюс от такого подхода - убирается “грязь” на склейках.