Гуглякартим по умному

[@kashey]

К сожалению этим страдает не статья
Этим страдаю я.
Если вы видите ошибки орфографии и семантики — ткните пальцем(в приват)
по другому не умею, к сожалению.

[@Treg]

Отсюда вывод — чем больше хороших постов, тем выше поднимется грамотность ;)

[@kashey]

Один из бонусов предложеной системы — она может обрабатывать очень много запросов.
На системе с 3000 человеками в день и НЕДЕЛЬНЫМ! кешем каждый день обрабатывалось более 56378(данные на 26.08) плиток которые были в не кеше.
Колличесво запрашиваемых плиток я сказать не могу — для скорости просто не учитывал

[@Aristei]

Благодарю за нужный материал!

[@l_nagash]

отличная статья. Открываются новые(старые) возможности. Спасибо!

Надо будет разобраться подробнее…

[@kashey]

Наверное было бы полезно еще рассказать как ИМХО лучше организовать сам процесс передачи данных с клиента на сервер.
JSON и XML я сам сразу советую выбросить и забыть.
Я не понимаю и не признаю людей для которых использование модных инструментов является самоцелью, посему хочу вам напомнить, что маркер это табличный элемент.
Передача 100 маркеров — это передача 100 строк некой таблицы
А для передачи таблиц есть очень хороший формат csv.
Ну и на самой передачи данных можно экономить, например передавать координаты относительно начала того блока котором сидит обьект
Или примерно также экономить полигональные данные, или для передачи чисел кодировать все в HEX- если задаться целью можно сильно уменьшить трафик между клиентом и вашим сервером.
Но судя по всему — никому тут это не надо.
Все прутся от официальных переводов хреновых туториалов по гуглямапам :(
Эх ребят — у вас все еще впереди

[@Kigorw]

парсинг формата цсв будет быстрее функции eval?

[@kashey]

csv будет весить в 10 раз меньше.
А временем парсинга на самом деле можно пренебречь — оно сильно меньше времени передачи данных

[@middle]

Запросто. eval должен сначала сделать лексический и семантический разбор, а потом обработать результат разбора. Для csv нужен фактически только лексический разбор, да и тот будет быстрее, т.к. регекспы проще.

[@Kigorw]

Технически верно, но ведь эвал он то встроенная функция, а парсинг это джс код, который парсится джс движком.
Кто-то сверял скорость?

[@kashey]

повторяю еще раз.
Скоростью парсинга в данном случае можно пренебречь.
Особенно в данном, когда мы качаем данные маленькими блоками.
В принципе большинство сервисов всеже используют JSON — это их право.
Использовать его или не использовать должен каждый решить для себя сам.
Я вообще сейчас частично перехожу на передачу информации картинками, с последующим раздиранием картинки в байтовый поток.
Типа можно с разных хостов данные грузить и не париться

[@middle]

Код скрипта парсится при загрузке. Парсинг выполняется с помощью регекспов, которые тоже встроенные.

2kashey: Да, скорость не критична, но не мешайте нам общаться :)

[@silentroach]

выделите код в тег <pre>
или пропустите через специальный сервис
а то совсем читать неудобно

[@Popik]

Может быть вопрос не совсем в тему.
Можно ли как нибудь использовать гуглокарты без инета, а еще лучше с gps'ом?
Потому что после гуглокарт всякие системы навигации совсем не впечатляют.

[@sleepwalker]

Нунасколько я в курсе платная версия гуглямапсплус как раз может это делать.
А еще есть www.ruslapland.ru/gps.htm может цеплять карты гугля совершенно безвозмездно

[@kashey]

Надо быть добрее и не перенимать западную манеру мыслить деньгами :)
Раз уж это придумал не я: то будем считать что «я просто разместить обьяву!»

[@shuba]

Спасибо, отлично!
На мою карту кроме меня никто ещё не ходит, но лучше сразу сделать правильно.

Только вот почему «плитки» — дословный перевод tiles?
Ещё где-нибудь такой термин применяется?
Может проще и понятнее — «квадрат»?

[@sovnarkom]

квады, а лучше — тайлы (геймдев-термин)

[@kashey]

Тайлы они и есть :)
Только вот первый человек которому я это объяснял что такое тайлы не знал, так как геймдевом не увлекалась.
Вот решили называть плитками :)

[@acornbreeze]

По-умному, по-другому и так далее.

www.gramota.ru/slovari/dic/? word=%EF%EE-%F3%EC%ED%EE%EC%F3&all=x

[@Regis]

Как-то «правильный» вариант сразу пришел в голову после прочтения постановки задачи. Хотя я как раз тем самым Quad-деревом не так давно сталкивался, похоже это и натолкнуло…

[@Prophet]

Как и обещал, задаю вопрос по алгоритму:

При вычислении границ тайлов используется вот такая формула:

if(n<4){yconsdel=(y1cons+y2cons)/2; ydel=consar[yconsdel];}
else {ydel=Math.round((y1+y2)/2);}

Долго думал, так и не понял, почему после 4-ой итерации мы больше не пользуемся массивом для нормирования Y-коодинаты.
Понимаю, что алгоритм не ваш, но всё же любопытно )

Более очевидным кажется алгоритм из LatLon2Tile с mapki.com, хотя пока не сравнивал результаты.

[@kashey]

вообще данную операцию можно и не производить, лично я от нее в последствии отказался
ее цель малек оквадратить тайл.
Вообще самая красивая реализация — через сами тайлы карты( такая методика была описана на яндекс-конфе), а как привести Я-тайлы в координатную сетку гугла(для единообразия адресации) я описывал в блоге я-карт

Лично я в данный момент использую как базис реальное Quad-tree из нод которой беру как адреса тайлов, так и координаты обьектов.
Без таких хитростей при наличие на карте пары тысяч маркеров начинаются тормоза

[@nod]

вот ссылочка про то что говорит kashey
как привести Я-тайлы в координатную сетку гугла

Если ссылка перестанет работать, юзайте поиск в клубе яндекс карт: «Итак — Google тайлы на яндекс картах — SOLVED»

[@kashey]

следует также указать что описаный в блоге способ не до конца «солвед»
Иногда бывают случае когда тайл сдвигается вверх чуть больше чем надо.
Скажем так.
вверху получается один ряд не видимых тайлов, а в низу — дырка.
Красивого решения через яндекс карты — я не обнаружил.
Сильно легче эмулировать тайлы ручками самостоятельно