Pamarkin
Город:
На ХТ с: 2011 года
Сообщений: 2 Профессия:
Интересы:
ICQ:
WWW:
На ХТ с: 2011 года
Сообщений: 2 Профессия:
Интересы:
ICQ:
WWW:
Репутация: 3
Профиль: на форуме
На сайте был 14/03/2011
Отправить личное сообщение
Найти сообщения пользователя
Найти темы пользователя
Зафрендить / Заигнорить
Профиль: на форуме
На сайте был 14/03/2011
Отправить личное сообщение
Найти сообщения пользователя
Найти темы пользователя
Зафрендить / Заигнорить
no report, no news, no articles, no funny...but we have a last posts :)
наверняка сразу надо кэшировать трек для нескольких представлений - для нескольких зумов с разным количеством точек
довольно логичною только это делается по-другому. см. мой предыдущий пост - надо делать тайловый кэш
делается не так, но алгоритмы есть.
да. только не на каждый зум.
почитайте тут http://habrahabr.ru/blogs/google/115198/
bigmir использует mapia со своими картами и своим api на flash. к гуглу и яндексу не имеет отношения. Плюс работает на flash, который не поддерживается iOs.
при большом количестве точек (> 10000) нет смысла в кэше xml. тем более передавать его на клиента весь.
у гугла и яндекса - разная модель мира (у гугла - шар, у яндекса - эллипсид Кроссовского).
но совместить можно
Это делал мой хороший знакомый.
не проблема.
не проблема
Не более, чем игрушка
Это по точкам. С треками все веселее.
сайты с треками
загрузить и показать один трек - ни разу не проблема.
проблема показать все имеющиеся треки.
рисовать на гуглокартах хотя бы 20 треков средствами api и javascript - нереально.
посмотрите, как velosamara рисует свои полтора трека... и посморите на ie 7 или 8.
решить эту проблему можно другим способом, а именно отрисовкой и кэшированием картинок с треками. но вот отслеживание мыши поверх этих треков - гимор.
Quote:
Вывод треков. Трудно сказать будет ли все именно так и работать - но мысли запишу.
1. Трек(полным набором точек) пусть будет в базе лежать. Если рядом оригинал в виде файла - тем лучше - проще для скачивания.
2. При добавлении трека обязательно в базу пишутся несколько коэффициентов высчитываемых, к которым потребуется потом быстрый доступ. Это - минимальная широта и минимальная долгота и максимальная широта и максимальная долгота. Т.е. фактически "прямоугольник в который вписан трек". И плюс длина трека. И точки начала и конца.
1. Трек(полным набором точек) пусть будет в базе лежать. Если рядом оригинал в виде файла - тем лучше - проще для скачивания.
2. При добавлении трека обязательно в базу пишутся несколько коэффициентов высчитываемых, к которым потребуется потом быстрый доступ. Это - минимальная широта и минимальная долгота и максимальная широта и максимальная долгота. Т.е. фактически "прямоугольник в который вписан трек". И плюс длина трека. И точки начала и конца.
наверняка сразу надо кэшировать трек для нескольких представлений - для нескольких зумов с разным количеством точек
Quote:
3. Алгоритм отображения "всех треков" на карте одновременно потребует определенного геморроя. Пока я это вижу так:
а) - Существует "пользовательская карта треков" - просто статический файл с изображенными на нем всеми треками этого типа (статкарта). При добавлении трека в этот файл дописываются данные. Этот файл выводится на мальньких увеличениях, при клике на нем пишется "для рассматривания отдельных треков увеличьте карту".
б) - На разумных увеличениях переходим на вывод отдельных треков. Но не настоящих треков, а "упрощенных треков". - "упротреков". Т.е., грубо говоря, если в треке 115 точек, а он при текущем увеличении вырождается визуально в точку, то нет смысла выводить в слой все его 115 точек - достаточно одну. Как это реализовывать.
а) - Существует "пользовательская карта треков" - просто статический файл с изображенными на нем всеми треками этого типа (статкарта). При добавлении трека в этот файл дописываются данные. Этот файл выводится на мальньких увеличениях, при клике на нем пишется "для рассматривания отдельных треков увеличьте карту".
б) - На разумных увеличениях переходим на вывод отдельных треков. Но не настоящих треков, а "упрощенных треков". - "упротреков". Т.е., грубо говоря, если в треке 115 точек, а он при текущем увеличении вырождается визуально в точку, то нет смысла выводить в слой все его 115 точек - достаточно одну. Как это реализовывать.
довольно логичною только это делается по-другому. см. мой предыдущий пост - надо делать тайловый кэш
Quote:
Шаг третий - веселый - у нас есть карта на экране. Мы знаем координаты при текущем увеличении. Например диагональ в километрах составляет 2000 км. А в пикселях диагональ карты 500 пикселей. Значит 1 пиксель это 4 км. Смотрим толщину линии, которой рисуется трек. Допустим 5 пикселей. Значит точность линии 20 км. Теперь читаем трек. Первая точка - отображается всегда. Смотрим расстояние до второй. 1 км. Про наличие второй точки - забываем. Смотрим расстояние до второй. 4 км. Забыли. До третьей. 8. Забыли. До четвертой(от первой) 25. Её наносим - смотрим дальше от неё. До пятой(уже от четвертой) 5. Забываем. И так далее. До последней. Последняя(как и первая) вносится всегда. В результате в упрощенный трек из реального может попасть ОЧЕНЬ мало точек. Например две из 500. Или 5 из 1000. Что является неплохим уменьшением пожираемых ресурсов, фактически не ухудшая картинку визуально.
делается не так, но алгоритмы есть.
Quote:
Полученный упротрек пишется в файл и в дальнейшем, при выводе этого трека при таком же увеличении просто берется этот статический упротрек. Размер кеша будет равен количеству треков*на количество увеличений, при которых выводятся треки, а не статкарта.
да. только не на каждый зум.
почитайте тут http://habrahabr.ru/blogs/google/115198/
Quote:
Карты должны быть похожи при выводе точек(треков) на http://map.bigmir.net/ (но карта должна быть слева - меню справа)
bigmir использует mapia со своими картами и своим api на flash. к гуглу и яндексу не имеет отношения. Плюс работает на flash, который не поддерживается iOs.
Quote:
xml координат слоев надо кешировать - переделывая только в момент добавления нового объекта соответствующего типа.
при большом количестве точек (> 10000) нет смысла в кэше xml. тем более передавать его на клиента весь.
Quote:
карты надо делать как яндекс, так и гугль(а потом возможно и еще кто-то) - объяснение механизма и пример:
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7125
http://webmap-blog.ru/?p=395
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7125
http://webmap-blog.ru/?p=395
у гугла и яндекса - разная модель мира (у гугла - шар, у яндекса - эллипсид Кроссовского).
но совместить можно
Quote:
Это делал мой хороший знакомый.
Quote:
Прилепить сверху яндекса подключаемый слой топографического генштаба
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7286
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7419
Процесс протестирован - работает в целом. Расскажу как.
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7286
http://clubs.ya.ru/mapsapi/replies.xml?item_no=7419
Процесс протестирован - работает в целом. Расскажу как.
не проблема.
Quote:
Карта и слой точек должны иметь свой урл. Чтобы можно было отдельно залинковать "велопарковки в Харькове" или "источники Караби".
не проблема
Quote:
Вот еще интересный скрипт для ознакомления http://habrahabr.ru/blogs/php/81007/#habracut
Не более, чем игрушка
Это по точкам. С треками все веселее.
сайты с треками
Quote:
http://velosamara.ru/navigator/ViewPLT. ... egory_id=2
http://veloserver.ru/?menuitem=1
http://velo-obninsk.ru/index.php?board=23.0
http://veloserver.ru/?menuitem=1
http://velo-obninsk.ru/index.php?board=23.0
загрузить и показать один трек - ни разу не проблема.
проблема показать все имеющиеся треки.
рисовать на гуглокартах хотя бы 20 треков средствами api и javascript - нереально.
посмотрите, как velosamara рисует свои полтора трека... и посморите на ie 7 или 8.
решить эту проблему можно другим способом, а именно отрисовкой и кэшированием картинок с треками. но вот отслеживание мыши поверх этих треков - гимор.
Друзья:
Полезные ссылки
Сайты друзей
© "Харьков Турист" 2003-2023 При копировании любых материалов с этого
сайта прямая ссылка на сайт обязательна