Форум SAS.Планета

Друзья,
нужна поддержка оформления, например, LineStyle в Викимапия-подобных слоях .kml

Наш поисково-спасательный отряд несколько лет использует SAS Planet для работы с картами и спутниковыми снимками. Мы добровольческий отряд, но при этом официально АСФ (аварийно-спасательное формирование). Мы ищем в природной среде, выводим по телефону. Sun Calculator, ГШ и спутниковые снимки – наше всё. В прошлом году у нас была 1000+ заявок на поиск в природной среде (по некоторым заявкам более одного человека). По 225 заявкам мы вывели по телефону (по солнцу, облакам, ветру и линейным ориентирам), по 50 заявкам мы разыскали людей в природной среде, в лесах и болотах. Некоторые поиски длились до двух недель.

Мы сейчас сделали систему, которая анализирует, отображает и раскрашивает все треки со всех наших поисково-спасательных работ (ПСР) по степени проходимости местности основываясь на показателях скорости и криволинейности движения. Мечтали подключить это всё в единый инструмент - нашу любимую САС Планету, мы сделали веб-сервис который умеет отдавать треки в .kml формате по типу Викимапии и интегрировали этот сервис с нашей базой ПСР, мы можем прямо из карты из описания трека переходить к истории ПСР, читать отчёты групп и прочее. Мы ожидаем что это сократит длительность многих поисков и повысит процент успешных выводов по телефону. Одна проблема, если .kml загружен САС Планетой с википодобного сервиса никакого оформления у него не читается. Те же самые .kml файлы из кеша если их кинуть драг-н-дропом или открыть через меню файл раскрашиваются прекрасно.
В исходниках я увидел коммент //todo: на чтение оформления из kml при загрузке с веба и кажется как будто это должно занять очень разумное время.
Я готов из своего кармана оплатить эту работу. Пожалуйста, оцените эту работу в деньгах и возьмитесь кто-нибудь за поддержку стилей объектов в .kml загруженных с веба. Уже в начале мая наши сограждане толпами пойдут в леса, а нам ещё всё нужно отладить и обучить дежурных руководителей спасработ.

Belkin писал(а):Я готов из своего кармана оплатить эту работу. Пожалуйста, оцените эту работу в деньгах и возьмитесь кто-нибудь за поддержку стилей объектов в .kml загруженных с веба.

Какие будут Ваши доказательства предложения? Предлагайте - а девелоперы уже рассмотрят, если\когда захотят (админ ресурса девелопером не является, но берет на себя обязанности гаранта оплаты заказа девелоперам от лица Вашего имени, см. правила раздела выше).

Parasite писал(а):

Belkin писал(а):Я готов из своего кармана оплатить эту работу. Пожалуйста, оцените эту работу в деньгах и возьмитесь кто-нибудь за поддержку стилей объектов в .kml загруженных с веба.

Какие будут Ваши доказательства предложения? Предлагайте - а девелоперы уже рассмотрят, если\когда захотят (админ ресурса девелопером не является, но берет на себя обязанности гаранта оплаты заказа девелоперам от лица Вашего имени, см. правила раздела выше).

Я не знаю сколько это стоит, работы там на мой взгляд совсем немного и есть образец, но допустим пять тысяч рублей за поддержку тех же стилей что работают при обычном импорте kml.

Belkin писал(а):Я не знаю сколько это стоит, работы там на мой взгляд совсем немного и есть образец, но допустим пять тысяч рублей за поддержку тех же стилей что работают при обычном импорте kml.

Да, там действительно не сильно много работы, потому что я давно ориентировался на поддержку такого режима и оставлял возможности включения. В принципе готов за означенную сумму в течении пары недель сделать что бы векторные kml тайлы поддерживали оформление на том же уровне что и импортированные из kml метки, но вот гарантий скорости подгрузки и отображения таких тайлов дать не могу - нужно пробовать и проверять.
ЗЫЖ Можете еще попробовать связаться с Zed <starmen@tut.by>, вдруг он согласится за меньшую сумму или быстрее, а то он на этот форум давно не заходит, а вообще в разработке продолжает участвовать заметно больше меня.

Деньги на счёт сайта я перевёл.

Belkin писал(а):Деньги на счёт сайта я перевёл.

Средства получены, можно начинать.

Начал. Как обычно, гладко было на бумаге, да забыли про овраги.

Как все понимают, эта функциональность не должна нарушить существующую работу с wikimapia, так как это пока единственный доступный работающий источник векторных данных. Сам пользуюсь. Просто внутрь ну очень давно не залазил. Я думал проблемы при использовании нормального парсера, по сравнению с тупым самописным, будут только со скоростью работы. И там действительно разница раз в 5. Но вот дальше выясняется, что викимапия отдает реально не полигоны, а мультигеометрию из точки и пути, которую правильный парсер разбирает вполне правильно.

Итого приходим к необходимости назначать разные парсеры разным zmp. Прямой связи там нет. Парсер задается через ContentType. А ContentType определяется по расширению заданному в zmp. Я давно хотел сделать, что бы в zmp задавалось не только расширение файлов, но и ContentType, имеющий больший приоритет, если указан.

Вот придется таки сделать. Совместимость это наше все, но ее поддержка это капец.

Это так. Кратенький отчет о том чем уже занимаюсь

C ContentType разобрались. Как следствие, теперь можно чуть проще делать отдельные парсеры для каждого zmp со своими заморочками. Теоретически можно допилить, что бы САС пересохранял Jpeg c меньшим качеством для экономии места или конвертировал png в формат c палитрой вместо 32 битного цвета.

Следующий шаг заставить парсер создавать параметры оформления при разборе kml для тайлового слоя. Там тоже есть свои нюансы.

А можете, на всякий случай, скинуть пару kml, которые вы хотите видеть с оформленим в виде векторного слоя? В идеале маленький кусочек скачанного кэша в формате файлового кэша САС?

Да, при первой же возможности, самое позднее — завтра днём. Сервис пока внутренний, но кэш создаётся исправно.