Комментарии 158
Не прошло и полугода, как этот АПИ заметили на maps.yandex.ru. Достойный ответ для leaflet
Это не главные конкуренты, но, думаю, теперь о достойном ответе уже надо задуматься им самим ;)
Да вот только после Leaflet отношение к Яндекс.Картам API 2.0 — как в злом анекдоте: «теперь ты мнэ нэ нужэн».
Маршруты этот Leaflet, например, строить не умеет…
Это замечание справедливо. Leaftlet — исключительно картоотображающий движок. Кому нужно построение маршрутов, тот да воспользуется Project OSRM, или сервисом Cloudmade, или OpenRouteService, или YourNavigation.org, как Zverik нам рекомендовал позавчера.
Ничего против леафлета не имею — великолепная система. Некоторые моменты сделаны просто изумительно. Хотя местами конечно слишком легковесный.
Теперь будет на одну великолепную систему больше.
Теперь будет на одну великолепную систему больше.
А какими местами слишком легковесный, чего явно не хватает?
Я не говорил что не хватает.
Мое высказывание можно считать что он имеет слишком прямую архитектуру.
Хотя для большинства пользователей это наверное плюс.
Мое высказывание можно считать что он имеет слишком прямую архитектуру.
Хотя для большинства пользователей это наверное плюс.
В данном случае сложная архитектура с динамическими модулями нецелесообразна, т.к. в случае необходимости можно легко сделать статический билд с нужными компонентами и загрузить его весь сразу. Хотя на практике даже такой необходимости не возникает — весь запакованный JS-код Leaflet на данный момент занимает 22кб.
Один из плюсов динамических модулей — в браузер приходит сборка именно под конкретный браузер.
Леафлет вообще как-то очень кратко написан.
Некоторые модули Я.Карт обеспечивающие визуально тоже самое — в разы крупнее.
Умнее. И напильников в них больше.
Например ты используешь Sutherland-Hodgeman, а мы Cohen-Sutherland. Графика справляется с многоконтурными полигонами.
Леафлет вообще как-то очень кратко написан.
Некоторые модули Я.Карт обеспечивающие визуально тоже самое — в разы крупнее.
Умнее. И напильников в них больше.
Например ты используешь Sutherland-Hodgeman, а мы Cohen-Sutherland. Графика справляется с многоконтурными полигонами.
Ты уверен насчёт алгоритмов? Cohen-Sutherland — это алгоритм для клиппинга сегментов, Leaflet его тоже использует. Sutherland-Hodgeman — для полигонов. Никаких проблем с многоконтурными полигонами нет.
Насчёт краткости — она, как говорится, сестра таланта. :) Больше напильников — не значит умнее.
Насчёт краткости — она, как говорится, сестра таланта. :) Больше напильников — не значит умнее.
Ой значит.
У тебя в очень многих места очень многие вещи не учтены.
Хотя о некоторых таких вещах нормальным людям знать не требуется.
Но ничего — в скором времени будет Субботник в Киеве — можно будет плотно поболтать.
У тебя в очень многих места очень многие вещи не учтены.
Хотя о некоторых таких вещах нормальным людям знать не требуется.
Но ничего — в скором времени будет Субботник в Киеве — можно будет плотно поболтать.
Ага, есть проблемы с многоконтурыми.
В SVG\VML используется тип заливки even-odd.
В canvas я как-то этого не заметил.
В SVG\VML используется тип заливки even-odd.
В canvas я как-то этого не заметил.
Разъясни, пожалуйста. А еще лучше тест-кейс на jsfiddle.net/ — пока по этому поводу не жаловались.
jsfiddle.net/r2u6r/1/
там полигон с самопересечением + дополнительный контур.
Можно переключится между svg или canvas.
При переключении fillRule потребуется дернуть полигон мышкой чтобы он перерисовывался(новая бага, спасибо тебе)
там полигон с самопересечением + дополнительный контур.
Можно переключится между svg или canvas.
При переключении fillRule потребуется дернуть полигон мышкой чтобы он перерисовывался(новая бага, спасибо тебе)
Насчёт сборки под конкретный браузер — в Leaflet'е кода с браузерными костылями от силы наберётся пару килобайт. Так что тоже несущественно.
<style>
*, table, div, img {
padding:5;/* joomla style */
margin: 5;
max-width: 100%;/* drupal style */
}
И прощай Google,Yandex1,Leaflet.
Вторая версия от этого защищена, но сколько крови и браузерных костылей это принесло… эх
max-width — единственный момент, который я позволил себе исправить с помощью !important и считаю это хорошим оправданным решением. А вот для всех дивов и картинок паддинги с марджинами устанавливать — это уже идиотизм какой-то, пускай разработчики сами исправляют, тем более что проблема в отличии от max-width лежит на поверхности.
Ну, лично я, например, в этом сильно сомневаюсь. На настоящий момент это просто разного калибра вещи.
Я бы не сказал. Просто Leaflet — это только JS-библиотека (и сервисы к ней выбираются отдельно по вкусу — CloudMade, Mapbox, MapQuest, Bing, etc.), а API Яндекс.Карт — это JS-библиотека + сервисы в одном флаконе. Но если говорить только о библиотеках — они вполне сравнимы.
Посмотрите на слои активных областей и редактор графики, например, прикиньте, сколько там кода.
Достаточно хорошо представляю — редактор графики появится в след. версии, пока реализован редактор полилайнов/полигонов, в несжатом виде 5кб. С кругами/прямоугольниками, возможностью перетаскивания и поворота будет больше, но появится достаточно скоро (скорей всего выделенное в отдельный плагин).
Активные области — опять же эта штука service-specific, но вот, к примеру, есть надстройка поверх Leaflet от GisCloud, умеющая отображать миллионы интерактивных точек на карте.
Активные области — опять же эта штука service-specific, но вот, к примеру, есть надстройка поверх Leaflet от GisCloud, умеющая отображать миллионы интерактивных точек на карте.
У Leaflet есть одно неоспоримое преимущество, которое Яндексу будет трудно преодолеть: открытый исходный код и open-source-сообщество.
Можно подумать у Яндекса мало opensource проектов :P
А открытый исходный код…
Подключите
А открытый исходный код…
Подключите
<script src="http://api-maps.yandex.ru/2.0/?load=package.full&mode=debug&lang=ru-RU" type="text/javascript">
Вообще-то да, как-то бедненько как для такой большой серьёзной компании. :)
И открытый исходный код я имел в виду в широком смысле, а не прямом. Открытый для contribution'ов.
И открытый исходный код я имел в виду в широком смысле, а не прямом. Открытый для contribution'ов.
Но библиотеки для карт среди них всё-таки нет. :)
github.com/yandexmobile/ :P
Но js-карты — да, не замечены.
Но js-карты — да, не замечены.
Кстати, спасибо за ссылку на Leaflet в первом комментарии — всегда рад куче трафика с Хабра. :)
Рад, что отменили ключи.
Приятная мелочь — убрали велосипеды.
// Было
var p1 = new YMaps.GeoPoint(4, 5);
var p2 = new YMaps.GeoPoint(1, 2);
var b = new YMaps.GeoBounds(p1, p2);
// Стало
var p1 = [4, 5];
var p2 = [1, 2];
var b = [p1, p2];
Еще и координаты больше не перепутаны
Спорный вопрос. Вот так вот сделать console.log(p1), а потом думаешь — что это за массив с числами? А что это за массив с массивом чисел?
Имхо, в движке их лучше оставить, но чтобы можно было передавать массивом, а внутри они уже при необходимости конвертировались. Как-то так:
Имхо, в движке их лучше оставить, но чтобы можно было передавать массивом, а внутри они уже при необходимости конвертировались. Как-то так:
new Rectangle( [1,2], [3,4] );
// equals to:
new Rectangle( new Point(1,2), new Point(3,4) );
Скорее всего это внутри так и есть, иначе с проекциями сложновато бы было работать.
Координаты точки, или пикселя остаются обычным массивом чисел.
Но над этими массивами незримо довлеет геометрия.
Геометрия!=хранимые данные.
Но над этими массивами незримо довлеет геометрия.
Геометрия!=хранимые данные.
Вы знаете, мы тоже так думали. Но, когда мы перешли от работы с точками-объектами к работе с точками — парами координат, то в итоге поняли, что это в разы удобнее.
Т.Е. внутри тоже используются массивы и не кастуются к точкам? А чем удобнее?
Достаточностью?
Хорошо хоть типизированные массивы без разделения на x,y не используются
Хорошо хоть типизированные массивы без разделения на x,y не используются
Достаточностью в чём?
У такого подхода есть куча недостатков, которые достаточно очевидны.
Мне интересны, какие преимущества покрывают эти недостатки.
У такого подхода есть куча недостатков, которые достаточно очевидны.
Мне интересны, какие преимущества покрывают эти недостатки.
Единая разменная монета.
Точка — массив из двух элементов. Линия — массив точек. Полигон — массив линий.
В 99% случаев кроме координат вообще-то ничего более не нужно.
Если нужна математика — отправляешь в нее свои сырые данные кушаешь ответ.
А не лезешь в точку одной точки, чтобы получить расстояние до другой.
Образно говоря — C-style. ООП на уровне данных отсутствует.
Геометрия есть композиция из данных и методов. При этом данные и методы разделены.
Как самый простой вариант — можешь замерить время создания и доступа к массиву точек которые массив и к массиву точек которые «умные».
В хроме можно потом еще на garbage посмотреть, сколько он занял.
А недостатки мне не совсем ясны. Приведи парочку самых самых.
Точка — массив из двух элементов. Линия — массив точек. Полигон — массив линий.
В 99% случаев кроме координат вообще-то ничего более не нужно.
Если нужна математика — отправляешь в нее свои сырые данные кушаешь ответ.
А не лезешь в точку одной точки, чтобы получить расстояние до другой.
Образно говоря — C-style. ООП на уровне данных отсутствует.
Геометрия есть композиция из данных и методов. При этом данные и методы разделены.
Как самый простой вариант — можешь замерить время создания и доступа к массиву точек которые массив и к массиву точек которые «умные».
В хроме можно потом еще на garbage посмотреть, сколько он занял.
А недостатки мне не совсем ясны. Приведи парочку самых самых.
Какая разница, что браузеру создавать — объект сущности Array или объект сущности Point? В JS они равнозначны по сути.
Преимущество — в дебаги. Значительно приятнее по console.log() видеть, что это именно точка, а не массив с непонятными числами.
В точку можно добавить методы, которые будут позволять её обрабатывать легко и красиво.
Преимущество — в дебаги. Значительно приятнее по console.log() видеть, что это именно точка, а не массив с непонятными числами.
В точку можно добавить методы, которые будут позволять её обрабатывать легко и красиво.
p1.round()
// vs
p1[0] = p1[0].round();
p1[1] = p1[1].round();
// vs
geometry.round( p1 );
////////////////////
p1.equals(p2)
// vs
p1[0] == p2[0] && p1[1] == p2[1]
// vs
geometry.isPointEquals(p1, p2)
Лишние конструкторы — лишние тормоза. Точек слишком много, чтобы над каждой вызывать конструктор — оч дорого как по времени так и попамяти.
var point = [1, 2];
point.type = "My debuggable point"; // <<<
// тут какая-то магия и имя поинт попа дает в points
console.log(points[0].type); // undefined
console.log(points[1].type); // My debuggable point!
Браузеры могут оптимизировать работу со стандартными типами и они могут работать значительно быстрее, чем самописные конструкторы.
В FF, например, массив создается в 2 раза быстрее чем Point — jsperf.com/array-vs-point/2 в остальных примерно равно. По памяти не проверял.
В FF, например, массив создается в 2 раза быстрее чем Point — jsperf.com/array-vs-point/2 в остальных примерно равно. По памяти не проверял.
Ну, тут надо вопрос по другому разворачивать — а в чем выигрыш от наличия класса точки?
Т.е., например, вот так код выглядел на классах:
Теперь он выглядит примерно так:
Да, появилось некоторое дублирование, но код стал намного читабельнее и избавился от кучи визуального шума. Кажется, что в условиях отсутствия переопределения операторов, так писать проще и удобнее.
Т.е., например, вот так код выглядел на классах:
var pathCenterDiff = pathPixelBounds.getCenter().moveBy(attractionOffset).diff(centerInTiles),
worldSize = coordSystem.getWorldSize(),
effectivePathSize = new Point(
Math.ceil(pathPixelBounds.getSpan().getX() / worldSize.getX()) || 1,
Math.ceil(pathPixelBounds.getSpan().getY() / worldSize.getY()) || 1
),
effectivePathCenterDiff = new Point(
pathCenterDiff.getX() / worldSize.getX() / effectivePathSize.getX(),
pathCenterDiff.getY() / worldSize.getY() / effectivePathSize.getY()
).apply(Math.round);Теперь он выглядит примерно так:
var pathCenterDiff = [
centerInTiles[0] - (pathPixelBounds.getCenter()[0] + attractionOffset[0]),
centerInTiles[1] - (pathPixelBounds.getCenter()[1] + attractionOffset[1])
],
worldSize = coordSystem.getWorldSize(),
effectivePathSize = [
Math.ceil(pathPixelBounds.getSpan()[0] / worldSize[0]) || 1,
Math.ceil(pathPixelBounds.getSpan()[1] / worldSize[1]) || 1
],
effectivePathCenterDiff = [
Math.round(pathCenterDiff[0] / worldSize[0] / effectivePathSize[0]),
Math.round(pathCenterDiff[1] / worldSize[1] / effectivePathSize[1])
];
Да, появилось некоторое дублирование, но код стал намного читабельнее и избавился от кучи визуального шума. Кажется, что в условиях отсутствия переопределения операторов, так писать проще и удобнее.
Ну не знаю, мне кажется такой окончательный вариант лучше обоих ваших:
Не подумайте, что я критикую только для того, чтобы покритиковать, реально интересно мнение.
var pathCenterDiff, worldSize, effectivePathSize, effectivePathCenterDiff;
worldSize = coordSystem.worldSize;
pathCenterDiff = pathPixelBounds.getCenter()
.moveBy(attractionOffset)
.diff(centerInTiles);
effectivePathSize = pathPixelBounds.getSpan()
.divide(worldSize)
.ceil();
effectivePathCenterDiff = pathCenterDiff
.divide(worldSize)
.divide(effectivePathSize)
.round();
Не подумайте, что я критикую только для того, чтобы покритиковать, реально интересно мнение.
местами, особенно на фронтах, это наверное удобно. И многим привычно.
Но я думаю ты понимаешь насколько это работает медленнее чем обычные операции над массивами.
JS (еще?) не умеет разворачивать функции.
Хотя…
Тоже самое. Процедурный стиль.
Но я думаю ты понимаешь насколько это работает медленнее чем обычные операции над массивами.
JS (еще?) не умеет разворачивать функции.
Хотя…
effectivePathCenterDiff = round(divide( divide(pathCenterDiff, worldSize), effectivePathSize));
Тоже самое. Процедурный стиль.
В Вашем варианте необходимо завести по методу на каждую операцию, чтобы их успешно чайнить. По моему опыту, после первого десятка начинаешь путаться :)
Кстати, а зачем вызывать одни и те же методы по два раза?
Не поверите… сижу сегодня, читаю документацию по api v1, пишу проект.
Бац 404 — новый апи вышел. И самое печальное — документация пока меня не радует. При чем в том числе «новая» документация к первой версии. Такое ощущение что ее урезали.
В целом хочу отблагодарить за новый api и новую кластеризацию в частности. Как раз она будет нужна нам в упомянутом проекте.
Бац 404 — новый апи вышел. И самое печальное — документация пока меня не радует. При чем в том числе «новая» документация к первой версии. Такое ощущение что ее урезали.
В целом хочу отблагодарить за новый api и новую кластеризацию в частности. Как раз она будет нужна нам в упомянутом проекте.
Документация к 1-ой версии осталась в точности в том же виде.
Документация ко второй версии в плане справочника (reference) ничем не уступает первой, а статьи и примеры будут публиковаться по мере их написания.
Приходите 26-го к нам на АПИшник, мы всё покажем и расскажем.
Документация ко второй версии в плане справочника (reference) ничем не уступает первой, а статьи и примеры будут публиковаться по мере их написания.
Приходите 26-го к нам на АПИшник, мы всё покажем и расскажем.
Еще раз решил проверить — виноват. Смотрел совсем не туда, куда нужно. Действительно старая документация не менялась.
пользуясь случаем, хочу спросить вас о чисто прикладной проблеме, как убрать балун у линии? я выполнял заказ и, после нескольких часов исследования проблемы, так и не нашел способа это сделать. а у линий маршрута на карте заказчика не предполагалось никакой дополнительной информации, в отличие от точек, и кликабельность линии с пустой выскакивающей сноской — смотрелась странно,… )
ps: заранее спасибо.
ps: заранее спасибо.
В 1.х — задать опцию hasBalloon у линии или у коллекции
В 2.x балуны по умолчанию не открываются, если у них нет контента. Ну и опция hasBalloon тоже работает :)
В 2.x балуны по умолчанию не открываются, если у них нет контента. Ну и опция hasBalloon тоже работает :)
Пользуясь случаем — вопрос. Неужели в 2.х нет способа заменить контент в балуне? в 1.х надо было всего-лишь написать
В 2.х ничего не нашёл на этот счёт.
placemark.setBalloonContent('text');В 2.х ничего не нашёл на этот счёт.
Посмотрите на пример.
В документации, к сожалению, в этом месте пока дырка.
В документации, к сожалению, в этом месте пока дырка.
Пример этот я изучил. Создание Placemark с заданием контента в Balloon это понятно. Меня интересует момент, когда Placemark создан и добавлен на карту — можно ли после этого взять и изменить контент внутри? Единственный вариант, который пока приходит в голову — пихать в контент balloon какой-нибудь div с id=«myID» и менять контент внутри этого div.
А в 2.0 балун динамически реагирует на изменение тех свойств, которые показывает.
Т.е. в случае дефолтного геообъекта geoObject.properties.set('balloonContent', 'html') контент изменится автоматически.
Т.е. в случае дефолтного геообъекта geoObject.properties.set('balloonContent', 'html') контент изменится автоматически.
А можно примеров побольше? Мне вот буквально сегодня понадобились Яндекс.Карты и рискнул сразу вторую версию прикручивать. Простейше вещи ищу в примерах, но их как-то не хватает :(
Примеров и текстов, конечно, будет больше.
Приходите к нам на АПИшник, мы всё покажем и расскажем.
Приходите к нам на АПИшник, мы всё покажем и расскажем.
Спасибо, буду ждать.
В Москву ехать далековато, жаль.
В Москву ехать далековато, жаль.
Привет! Вы можете посмотреть онлайн трансляцию, если интересно. events.yandex.ru/public/event/online.xml. Начало в 12:30.
угу. а я закончил с картами и почти нашел куда ключ засунуть…
наконец без ключа. спасиб ))))
наконец без ключа. спасиб ))))
Хотелось бы чего-нибудь для декстопа. Хотя бы чтобы можно было интегрировать вместе с окном браузера в свое приложение. Хоть с какой рекламой, но забесплатно.
Насколько я знаю в Win8 это будет нативно — интегрировать js в окошко.
А браузер себе вставить — так и сейчас можно.
А браузер себе вставить — так и сейчас можно.
api.yandex.ru/maps/faq.xml#agreement_5
•Могу ли я использовать API Яндекс.Карт в приложениях, не являющихся интернет-сервисами?
Нет, это запрещено Пользовательским соглашением.
•Могу ли я использовать API Яндекс.Карт в приложениях, не являющихся интернет-сервисами?
Нет, это запрещено Пользовательским соглашением.
Это палка о двух концах, проходили уже в моментах упаковки в телефонные приложения.
Вы совершенно правильно написали.
Но(!) если у вас есть интернет-сервис повторяющий функционал и наполнение приложения — приложение может быть.
Главная суть в том чтобы ваше решение на картах было доступно всем.
На самом деле по TOS нельзя даже в админках(закрытые разделы) карты размещать.
Второй момент — нельзя кешировать у себя тайлы карты, те вы можете сделать приложение, но не можете сделать офлайн приложение.
Уж не говоря о том что вы с технической стороны обязаны загружать АПИ непосредственно с серверов Яндекса.
Вы совершенно правильно написали.
Но(!) если у вас есть интернет-сервис повторяющий функционал и наполнение приложения — приложение может быть.
Главная суть в том чтобы ваше решение на картах было доступно всем.
На самом деле по TOS нельзя даже в админках(закрытые разделы) карты размещать.
Второй момент — нельзя кешировать у себя тайлы карты, те вы можете сделать приложение, но не можете сделать офлайн приложение.
Уж не говоря о том что вы с технической стороны обязаны загружать АПИ непосредственно с серверов Яндекса.
За кластеризацию меток — отдельное спасибо! Главное, что работает из коробки.
Но пока рендерятся ужасно :(
Что вы имеете в виду?
Это просто не совсем удачный пример: работало вкупе с геоокодером (из-за этого задержки).
Вот пример из документации, где можно посмотреть как работает «чистый» кластеризатор.
api.yandex.ru/maps/doc/jsapi/2.x/examples/cluster.html
api.yandex.ru/maps/doc/jsapi/2.x/examples/cluster.html
Интересно, почему Chrome поставили в один ряд с IE9? он что, не поддерживает анимацию transform3d + transition?
>С 12 утра и до 17 вечера
Очень жаль, хотелось бы пойти.
Очень жаль, хотелось бы пойти.
Мы выложим потом презентации докладчиков. Если все сложится, то, возможно, и запись будет.
Добрый день!
У нас получилось организовать онлайн трансляцию. events.yandex.ru/public/event/online.xml. Начало в 12:30.
У нас получилось организовать онлайн трансляцию. events.yandex.ru/public/event/online.xml. Начало в 12:30.
Не профи в этой теме, поэтому хотелось бы узнать: есть/планируется ли api для карты метро? Указал станции — получил маршрут и время.
Подскажите, а где почитать на человеческом, об ограничениях API Карт? Выбор сейчас между OSM и Яндексовскими.
Вы можете договор почитать legal.yandex.ru/maps_api/. Если что-то непонятно, спрашивайте прям тут, расскажу.
Речь, видимо, про лимиты.
Да, о лимитах. Промахнулся — habrahabr.ru/company/yandex/blog/142310/#comment_4762722
Спасибо. Классический выбор между OSM/Гулом и Яндексом. ;)
«…функции геокодирования ограничено 25000 запросов для одного сайта в сутки…». С одной стороны выходит больше, чем у гугла, который считает уже даже любой показ карты — ображением к АПИ. С другой стороны, что будет с Яндекс.Картами, если я выбиваюсь за пределы 25К?
«…функции геокодирования ограничено 25000 запросов для одного сайта в сутки…». С одной стороны выходит больше, чем у гугла, который считает уже даже любой показ карты — ображением к АПИ. С другой стороны, что будет с Яндекс.Картами, если я выбиваюсь за пределы 25К?
OSM, кстати, при большом трафике тоже порой прикрывает доступ к тайлам.
Речь идет не об обращениях к API, а об использовании функции геокодирования. Если превысите, сразу отключать Вас никто не будет. Сначала пришлем предупреждение.
Вы себе представляете что такое 25000 геокодирований в сутки?
Это или миллион пользователей на сайте или наглый робот.
Других лимитов на использование нет.
К тому же — OSM наконец можно показать на Яндекс Картах(как и любые другие тайлы подготовленные для любой проекции)
Это или миллион пользователей на сайте или наглый робот.
Других лимитов на использование нет.
К тому же — OSM наконец можно показать на Яндекс Картах(как и любые другие тайлы подготовленные для любой проекции)
НЛО прилетело и опубликовало эту надпись здесь
У очень многих выражение «получить информацию за платные СМС» вызывает только одну ассоциацию, к сожалению. Надеюсь, операторы однажды это поймут, и все же возьмутся за мошенников… но это мечты, конечно.
Но, да, пункт лицензии запрещает. Разве что сделать прокси-сайт, который будет брать у Яндекса, и отдавать своим подписчикам бесплатно, а подписчиком будет уже сайт с СМС-оплатой :)
Но, да, пункт лицензии запрещает. Разве что сделать прокси-сайт, который будет брать у Яндекса, и отдавать своим подписчикам бесплатно, а подписчиком будет уже сайт с СМС-оплатой :)
Можете.
Вы не в праве требовать деньги за просмотр данных.
То что для занесения данных на карту, либо просмотра более детальных данных нужно что-то сделать — уже не считаете.
Вы не в праве требовать деньги за просмотр данных.
То что для занесения данных на карту, либо просмотра более детальных данных нужно что-то сделать — уже не считаете.
НЛО прилетело и опубликовало эту надпись здесь
Да, сами карты должны быть доступны всем.
Принципы формирования выборки даннных для отображения пользователю — ваша проблема.
Принципы формирования выборки даннных для отображения пользователю — ваша проблема.
А счастье было так возможно…
Задал вопрос в саппорт Яндекса:
" У нас в компании есть внутренний корпоративный портал на основе SharePoint
Мы бы хотели создать веб-часть карты с пробками для нашего региона. Возможно ли использования вашего сервиса?
Данной веб-частью будут пользоваться сотрудники."
Ответ:
«Если это будет закрытый сервис только за сотрудников компании, то будет нарушаться пункт 2.3.2 пользовательского соглашения»
Задал вопрос в саппорт Яндекса:
" У нас в компании есть внутренний корпоративный портал на основе SharePoint
Мы бы хотели создать веб-часть карты с пробками для нашего региона. Возможно ли использования вашего сервиса?
Данной веб-частью будут пользоваться сотрудники."
Ответ:
«Если это будет закрытый сервис только за сотрудников компании, то будет нарушаться пункт 2.3.2 пользовательского соглашения»
Спасибо, обновление очень достойное!
Обратил внимание на многоязычную поддержку. Есть ли теперь автокомплит адреса на разных языках?
Обратил внимание на многоязычную поддержку. Есть ли теперь автокомплит адреса на разных языках?
ммм… стало любопытно зачем в этом примере такая портянка из тегов style? Это как-то связанно с новой версией API?
Это результат работы модульной системы.
Один css модуль — один тэг.
При этом в IE, так как у него проблемы с колличеством обьявлений стилей — все они будут слиты в один стиль.
Приходят же данные(и js и css и даже картинки) в одном файле.
Один css модуль — один тэг.
При этом в IE, так как у него проблемы с колличеством обьявлений стилей — все они будут слиты в один стиль.
Приходят же данные(и js и css и даже картинки) в одном файле.
А почему бы не сделать какой-то контейнер, в который добавлять эти стили, а потом при окончании загрузке модулей этот контейнер бы добавлял один style?
Вот, первый полезный фидбэк.
Я так понимаю, что ты — один из разработчиков API v2?
Человек и пароход.
В том смысле что повезло — разработчик и древнейший пользователь.
Так уж сложилась судьба.
В том смысле что повезло — разработчик и древнейший пользователь.
Так уж сложилась судьба.
О как, esosedi, созданный теми же разработчиками и на основе той же базы wikimapia переехал на yandex api.
Не удивлюсь если до Яндекса раньше работал у них.
Не удивлюсь если до Яндекса раньше работал у них.
Где ж он только не работал.
Подскажите, пожалуйста — не вижу в новом справочнике возможности добавления кастомного копирайта на карту, аналога старого
Я слепой или его нет более?
map.addCopyright('© customCopyright')Я слепой или его нет более?
Это все здорово респект за работу. Но мне все равно не понятно, почему, все пытаются выпустить что то свое. Вот возьмем Гугл, у них есть офигенные карты по всей Европе, а по СНГ нет. Яндекс молодец опередил Гугл тут, но людям теперь нужно использовать Гугл для Европы, Яндекс для СНГ, а это не всегда удобно… что мешает таким компаниям сотрудничать? Обьеденить эти сервиса, а конечный пользователь пусть сам решает что ему удобнее. Может мне кто то это объяснить?
Ближе к вечеру пара сайтов уже перешла на АПИ 2.0.
А библиотеки для Android/iOS доработаете, чтобы можно было и на мобильных платформах пользоваться новыми вкусностями?
Подскажите пожалуйста, могу я как-то по адресу получить район/округ/регион с помощью API, а не только город/страну? Или без КЛАДР/ФИАС не обойтись?
При обратном геокодировании можно получить всю иерархию административного подчинения объекта (город/регион/страна) кроме района города — чтобы получить район, нужно выполнить ещё один запрос к геокодеру с kind=district
Надо было недавно из GPS координат узнать к каким областям России они относятся.
Запросы к geocode-maps.yandex.ru/1.x/?geocode= в половине случаев давали всё что угодно, но не названия областей. Почему поле AdministrativeAreaName нельзя сделать обязательным во всех случаях?
Запросы к geocode-maps.yandex.ru/1.x/?geocode= в половине случаев давали всё что угодно, но не названия областей. Почему поле AdministrativeAreaName нельзя сделать обязательным во всех случаях?
Дайте примеры, пожалуйста.
Например координата 84.8328,56.6133
api-maps.yandex.ru/1.1.21/xml/Geocoder/Geocoder.xml?key=&results=1&geocode=84.8328%2C56.6133 (надо подставить ключ)
Возвращает только CountryName, никакой информации об области, городе.
Сам yandex.maps при вводе этих координат тоже при клике на балун пишет только «Россия».
Пользуясь случаем попрошу ещё один фичреквест: сделайте наконец при расчёте кратчайшего маршрута в МО в результатах километраж от МКАД. Вам проще поддерживать актуальные координаты МКАД в виде API или готовой библиотеке, чем каждый будет городить свой огород, обрисовывая примерно МКАД и съезды с него.
api-maps.yandex.ru/1.1.21/xml/Geocoder/Geocoder.xml?key=&results=1&geocode=84.8328%2C56.6133 (надо подставить ключ)
Возвращает только CountryName, никакой информации об области, городе.
Сам yandex.maps при вводе этих координат тоже при клике на балун пишет только «Россия».
Пользуясь случаем попрошу ещё один фичреквест: сделайте наконец при расчёте кратчайшего маршрута в МО в результатах километраж от МКАД. Вам проще поддерживать актуальные координаты МКАД в виде API или готовой библиотеке, чем каждый будет городить свой огород, обрисовывая примерно МКАД и съезды с него.
Зарепортил ребятам из поиска, обещают починить в ближайшем релизе.
Спасибо за сообщение.
Спасибо за сообщение.
Если кто-то из Google Api читает это, то передаю привет и вам: у вас тоже есть эта проблема.
AdministrativeAreaName встречается также редко, и не является обязательным. Иногда область записана в AddressLine, иногда в LocalityName, иногда в SubAdministrativeAreaName, иногда SubAdministrativeAreaName. Бардак.
AdministrativeAreaName встречается также редко, и не является обязательным. Иногда область записана в AddressLine, иногда в LocalityName, иногда в SubAdministrativeAreaName, иногда SubAdministrativeAreaName. Бардак.
На моем пути с работы домой Я.Карты меня трижды пытаются завести на односторонние улицы, считая их двухсторонними. Ладно, одну из них сделали односторонней «всего» два года назад, но две другие всю жизнь были таковыми.
Это, на фоне длины пути что-то около 10-12 улиц, наводит меня на мысли о не очень точной картографической базе. И как в этой ситуации (с таким подозрением о качестве БД) строить сервисы, опираясь на вас — порой непонятно. Тикеты в саппорт — путь, но не все им идут (т.е. свои-то «три улицы» я сдам — но сколько их по России будет не сдано), а, самое главное, может, просто исходные данные для ваших БП не особо точны?
В любом случае, спасибо, что работаете и развиваетесь!
Очень надеюсь, что качество данных карт возрастет, пока же, и правда, Я.Карты надо использовать как именно карты, а не как источник маршрутов.
Это, на фоне длины пути что-то около 10-12 улиц, наводит меня на мысли о не очень точной картографической базе. И как в этой ситуации (с таким подозрением о качестве БД) строить сервисы, опираясь на вас — порой непонятно. Тикеты в саппорт — путь, но не все им идут (т.е. свои-то «три улицы» я сдам — но сколько их по России будет не сдано), а, самое главное, может, просто исходные данные для ваших БП не особо точны?
В любом случае, спасибо, что работаете и развиваетесь!
Очень надеюсь, что качество данных карт возрастет, пока же, и правда, Я.Карты надо использовать как именно карты, а не как источник маршрутов.
Поздравляю всех карторазрабов!
Первое, что бросается в глаза:
1. возможность использования спрайтов для иконок маркеров
2. все также нет поддержки canvas !(( Каждая точка — 4 DOM-элемента!
3. всплывающая подсказка всплывает только один раз? (потом — тонет? opera 11.62)
4. Клатеризатор — это суперплюс. Буду его сегодня тестировать. Даже догадываюсь, кто его сделал.
5. Если работает touch — то это плюс. наконец-то.
сейчас буду ковырять
Первое, что бросается в глаза:
1. возможность использования спрайтов для иконок маркеров
2. все также нет поддержки canvas !(( Каждая точка — 4 DOM-элемента!
3. всплывающая подсказка всплывает только один раз? (потом — тонет? opera 11.62)
4. Клатеризатор — это суперплюс. Буду его сегодня тестировать. Даже догадываюсь, кто его сделал.
5. Если работает touch — то это плюс. наконец-то.
сейчас буду ковырять
1. Вы и раньше могли задать свой layout и использовать спрайты.
2. Каждая точка — есть то что вы попросили. Сейчас минимально — 2 DOM-элемента.
Метки у нас вообще «very rich», но за это приходится расплачиваться.
А вот canvas есть.
Задайте overlayFactory: interactiveGraphics и иконка молча уйдет в контур графики.
3. Можно поподробнее
4. Не догадываешься 100%.
5. На iPad — вообще летает :)
2. Каждая точка — есть то что вы попросили. Сейчас минимально — 2 DOM-элемента.
Метки у нас вообще «very rich», но за это приходится расплачиваться.
А вот canvas есть.
Задайте overlayFactory: interactiveGraphics и иконка молча уйдет в контур графики.
3. Можно поподробнее
4. Не догадываешься 100%.
5. На iPad — вообще летает :)
1. Имелся в виду класс IconStyle — «коробочный».
2. пока нет времени посмотреть, но очень хочется.
3. api.yandex.ru/maps/doc/jsapi/2.x/examples/hint.html
хинт вспывает 1 раз, потом не появляется ни на том же, ни на другом зуме. опера 11.62, хром 18.0.1025.162 m
4. на APIшник возьму что-нить из ректальнокриптографического… узнАю 146%
5. проверю вечером
не нашел функции tileCoordinates.fromPixels — ручками? )
2. пока нет времени посмотреть, но очень хочется.
3. api.yandex.ru/maps/doc/jsapi/2.x/examples/hint.html
хинт вспывает 1 раз, потом не появляется ни на том же, ни на другом зуме. опера 11.62, хром 18.0.1025.162 m
4. на APIшник возьму что-нить из ректальнокриптографического… узнАю 146%
5. проверю вечером
не нашел функции tileCoordinates.fromPixels — ручками? )
с асинхронной загрузкой не все понятно.
ymaps.ready — можно легко пропустить. может, добавить ymaps.complete?
пришлось писать костыль:
ymaps.ready — можно легко пропустить. может, добавить ymaps.complete?
пришлось писать костыль:
if (this.apiLoadAttemps == 0)
{
$('HEAD').append($('
или как в гугле - callback на загрузку.не прошел код
if (this.apiLoadAttemps == 0)
{
$('HEAD').append($('<script>').attr({id: "ymapsapi", type: "text/javascript", src : "http://api-maps.yandex.ru/2.0/?load=package.full&mode=debug&lang=ru-RU"}));
} else if (this.apiLoadAttemps >= 5) {
alert('Карта не может быть загружена');
return;
};
if (!(window.ymaps && window.ymaps.Map))
{
this.apiLoadAttemps ++;
window.setTimeout( function() { self.initMap.call(self, options) } , 500);
} else {
this.map = new ymaps.Map(this.container.id, {center: [ options.center.lat, options.center.lng], zoom: options.zoom});
};
Можете хотя бы в двух словах описать, как завести пользовательские карты в новой версии API?
А как мне динамически менять координату точки? По json-у получу я её, а как сменить свойство объекта?
Карту создаю примерно так:
Хочу раз в минуту забирать через json координату и обновлять центр карты и положение точки в соответствии с этой координатой. В js я особо не силён.
Карту создаю примерно так:
ymaps.ready(init);
function init() {
var myMap = new ymaps.Map("map", {
center:[55.76, 37.64],
zoom:10
}),
myPlacemark = new ymaps.Placemark([55.8, 37.6]);
myMap.geoObjects
.add(myPlacemark)
}
Хочу раз в минуту забирать через json координату и обновлять центр карты и положение точки в соответствии с этой координатой. В js я особо не силён.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript API Яндекс.Карт — версия 2.0