Форумы GIS-Lab.info

Здрасте всем.

Стоит задача по визуализации социологических данных. Геопространственные данные по субъекту в разрезе административных образований (городские поселения и муниципальные районы) в шейпах. Ориентировочно требуется визуализировать примерно 20 параметров дважды в год. Данные нужно презентовать на запароленном интернет-сервере (облачные решения даже с разграничением доступа не подходят).

Средствами R, используемой для обработки соц. данных, задача решается частично, поскольку:
1. Заказчику требуется интерактив (ретроспектива показателей во всплывающем окошке).
2. + Средства навигации между слоями.
3. + Потенциально может быть интересно подключение каких-либо атрибутивных данных из открытых источников.

Смотрел в сторону коммерческих отечественных решений. Если с бюджетом можно поднапрячься, то с остальным мириться не хочется. Напрягает неоптимальность алгоритма работы. Сначала нужно на десктопе сливать пространственные и атрибутивные данные, вручную выпекать шейп, а потом прикручивать его к веб-серверу. С каждым показателем требуется совершать кучу типовых рутинных действий.

Чего хочется:
1. Хочется решений, максимально задействующих потенциал R, то есть выполнять по максимуму операции в одной среде, не прибегая к помощи дополнительного десктопного приложения.
2. Хочется на выходе выразительных возможностей уровня MapBox.

ABOCb писал(а):Напрягает неоптимальность алгоритма работы. Сначала нужно на десктопе сливать пространственные и атрибутивные данные, вручную выпекать шейп, а потом прикручивать его к веб-серверу. С каждым показателем требуется совершать кучу типовых рутинных действий.

а зачем вы так неоптимально работаете? Не умеете "сливать пространственные и атрибутивные данные, и выпекать шейп" в среде R? наймите какого-нибудь пионэра, который умеет - задачка как раз для студента.

gamm писал(а):

ABOCb писал(а):Напрягает неоптимальность алгоритма работы. Сначала нужно на десктопе сливать пространственные и атрибутивные данные, вручную выпекать шейп, а потом прикручивать его к веб-серверу. С каждым показателем требуется совершать кучу типовых рутинных действий.

а зачем вы так неоптимально работаете? Не умеете "сливать пространственные и атрибутивные данные, и выпекать шейп" в среде R? наймите какого-нибудь пионэра, который умеет - задачка как раз для студента.

"Смержить" данные мы сможем без студентов. Непонятно как экспортировать легенду закраски полигонов, которая зависит от размерности данных. Используемые шейпы перепилены, границы городских поселений заменены центроидами, так как изначальные границы поселений слишком мелкие в сравнении с масштабом муниципальных районов. Поэтому и на этапе переноса в веб (не определились - куда именно) могут быть проблемы.

упрощенно, вы хотите готовить данные в R и без промежуточного приложения загружать их в web приложение, в котором автоматом всё красиво нарисуется? А в каком виде вы выгружаете данные из R?

andreygeo писал(а):упрощенно, вы хотите готовить данные в R и без промежуточного приложения загружать их в web приложение, в котором автоматом всё красиво нарисуется? А в каком виде вы выгружаете данные из R?

Ну про "автомат" я ничего не говорил. Мне просто цепочка - экспорт распределений с R, подготовка шейпа на десктопе, загрузка/допиливание в Веб-портале (и так сделай 20 раз) кажется неоптимальной. (В этом случае данные из R выгружаются в csv). Предпочёл бы все процедуры до загрузки делать в одной среде. Поскольку социологические данные в R, значит - это R, раз позволяют функциональные возможности среды (а они позволяют).
Раскрасить карту по шейпу "в цвета" какого-то показателя я умею. Я не умею "пакетно" подготовить данные по 20 распределениям, передать их в каком-то оптимальном формате (каком?) и загрузить на гео-портал (какой?). Неосторожно предполагаю, что задача, если не типовая, то точно уже имеет решение.

ABOCb писал(а):Мне просто цепочка - экспорт распределений с R, подготовка шейпа на десктопе, загрузка/допиливание в Веб-портале (и так сделай 20 раз) кажется неоптимальной.

не могли бы вы прояснить - то, что вы описываете, это то, как вы сейчас работаете (и если да, то куда вы это грузите, и что мешает вам обойтись без десктопа и допиливания). А если это ваши предположения, то почему вы решили, что нужно действовать именно таким образом? Дело в том, что R - это обычный язык программирования, на котором можно создавать те же шейпы, файлы стилей для отображения, и т.д., вплоть до создания иерархии растровых тайлов, готовых для отображения сервером. Достаточно один раз настроить серверную часть, и подменять картинки.

gamm писал(а):

ABOCb писал(а):Мне просто цепочка - экспорт распределений с R, подготовка шейпа на десктопе, загрузка/допиливание в Веб-портале (и так сделай 20 раз) кажется неоптимальной.

