Если есть уже как минимум две компании, которые успешно решили данную задачу — значит это возможно. Насколько я могу судить со стороны они решили эту проблему отдавая все 100% объектов только на максимуме зума и существенно понижая его минимальном зуме, т.е. Если выделить хоть всю Москву, то при мелком масштабе(зуме) отсилы 1% подгружается, а при максимальном — 100%, но на очень ограниченной области. Хотя я могу и ошибаться.
В JOSM же при редактировании стоит выделить город целиком, так сразу пытается загрузить все 100% объектов которых разумеется 50к+ и приходится долго и муторно выделять по всему городу и прогружать отдельные мелкие участки, в которых надо что-либо исправить.
Однажды вопрос КАК про геокодер в OL я уже задавал, на что получил ответ — «качай XML? загружай к се в базу, и ищи в ней». Надо сказать не очень удобное решение, поэтому надеюсь здесь есть хоть ктото кто знает способ как хоть по всему миру выполнять поиск без загрузки к себе огромных массивов данных как это сделано в геокодере Яндекса и Google.
Порой приходится вносить коррективы в РАЗНЫЕ районы одно и тогоже города или небольшого региона/местности. И это сложновато сделать при многочисленных непрогруженных «белых пятнах» в редакторе ибо чтобы выяснить какой участок карты следует прогрузить детальнее нужно видеть общую картину, но и она в 50к не влезает. Размах куда меньше, чем вся Москва к примеру, но все же более 50к+
Простоты использования. то что у Яндекса делается в 1 строчку, тут в несколько промежуточных преобразований выливается ито до аналога Placemark с интерактивным baloon както не видно. Чего не хватает: placemark.name = "Название";
placemark.description = "Описание";
Placemark.setIconContent(...);/code>
И прочие опции класса перечисленные на api.yandex.ru.
И еще обратной функции: placemark.getCoordPoint()
Еще раз напоминаю - возможно это уже все есть, но хотелось бы видеть примеры, желательно работающие.
«Почему в OSM ограничение на 50000 объектов за раз?» — это как раз понятно. Вопрос в том почему нельзя бОльшую область разбить на более мелкие куски чтоб серваку было не так напряжно.
PS Респект gis-lab.info, ибо кроме них про OL в Рунете тишина… Еще бы найти способ применять диффы прозрачно и при необходимости по запросу пользователя(например если он увеличил какойлибо небольшой участок, то проверить наличие обновлений по оному).
Ссылку в студию! Иначе беспочвенной утверждение. А еще я про рунет именно что-то упоминал и не про то как «связаться» и все, а как именно «повлиять», порой надоедает писать письма уходящие в «никуда».
Господа, ведь изначально просил ссылку на примерчик, нет вот надо снова и снова писать мол «вы не знаете, вы не умеете», а ответов подкрепленных примерами по теме никак.
ЗЫ Про маркеры ссылки смотрел, немного не то имер ввиду, а аналог YMaps.Placemark.
Конечно надеюсь что не в XML)) Без обвязки XML тегов итого меньше будет.
Вывод: какже тяжело наверно живется Гуглу и Яндексу с обработкой бОльших объемов да еще и реалтайм.
PS Загрузку 50к+ объектов из базы никак нельзя автоматически побить на кусочки поменьше(скажем по 5000) и загрузить их последовательно один за другим? Заметил что точки треков примерно так и загружаются.
1. Да, но это значит что сдвиг нужно еще и привязать к фактическому расположению редактируемого участка или формулу вывести(смотря что проще будет если проанализировать данные о сдвиге в различных регионах). Ведь это возможно, да?
2. Проблема в 2ной работе. Работы итак непочатый край с добавлением новых объектов и адресов, а тут еще старые перепроверять.
3. Всего 1 вопрос — что такого особенного в Народных картах Яндекса, что у них нет таких проблем на техже областях отрисовки? А суточные диффы? И как их применять без вмешательства админов ресурсов прозрачно для пользователя, чтобы в любой момент времени пользователь видел актуальные данные — пусть не ежеминутные, но хотябы суточные?
PS Когда аргументы кончаются или просто ответов больше нет очень часто говорят «вам стоит изучить вопрос или RTFM» — мегауниверсально, но редко помогает увы. Однако я пытаюсь не тока указать на недостатки, но и предлагаю варианты решения их. Если же эти вопросы уже давно решены — я буду рад прочесть мануал(или пример) по ссылке которую укажите в своем ответе, пожалуйста, дайте ссылку на исчерпывающий ответ на вопросы по теме, вдруг и правда не видел ее ранее. Только плиз не нада ответов в стиле «Идите на openlayers.org — там все есть.»
Лично мне больше нравится чтото типа этого: var GPoints=[.....];
if(yandex) PL.setPoints(GPoints);
if(google) PL = new GPolyline(GPoints,"#ff0000",5,0.5);
PS Я лично не фанат какого либо одного API. ИМХО всему свое применение, но нельзя отрицать очевидный факт более активного развития API Яндекса и Google на основе обращений их пользователей(особенно в Яндекс.Клубе), а вот OpenLayers хоть и Open но по факту разрабатывается гдето вдалеке от рунетчиков и повлиять на него в разы сложнее чем на коммерческие API.
Ну я обычно читаю API всех используемых систем — наверное это привычка.
Но вы так и не ответили на вопрос про генерацию трека из массива.
PS Можно просто ссылку дать, если есть где еще почитать.
1. Может и Bing виноват, может и слой OSM в данной области был отрисован кемто кто не знал про сдвиг слоя. Почему то ни с Гуглом ни с Яндексом таких явных проблем нет, спутниковая подложка очень неплохо подогнана. Если к примеру во всем виноват Bing, то почему нельзя ввести поправочные коэффициенты для этого слоя во всех редакторах изначально? Нет нада этим озадачить всех разрабов/редакторов — пусть каждый раз начинают работу с подгонки слоев!
2. По сути тут предлагается более жесткая модерация изменений. Если комуто лень отрисовать «на совесть» то лучше уж и не надо и уж тем более не надо фантазировать над теми участками где невозможно разглядеть что это. Ато достали уже отмечать каждый массив гаражей или автостоянку как жилые здания.
3. Зачем качаю? Да так… спортивный интерес просто, дай думаю заполняемость и адреса проставлю в РАЗНЫХ частях города. Аннет — район города (с десяток кварталов) оказывается — это уже слишком большой кусок(закачка в 1 поток разумеется). Про зеркальные API уже писал ранее — актуальность инфы рулит, просто кешить нужно и подкачивать тока дельты, а не все с 0 каждый раз.
Про объемы ОЗУ просто убило… да в наше время 4гигами никого уже не удивишь, но сравнение откровенно диких торможений при работе в OSM и при отрисовки того же участка Народных Я.Карт — скорость отрисовки, правки, сохранения отличается на пару порядков и все реалтайм и с 1 актуального источника и без всяких там дампов с отставанием по времени.
4. Речь не про интерфейс поиска на сайте OSM, а через API OL. Эдакий аналог класса Geocoder у Яндекса и Google.
Да не нужен мне ни формат KML ни GPS. Есть простой набор координат (широта+долгота+время) в базе, я хочу по ним построить трек к примеру. В данный момент как заглушку я сделал генерацию GPX файла realtime по запросу с дальнейшей подгрузкой его как GPX файлслоя, но это както не спортивно — 2 запроса к вебсерверу вместо одного.
Про маркеры — просто сравните с Яндексовским классом YMaps.Placemark и его свойствами и методами.
1. Откровенно убивает просто постоянный сдвиг слоя Bing и OSM. F также то, что невозможно его сохранить и установить по умолчанию как в онлайн редакторе так и JOSM. Каждый раз смещение приходится или снова подгонять или как минимум загрузить ранее созданный preset.
2. Огромное кол-во объектов отрисованных «как рука взяла», т.е. выходит двойная работа с исправлением ошибок.
3. Постоянные сбои загрузки объектов и сообщения об отказе загрузки более 50к объектов за 1 запрос, т.е. даже для регионального центра приходится загружать кеш объектов и обновлять их поквартально! Что убивает кучу времени просто. Скачать 1 раз готовое — не предлагать ибо обновления происходят ежедневно, причем судя по времени затраченного на обновление объектов в области в JOSM перекачивается все повторно, про online редактор вообще молчу.
4. Почтовая индексация адресов зданий заполняется отсилы в 10% случаев ато и меньше. Интерфейс поиска по адресу online гдето «пропал» или небыл вообще. Перекачивать xml ежедневно и искать по оффлайновой копии както не современно.
Лучше бы дали ссылки на примеры с API OpenLayers… Яндекса и Google итак валом примеров.
И пожалуйста поближе к реальным задачам к конечным юзерам без геодезического образования.
Ну там трек построить, метки с тегами добавить, маршрут проложить, расстояние прикинуть, информационные слои подгружать не только с Open...Map сайтов.
Да, пробовал. Но до этого поближе познакомился с API Google Maps и Яндекс.Карт.
Может быть в области рисования различных проекций OpenLayers силен, но чтобы рядовой трек по точкам из массива(а не GPX файла) вывести с удобно читаемыми комментариями к маркерам — так тут уже затык(или просто особый подход нужен, не как у Я или G).
Также поражает катастрофически малое число примеров использования в Рунете, ибо предпочитают юзать слой OSM совместно с API Google что снова накладывает ограничения.
В связи с ограничениями на использования картографических материалов Яндекса и Google OSM остается практически единственным инструментом широкого применения (в т.ч. и коммерческого), однако его «родной» API OpenLayers крайне сыроват и недостаточно функционален по сравнению с API Google Maps и API Яндекс.Карт. В связи с этим присоединяюсь к вопросу Fatal1ty и задам еще один вопрос:
Кто-нибудь (персоны, сообщества и т.п.) уже занимался доработкой API OpenLayers дабы сделать его более удобным, простым и доступным для широкого применения?
В JOSM же при редактировании стоит выделить город целиком, так сразу пытается загрузить все 100% объектов которых разумеется 50к+ и приходится долго и муторно выделять по всему городу и прогружать отдельные мелкие участки, в которых надо что-либо исправить.
placemark.name = "Название";placemark.description = "Описание";
Placemark.setIconContent(...);/code>
И прочие опции класса перечисленные на api.yandex.ru.
И еще обратной функции: placemark.getCoordPoint()
Еще раз напоминаю - возможно это уже все есть, но хотелось бы видеть примеры, желательно работающие.
В теории все звучит красиво. Или ссылку на сервис этим пользующийся.
PS Респект gis-lab.info, ибо кроме них про OL в Рунете тишина… Еще бы найти способ применять диффы прозрачно и при необходимости по запросу пользователя(например если он увеличил какойлибо небольшой участок, то проверить наличие обновлений по оному).
Господа, ведь изначально просил ссылку на примерчик, нет вот надо снова и снова писать мол «вы не знаете, вы не умеете», а ответов подкрепленных примерами по теме никак.
ЗЫ Про маркеры ссылки смотрел, немного не то имер ввиду, а аналог YMaps.Placemark.
Вывод: какже тяжело наверно живется Гуглу и Яндексу с обработкой бОльших объемов да еще и реалтайм.
PS Загрузку 50к+ объектов из базы никак нельзя автоматически побить на кусочки поменьше(скажем по 5000) и загрузить их последовательно один за другим? Заметил что точки треков примерно так и загружаются.
2. Проблема в 2ной работе. Работы итак непочатый край с добавлением новых объектов и адресов, а тут еще старые перепроверять.
3. Всего 1 вопрос — что такого особенного в Народных картах Яндекса, что у них нет таких проблем на техже областях отрисовки? А суточные диффы? И как их применять без вмешательства админов ресурсов прозрачно для пользователя, чтобы в любой момент времени пользователь видел актуальные данные — пусть не ежеминутные, но хотябы суточные?
PS Когда аргументы кончаются или просто ответов больше нет очень часто говорят «вам стоит изучить вопрос или RTFM» — мегауниверсально, но редко помогает увы. Однако я пытаюсь не тока указать на недостатки, но и предлагаю варианты решения их. Если же эти вопросы уже давно решены — я буду рад прочесть мануал(или пример) по ссылке которую укажите в своем ответе, пожалуйста, дайте ссылку на исчерпывающий ответ на вопросы по теме, вдруг и правда не видел ее ранее. Только плиз не нада ответов в стиле «Идите на openlayers.org — там все есть.»
var GPoints=[.....];if(yandex) PL.setPoints(GPoints);
if(google) PL = new GPolyline(GPoints,"#ff0000",5,0.5);
PS Я лично не фанат какого либо одного API. ИМХО всему свое применение, но нельзя отрицать очевидный факт более активного развития API Яндекса и Google на основе обращений их пользователей(особенно в Яндекс.Клубе), а вот OpenLayers хоть и Open но по факту разрабатывается гдето вдалеке от рунетчиков и повлиять на него в разы сложнее чем на коммерческие API.
Но вы так и не ответили на вопрос про генерацию трека из массива.
PS Можно просто ссылку дать, если есть где еще почитать.
2. По сути тут предлагается более жесткая модерация изменений. Если комуто лень отрисовать «на совесть» то лучше уж и не надо и уж тем более не надо фантазировать над теми участками где невозможно разглядеть что это. Ато достали уже отмечать каждый массив гаражей или автостоянку как жилые здания.
3. Зачем качаю? Да так… спортивный интерес просто, дай думаю заполняемость и адреса проставлю в РАЗНЫХ частях города. Аннет — район города (с десяток кварталов) оказывается — это уже слишком большой кусок(закачка в 1 поток разумеется). Про зеркальные API уже писал ранее — актуальность инфы рулит, просто кешить нужно и подкачивать тока дельты, а не все с 0 каждый раз.
Про объемы ОЗУ просто убило… да в наше время 4гигами никого уже не удивишь, но сравнение откровенно диких торможений при работе в OSM и при отрисовки того же участка Народных Я.Карт — скорость отрисовки, правки, сохранения отличается на пару порядков и все реалтайм и с 1 актуального источника и без всяких там дампов с отставанием по времени.
4. Речь не про интерфейс поиска на сайте OSM, а через API OL. Эдакий аналог класса Geocoder у Яндекса и Google.
Про маркеры — просто сравните с Яндексовским классом YMaps.Placemark и его свойствами и методами.
1. Откровенно убивает просто постоянный сдвиг слоя Bing и OSM. F также то, что невозможно его сохранить и установить по умолчанию как в онлайн редакторе так и JOSM. Каждый раз смещение приходится или снова подгонять или как минимум загрузить ранее созданный preset.
2. Огромное кол-во объектов отрисованных «как рука взяла», т.е. выходит двойная работа с исправлением ошибок.
3. Постоянные сбои загрузки объектов и сообщения об отказе загрузки более 50к объектов за 1 запрос, т.е. даже для регионального центра приходится загружать кеш объектов и обновлять их поквартально! Что убивает кучу времени просто. Скачать 1 раз готовое — не предлагать ибо обновления происходят ежедневно, причем судя по времени затраченного на обновление объектов в области в JOSM перекачивается все повторно, про online редактор вообще молчу.
4. Почтовая индексация адресов зданий заполняется отсилы в 10% случаев ато и меньше. Интерфейс поиска по адресу online гдето «пропал» или небыл вообще. Перекачивать xml ежедневно и искать по оффлайновой копии както не современно.
И пожалуйста поближе к реальным задачам к конечным юзерам без геодезического образования.
Ну там трек построить, метки с тегами добавить, маршрут проложить, расстояние прикинуть, информационные слои подгружать не только с Open...Map сайтов.
Может быть в области рисования различных проекций OpenLayers силен, но чтобы рядовой трек по точкам из массива(а не GPX файла) вывести с удобно читаемыми комментариями к маркерам — так тут уже затык(или просто особый подход нужен, не как у Я или G).
Также поражает катастрофически малое число примеров использования в Рунете, ибо предпочитают юзать слой OSM совместно с API Google что снова накладывает ограничения.
Кто-нибудь (персоны, сообщества и т.п.) уже занимался доработкой API OpenLayers дабы сделать его более удобным, простым и доступным для широкого применения?