Pull to refresh

Comments 29

UFO just landed and posted this here
К сожалению этим страдает не статья
Этим страдаю я.
Если вы видите ошибки орфографии и семантики — ткните пальцем(в приват)
по другому не умею, к сожалению.
UFO just landed and posted this here
UFO just landed and posted this here
Отсюда вывод — чем больше хороших постов, тем выше поднимется грамотность ;)
Один из бонусов предложеной системы — она может обрабатывать очень много запросов.
На системе с 3000 человеками в день и НЕДЕЛЬНЫМ! кешем каждый день обрабатывалось более 56378(данные на 26.08) плиток которые были в не кеше.
Колличесво запрашиваемых плиток я сказать не могу — для скорости просто не учитывал
отличная статья. Открываются новые(старые) возможности. Спасибо!

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

2kashey: Да, скорость не критична, но не мешайте нам общаться :)
Может быть вопрос не совсем в тему.
Можно ли как нибудь использовать гуглокарты без инета, а еще лучше с gps'ом?
Потому что после гуглокарт всякие системы навигации совсем не впечатляют.
Нунасколько я в курсе платная версия гуглямапсплус как раз может это делать.
А еще есть www.ruslapland.ru/gps.htm может цеплять карты гугля совершенно безвозмездно
UFO just landed and posted this here
Надо быть добрее и не перенимать западную манеру мыслить деньгами :)
Раз уж это придумал не я: то будем считать что «я просто разместить обьяву!»
Спасибо, отлично!
На мою карту кроме меня никто ещё не ходит, но лучше сразу сделать правильно.

Только вот почему «плитки» — дословный перевод tiles?
Ещё где-нибудь такой термин применяется?
Может проще и понятнее — «квадрат»?
квады, а лучше — тайлы (геймдев-термин)
Тайлы они и есть :)
Только вот первый человек которому я это объяснял что такое тайлы не знал, так как геймдевом не увлекалась.
Вот решили называть плитками :)
Как-то «правильный» вариант сразу пришел в голову после прочтения постановки задачи. Хотя я как раз тем самым Quad-деревом не так давно сталкивался, похоже это и натолкнуло…
Как и обещал, задаю вопрос по алгоритму:

При вычислении границ тайлов используется вот такая формула:
if(n<4){yconsdel=(y1cons+y2cons)/2; ydel=consar[yconsdel];}
else {ydel=Math.round((y1+y2)/2);}

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

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

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

Лично я в данный момент использую как базис реальное Quad-tree из нод которой беру как адреса тайлов, так и координаты обьектов.
Без таких хитростей при наличие на карте пары тысяч маркеров начинаются тормоза
следует также указать что описаный в блоге способ не до конца «солвед»
Иногда бывают случае когда тайл сдвигается вверх чуть больше чем надо.
Скажем так.
вверху получается один ряд не видимых тайлов, а в низу — дырка.
Красивого решения через яндекс карты — я не обнаружил.
Сильно легче эмулировать тайлы ручками самостоятельно
Sign up to leave a comment.

Articles