не могли бы вы прояснить - то, что вы описываете, это то, как вы сейчас работаете (и если да, то куда вы это грузите, и что мешает вам обойтись без десктопа и допиливания). А если это ваши предположения, то почему вы решили, что нужно действовать именно таким образом? Дело в том, что R - это обычный язык программирования, на котором можно создавать те же шейпы, файлы стилей для отображения, и т.д., вплоть до создания иерархии растровых тайлов, готовых для отображения сервером. Достаточно один раз настроить серверную часть, и подменять картинки.

Нет. Выгружать в ГИС задача встала недавно. При обращении к одной известной отечественной фирме и был предложен такой алгоритм работы, который меня не очень устроил.

А зачем вам шейпы? Храните (деньги) данные в (сберегательной кассе) PostGIS!

ABOCb писал(а):При обращении к одной известной отечественной фирме

это сферический конь в вакууме.

и был предложен такой алгоритм работы, который меня не очень устроил.

Скорее всего, вам (по вашей же посьбе) просто нарисовали абсолютно бесплатную схему, позволяющую обойтись даже без пионэра

если вы сможете сформулировать внятное ТЗ (пока у вас то полигоны, то точки - непонятно даже, что и как вы собрались визуализировать), то вам смогут предложить решение. Вариантов много, тот же Геомиксер или QGIS.

trir писал(а):А зачем вам шейпы? Храните (деньги) данные в (сберегательной кассе) PostGIS!

В шейпах просто исходные геоданные. Собственно нас интересует только один субъект с постоянными границами. Я просто не знаю - насколько целесообразно развёртывать PostGIS для этой задачи.

gamm писал(а):

ABOCb писал(а):При обращении к одной известной отечественной фирме

это сферический конь в вакууме.

и был предложен такой алгоритм работы, который меня не очень устроил.

Скорее всего, вам (по вашей же посьбе) просто нарисовали абсолютно бесплатную схему, позволяющую обойтись даже без пионэра
если вы сможете сформулировать внятное ТЗ (пока у вас то полигоны, то точки - непонятно даже, что и как вы собрались визуализировать), то вам смогут предложить решение. Вариантов много, тот же Геомиксер или QGIS.

Не совсем так. ТЗ не было, а было заполнение брифа, собеседование, веб-презентация и тестовый доступ. Допиливание под доп.требования обозначено как возможное, но трудоёмкое и не очень желательное. "Сферического коня" называть не хочу, поскольку может я просто не разобрался. Поэтому и обратился к сообществу, чтобы профи помогли мне разобраться с моими желаниями и направлением "рытья".

SpatiaLite

trir писал(а):SpatiaLite

Нравится что легковесное и без наворотов. Но нам серверное поделие нужно, а это вроде как "не использует клиент-серверную архитектуру"? Кроме того предполагается, что на выходе тематические карты будут юзать люди, ещё в меньшей степени обременённые опытом использования ГИС-ов, чем я.

ПБД

• Все продукты, удовлетворяющие спецификациям OGC (открытых ГИС) [1]
  Открытое программное обеспечение и интерфейсы прикладного программирования (API) для пространственных БД, некоторые из которых соответствуют спецификациям OGC [2]
  Boeing’s Spatial Query Server (Official Site), превращающий Sybase ASE в систему управления пространственными базами данных (СУПБД).
  Oracle Spatial
  Microsoft SQL Server поддерживает пространственные типы данных с версии 2008.
  PostgreSQL использует пространственное расширение PostGIS для реализации стандартизованного типа данных geometry и соответствующих функций
  MySQL поддерживает тип данных geometry и некоторые пространственные функции, которые не были реализованы в соответствии со спецификациями OGC. Функции, которые анализируют пространственные отношения объектов ограничены работой с описанным вокруг объекта прямоугольником, нежели с реальной геометрической информацией. Версии MySQL младше 5.0.16 поддерживают пространственные данные только в таблицах MyISAM, старше — дополнительно в таблицах InnoDB, NDB, BDB и ARCHIVE.
  Spatial Databox [3] быстродействующий механизм анализа пространственных данных с функциями поиска ближайших соседей, решением задач «содержится в»/«содержит» и пространственными выборками на основе мозаичных блоков.
  SAP HANA Spatial

ABOCb писал(а):Нравится что легковесное и без наворотов. Но нам серверное поделие нужно, а это вроде как "не использует клиент-серверную архитектуру"?

не покидает чувство, что вам никакие ГИС и веб-серверы не нужны. Хватит HTML странички на сервере с жыпегами, у которых есть активные области. Все, что нужно - жыпеги подменять, начальникам чисто картинка нужна. Таблички можно выкатывать при кликаньи в активные зоны, данные брать из файлов (их тоже подменять). Причем таблички выкатывать можно тоже в виде жыпегов, начальники все равно копипастят ручкой. Полная лепота - ничего в html не меняем, только жыпеги новые подсовываем

создается все это на бесплатном хостинге с фтп доступом, и жыпеги заливаются прямо из среды R, автоматом. Дешево и сердито (только небольшие расходы на пионэра для создания странички).