OSGeo Planet

Fernando Quadro: Big Data Spatial com GeoMesa

OSGeo Planet - Wed, 2018-10-24 10:30

Ao usar ferramentas de software livre para criar aplicativos GIS em um servidor como o GeoServer, você pode ler dados de arquivos e, ao usar mais dados do que arquivos podem armazenar com eficiência, pode ler de um gerenciador de banco de dados como PostgreSQL com PostGIS adicionado para fornecer suporte geoespacial. Se você tiver ainda mais dados, no entanto, você acabará atingindo um limite com o PostGIS. A máquina onde você a instalou pode ter muita memória RAM e espaço em disco, mas escalar a partir daí pode ficar caro se for possível.

À medida que mais tipos de dados se tornam disponíveis para sistemas GIS, está se tornando mais fácil atingir esses limites. O artigo do GIS Lounge “Empowering GIS com Big Data” descreveu algumas das classes de Big Data Spatial que estão levando as pessoas a ultrapassar esses limites e algumas das ferramentas que estão usando para trabalhar com esses dados. Uma ferramenta relativamente nova é o GeoMesa (open source), que adiciona suporte a recursos geográficos aos sistemas de banco de dados baseados no Hadoop Apache Accumulo, Apache HBase e Google Cloud Bigtable. Isso pode permitir que você dimensione o seu uso de dados GIS com sistemas de código aberto.

GeoMesa pode ajudar os usuários a gerenciar grandes conjuntos de dados espaço-temporais, armazenando petabytes de dados GIS e servindo dezenas de milhões de pontos em segundos.

1. Sistemas de banco de dados de Big Data

Primeiro, o que é o Hadoop, o que esses sistemas de banco de dados adicionam a ele e como eles diferem de um banco de dados relacional, como o PostgreSQL? E o mais importante, o que torna essa configuração tão boa para os Big Data Spatial?

O Apache Hadoop é uma estrutura de software livre que originalmente se tornou popular para manipular Big Data devido a dois componentes específicos dessa estrutura: o Hadoop Distributed File System (HDFS), que permite tratar os dados em uma coleção de máquinas comuns como um único sistema de arquivos e o MapReduce, que permite que os aplicativos dividam seu processamento em várias máquinas.

Com essa combinação, um aplicativo com requisitos de recursos crescentes não precisava necessariamente de um computador maior com mais RAM e espaço em disco para aumentar a escala; o crescimento poderia ser tratado pela adição de novas máquinas de baixo custo ao cluster do Hadoop. E, como os recursos baseados em nuvem se tornaram mais fáceis de usar e menos caros, você nem precisa de máquinas físicas permanentes para seu cluster – se você quisesse que doze máquinas funcionassem como um cluster para um trabalho de seis horas, você só precisa ter sua própria “nuvem” dessas máquinas por esse período de tempo.

Isso não funciona com todos os aplicativos, no entanto.

O MapReduce exige que você crie um procedimento Map e um procedimento Reduce para fazer o seu processamento. O procedimento Map é executado em cada nó do cluster, processando o subconjunto de dados transmitidos para esse nó e o procedimento Reduce reúne os resultados das execuções do Map e executa cálculos adicionais para agregar ou resumir os resultados. Esse arranjo funcionou bem para muitos tipos de análises, e as empresas despejaram terabytes de dados em rotinas MapReduce para que pudessem procurar padrões ocultos em seus dados de transações, cliques e registros. No entanto, para aplicativos de banco de dados típicos, a necessidade de dividir o processamento em operações de Map e Reduce dificultava a capacidade de permitir o tipo de consulta interativa e atualização de dados que a maioria das pessoas deseja fazer com seus bancos de dados.

À medida que o Hadoop ganhou força, um desenvolvimento paralelo no mundo da tecnologia da informação foi o desenvolvimento de sistemas de bancos de dados NoSQL. O termo originalmente significava “Não SQL” para descrever sistemas de bancos de dados que usavam alternativas aos modelos de dados baseados em tabela usados ​​com o padrão ISO SQL. O termo evoluiu para significar “Não apenas SQL”, pois aplicações grandes e modernas podem envolver uma coleção de sistemas de banco de dados que usam um modelo de dados diferente para executar uma tarefa especializada, e um sistema SQL – por exemplo, PostgreSQL – pode fazer parte dessa mistura.

Alguns desses sistemas de gerenciamento de bancos de dados NoSQL foram projetados para serem executados em um ambiente Hadoop, onde eles poderiam tirar vantagem do HDFS e proteger os desenvolvedores da necessidade de se preocupar com o Mapeamento e a Redução de seus dados. Uma família particular de bancos de dados NoSQL inspirada no documento Google Big Table sobre como eles armazenam e organizam seus dados é conhecida como “bancos de dados orientados por coluna”. Agrupando os dados de cada tabela por suas colunas em vez de usar a orientação de linha de bancos de dados SQL típicos, esses sistemas de banco de dados adicionaram flexibilidade de modelagem, eficiência de indexação e maior facilidade na distribuição de dados em vários nós.

Três sistemas populares de banco de dados orientados a colunas que podem ser executados no Hadoop são os projetos HBase e Accumulo e o Google Cloud Bigtable, a versão comercialmente disponível do Google do sistema interno de gerenciamento de dados. O conjunto de ferramentas GeoMesa para armazenar, indexar e consultar grandes dados espaciais pode trabalhar com todos esses três sistemas de banco de dados, permitindo que você realize análises geoespaciais em uma escala muito grande. Uma aplicação como o GeoServer pode então usar um repositório de dados GeoMesa como se usasse qualquer outro armazenamento de dados através de sua interface gráfica de usuário baseada na web, através do CQL, ou usando os padrões WFS , WMS , WPS e WCS. Ver essas habilidades adicionadas ao Cloud Bigtable impressionou o Google o suficiente para que eles recomendem o uso do GeoMesa, como um parceiro de serviço.

2. Dados geoespaciais armazenados, streaming de dados geoespaciais

Além de sua capacidade de trabalhar com petabytes de dados geoespaciais armazenados, o GeoMesa pode trabalhar com dados de streaming. Frequentemente, os consumidores de dados de alta velocidade (registros de 10K por segundo ou mais) implementam uma infraestrutura baseada na Arquitetura Lambda. A Arquitetura Lambda tem uma “Camada de Velocidade” para suportar telas interativas e análises quase em tempo real. Os dados armazenados pelo GeoMesa no Accumulo ou HBase fazem parte da camada de serviço que responde às consultas. O GeoMesa também inclui um datastore de streaming baseado no Apache Kafka, que é ideal para suportar reprodução recente em uma visualização de mapeamento. Por exemplo, se o seu sistema estiver lendo dados de posição sobre uma frota de veículos e você quiser renderizar e animá-los em uma camada de mapa, o armazenamento de dados Kafka do GeoMesa pode tornar isso possível. O GeoMesa também pode usar o Kafka para armazenar em cache dados suficientes para permitir que você “retroceda” animações do movimento da sua frota em torno do mapa. Um registro permanente desses dados pode ser fornecido na camada de veiculação para análise forense ou processamento em lote no futuro.

O GeoMesa também pode aproveitar o Apache Spark, uma estrutura de computação que está substituindo cada vez mais o uso direto do MapReduce para processar muito mais rapidamente os clusters do Hadoop. As bibliotecas do Spark para Machile Learning, Streaming e processamento de gráficos também permitem que os desenvolvedores criem e executem aplicativos analíticos mais rapidamente, o que abre algumas grandes possibilidades ao trabalhar com dados espaço-temporais.

A recente versão 1.2 do GeoMesa incluiu uma nova etapa: uma revisão completa pela LocationTech Working Group da Eclipse Foundation. Essa análise garantiu que o código-fonte do GeoMesa e todas as suas dependências estejam em conformidade com as licenças de software amigáveis ​​e sejam compatíveis com a licença Apache v2. Essa revisão completa da propriedade intelectual proporciona às empresas o uso da garantia de software de que podem usá-la com confiança e construir soluções baseadas no GeoMesa.

3. Quem está usando o GeoMesa

Várias forças armadas, agências de inteligência e empresas comerciais dos EUA já estão se beneficiando da capacidade do GeoMesa de ampliar seus Big Data Spatial. Para começar você mesmo, a página inicial da GeoMesa inclui tutoriais, e o YouTube tem vários vídeos que demonstram os recursos da GeoMesa e descrevem sua arquitetura. Para participar das conversas e obter suporte em seu próprio uso do GeoMesa, existem listas de discussão de usuários e desenvolvedores. E, como um projeto de código aberto, você pode entrar e contribuir com a CCRi, LocationTech e dezenas de outros colaboradores.

Fonte: GIS Lounge

Categories: OSGeo Planet

Fernando Quadro: Onde está seu vizinho mais próximo?

OSGeo Planet - Tue, 2018-10-23 10:30

Muitas das aplicações nos dias de hoje querem que saibamos o quão perto estamos das coisas:

  • Quais são os três cafés mais próximos da minha localização atual?
  • Qual é o aeroporto mais próximo do escritório?
  • Quais são as duas paradas de metro mais próximas do restaurante?

Outra maneira de fazer essas perguntas é dizer “Quem são meus vizinhos mais próximos a mim?”.

Isso mapeia um problema algorítmico clássico: encontrar com eficiência os vizinhos K mais próximos (ou K-NN), onde K é uma constante. Por exemplo, a primeira questão seria um problema de 3-NN, já que estamos tentando encontrar os 3 cafés mais próximos.

(Se você estiver interessado em aprender mais sobre os problemas do K-NN em geral, eu recomendo fortemente você tentar resolver isso usando Diagrama de Voronoi, uma maravilhosa estrutura de dados desenvolvida no campo da geometria computacional.)

Como podemos usar o PostgreSQL para nos ajudar a encontrar rapidamente nossos vizinhos mais próximos?

1. Construindo uma consulta

Em um artigo anterior foi utilizado um conjunto de dados das pessoas que visitaram cafeterias localizadas na área da cidade de Nova York. A nossa tabela se parece com isso:

CREATE TABLE visits ( id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, visitor UUID NOT NULL, visited_at timestamptz NOT NULL, geocode point NOT NULL );

Digamos que queremos descobrir os três amigos que estavam mais próximos da nossa localização em uma determinada data e hora. Para construir essa consulta, precisamos saber:

  • O intervalo de data e hora da consulta
  • A distância entre a nossa localização e a dos nossos amigos

O PostgreSQL define um operador de distância para tipos geométricos que se parecem com este “<->” que, no caso de pontos, calcula a distância euclidiana bidimensional. Por exemplo:

SELECT POINT(0,0) <-> POINT(1,1); ?column? ----------------- 1.4142135623731

Por uma questão de integralidade, quanto menor o número, mais próximos os dois pontos são um do outro, o que é importante para a próxima etapa do processo.

Se quisermos encontrar os três amigos mais próximos de nós em 1º de outubro de 2012, entre as 7h e as 9h, podemos criar uma consulta como esta:

SELECT visitor, visited_at, geocode FROM visits WHERE visited_at BETWEEN '2012-10-01 07:00' AND '2012-10-01 09:00' ORDER BY POINT(40.7127263,-74.0066592) <-> geocode LIMIT 3;

A parte “K-vizinho mais próximo” da consulta pode ser vista em ORDER BY POINT (40.7127263, -74.0066592) <-> geocode LIMIT 3, que está dizendo “encontre pela menor distância entre a minha localização atual e todas as outras gravadas locais, mas encontre os 3 locais mais próximos a mim.”

Como isso funciona?

EXPLAIN ANALYZE SELECT visitor, visited_at, geocode FROM visits WHERE visited_at BETWEEN '2012-10-01 07:00' AND '2012-10-01 09:00' ORDER BY POINT(40.7127263,-74.0066592) <-> geocode LIMIT 3; Limit (cost=53755.18..53755.54 rows=3 width=48) (actual time=120.890..128.781 rows=3 loops=1) -> Gather Merge (cost=53755.18..53794.45 rows=328 width=48) (actual time=120.889..128.778 rows=3 loops=1) Workers Planned: 4 Workers Launched: 4 -> Sort (cost=52755.12..52755.32 rows=82 width=48) (actual time=115.623..115.625 rows=2 loops=5) Sort Key: (('(40.7127263,-74.0066592)'::point <-> geocode)) Sort Method: top-N heapsort Memory: 25kB Worker 0: Sort Method: top-N heapsort Memory: 25kB Worker 1: Sort Method: top-N heapsort Memory: 25kB Worker 2: Sort Method: top-N heapsort Memory: 25kB Worker 3: Sort Method: quicksort Memory: 25kB -> Parallel Seq Scan on visits (cost=0.00..52754.06 rows=82 width=48) (actual time=65.256..115.476 rows=50 loops=5) Filter: ((visited_at >= '2012-10-01 07:00:00-04'::timestamp with time zone) AND (visited_at <= '2012-10-01 09:00:00-04'::timestamp with time zone)) Rows Removed by Filter: 805600 Planning Time: 0.112 ms Execution Time: 128.808 ms

Observando esse plano de consulta, o PostgreSQL determinou que nenhum dos índices poderia ser usado, e faz uma varredura sequencial completa (paralelizada) na tabela de visitas para encontrar as 3 pessoas mais próximas. Isso não é muito eficiente, mas poderíamos fazer melhor.

2. KNN-GiST: Encontre vizinhos eficientemente

O PostgreSQL 9.1 introduziu o índice KNN-GiST como uma maneira de acelerar a busca de vizinhos. Ele foi implementado em vários tipos de dados, incluindo pontos e trigramas, e também é aproveitado pela extensão espacial PostGIS.

Você pode usar um índice KNN-GiST simplesmente criando um índice GiST em um tipo de dados suportado, que, nesse caso, é a coluna geocode:

CREATE INDEX visits_geocode_gist_idx ON visits USING gist(geocode); VACUUM ANALYZE visits;

Para demonstrar seu poder, vamos ver o que acontece se tentarmos encontrar os 3 pontos mais próximos de um determinado local:

EXPLAIN ANALYZE SELECT visitor, visited_at, geocode FROM visits ORDER BY POINT(40.7127263,-74.0066592) <-> geocode LIMIT 3; Limit (cost=0.41..0.73 rows=3 width=48) (actual time=0.237..0.244 rows=3 loops=1) -> Index Scan using visits_geocode_gist_idx on visits (cost=0.41..423200.97 rows=4028228 width=48) (actual time=0.236..0.242 rows=3 loops=1) Order By: (geocode <-> '(40.7127263,-74.0066592)'::point) Planning Time: 0.089 ms Execution Time: 0.265 ms

Impressionante! Já podemos ver que o índice KNN-GiST em nosso tipo de ponto nos permite encontrar coisas que estão perto de nós incrivelmente rápido! Agora, vamos tentar executar nossa consulta original para descobrir quem está mais próximo de nós em 1º de outubro de 2012, entre as 7h e as 9h e ver se esse índice acelera:

EXPLAIN ANALYZE SELECT visitor, visited_at, geocode FROM visits WHERE visited_at BETWEEN '2012-10-01 07:00' AND '2012-10-01 09:00' ORDER BY POINT(40.7127263,-74.0066592) <-> geocode LIMIT 3; Limit (cost=0.41..4012.19 rows=3 width=48) (actual time=184.327..184.332 rows=3 loops=1) -> Index Scan using visits_geocode_gist_idx on visits (cost=0.41..433272.35 rows=324 width=48) (actual time=184.326..184.330 rows=3 loops=1) Order By: (geocode <-> '(40.7127263,-74.0066592)'::point) Filter: ((visited_at >= '2012-10-01 07:00:00-04'::timestamp with time zone) AND (visited_at <= '2012-10-01 09:00:00-04'::timestamp with time zone)) Rows Removed by Filter: 499207 Planning Time: 0.140 ms Execution Time: 184.361 ms

Sem sorte! Neste caso, porque também precisamos filtrar nossos dados para o intervalo de data e hora determinado, senão o PostgreSQL não pode tirar proveito do índice KNN-GiST.

3. Usando o índice btree_gist

Uma solução possível é criar um índice de várias colunas (visited_at, geocode), mas para fazer isso, precisamos configurar a extensão "btree_gist". Em suma, a extensão btree_gist permite que você use os operadores de qualidade padrão da árvore B com um índice GiST. Você pode instalar essa extensão executando o seguinte:

CREATE EXTENSION btree_gist;

Antes de tentarmos criar o índice de várias colunas, primeiro precisamos "dropar" o índice anterior:

DROP INDEX visits_geocode_gist_idx;

Agora, vamos criar o índice de várias colunas em (visited_at, geocode):

CREATE INDEX visits_visited_at_geocode_gist_idx ON visits USING gist(visited_at, geocode); VACUUM ANALYZE visits;

O que acontece com o tempo de execução?

EXPLAIN ANALYZE SELECT visitor, visited_at, geocode FROM visits WHERE visited_at BETWEEN '2012-10-01 07:00' AND '2012-10-01 09:00' ORDER BY POINT(40.7127263,-74.0066592) <-> geocode LIMIT 3; Limit (cost=0.41..12.64 rows=3 width=48) (actual time=0.047..0.049 rows=3 loops=1) -> Index Scan using visits_visited_at_geocode_gist_idx on visits (cost=0.41..1348.69 rows=331 width=48) (actual time=0.046..0.048 rows=3 loops=1) Index Cond: ((visited_at >= '2012-10-01 07:00:00-04'::timestamp with time zone) AND (visited_at <= '2012-10-01 09:00:00-04'::timestamp with time zone)) Order By: (geocode <-> '(40.7127263,-74.0066592)'::point) Planning Time: 0.133 ms Execution Time: 0.068 ms

Excelente! Parece que agora estamos aproveitando o índice KNN-GiST.

Uma pergunta que você pode ter: por que não apenas usar um índice B-tree na coluna visited_at? Essa solução pode funcionar se você souber que eliminará a maioria das linhas antes da execução. No entanto, se você começar a examinar uma faixa de data e hora maior ou se houver "muitas" linhas direcionalmente dentro da faixa de data e hora, verá um aumento significativo de desempenho usando este índice KNN-GiST de várias colunas.

4. Conclusão

Uma das coisas maravilhosas do PostgreSQL é que ele está repleto de "ferramentas ocultas" que podem ajudar significativamente na aceleração de suas cargas de trabalho. Quando usado apropriadamente, o índice KNN-GiST pode acelerar significativamente suas consultas onde você precisa encontrar coisas próximas, o que é uma necessidade comum de aplicativos. Eles não têm custo: os índices KNN-GiST são maiores do que os índices GiST regulares, mas os índices KNN-GiST de fornecem aceleração significativamente maiores que o espaço adicional e devem estar em sua caixa de ferramentas para qualquer aplicação que você constrói.

Este post foi traduzido e adaptado livremente do post originalmente escrito por Jonathan S. Katz, no Blog Crunchy Data.

Fonte: Blog Crunchy Data

Categories: OSGeo Planet

OTB Team: OTB Users Day 2018 – Recap

OSGeo Planet - Tue, 2018-10-23 09:39
The OTB team is proud to have hosted the fourth edition of OTB User Days! Thank you to everyone who attended, what a successful workshop! This yearly in-person meeting of the OTB community is open to everyone. This year we were hosted by Agropolis in Montepellier, France. About 70 people attended from many different countries! […]
Categories: OSGeo Planet

GRASS GIS: GRASS GIS 7.4.2 released

OSGeo Planet - Mon, 2018-10-22 20:38
We are pleased to announce the GRASS GIS 7.4.2 release
Categories: OSGeo Planet

Fernando Quadro: Análise de performance de Big Data com PostGIS e ArcGIS

OSGeo Planet - Mon, 2018-10-22 10:30

Esta semana estava lendo o feed do meu twitter quando me deparei com o titulo “Big Data Results“, e resolvi entrar para espiar do que se tratava! Era um post que fazia uma análise com dados de Nova Iorque (táxis) comparando a performance entre o ArcGIS e o PostGIS. Eu achei muito interessante, e resolvi traduzir, adaptar e transcrevo abaixo.

O exemplo utilizado tem um arquivo de 6GB com 16 milhões de pontos de táxi e 263 zonas. O objetivo era determinar o número de táxis em cada zona, juntamente com a soma de todas as tarifas. Abaixo segue a análise aprofundada do que foi realizado:

1. Os dados e o computador

Os dados foram obtidos da Comissão de Táxis e Limousines de Nova York para outubro de 2012. Os aproximadamente 16 milhões de pontos de táxi e 263 polígonos de zona de táxi exigiram cerca de 6 GB de armazenamento. Você pode ver abaixo que é realmente um grande volume de dados:

O computador utilizado tem um processador i7 (4 núcleos), Windows 10, unidade SSD, 12 GB de RAM e um processador de 3.0 GHz.

2. O Problema

A pergunta tinha que ser respondida era: Quantos táxis estavam para cada zona e qual era o valor total da corrida? Então, para tentar responder a essa pergunta foi utilizado o ArcGIS, e Postgres/PostGIS. Vamos então as análises:

3. ArcGIS 10.4

Como deve ser de conhecimento da maioria de vocês, o ArcGIS 10.4 é um aplicativo de 32 bits. Então, para tentar resolver esse problema foi executada uma junção de tabela (AddJoin_Management) entre os pontos de táxi e as zonas de táxi. Para dar ao ArcGIS uma chance de lutar, foram movidos os dados para um geodatabase (assim, as camadas teriam índices espaciais). Depois de executar a junção por algumas horas, o ArcGIS 10.4 relatou um erro de falta de memória.

4. ArcGIS Pro

Em seguida, o teste foi realizado com o ArcGIS Pro, que é um verdadeiro aplicativo de 64 bits. Além disso, o ArcGIS Pro possui várias ferramentas para fazer exatamente o que era necessário. Um deles foi o Summarize Within. A ESRI torna realmente fácil fazer esse tipo de pergunta no ArcGIS Pro. Então a função foi executada, e foi obtida uma tabela resultante em 1h 27m. Neste ponto do experimento, foi bastante satisfeito – pelo menos, houve uma resposta, e é algo que se pode fazer durante um intervalo para o almoço, por exemplo.

5. ArcGIS Server com GeoAnalytics Server

A ESRI estava divulgando seu novo GeoAnalytics Server (o preço é de US$ 40.000 para uma implementação de 4 núcleos), e foi realizado o teste com ele também. Para surpresa, ele executou a consulta em cerca de 2m, o que é realmente espantoso. Este produto é projetado para grandes volumes de dados com certeza.

6. Postgres/PostGIS

Para ver como isso funcionaria no Postgres com o PostGIS a primeira coisa a ser feita foi criar uma instrução SQL:

SELECT count(*) AS totrides,taxizones.zone, sum(taxisandy.fare_amount) FROM taxizones, taxisandy WHERE ST_Contains(taxizones."Geom",taxisandy.pu_geom) GROUP BY zone

Esta consulta foi executada em 10m 27s. Foi um resultado satisfatório, afinal, essa consulta é super simples de escrever. Mas ainda não é o fim pois existem algumas maneiras de otimizar essa consulta.

7. Postgres/PostGIS Otimizado

O índice espacial já havia sido criado, mas havia mais duas coisas que era necessário fazer: esvaziar a tabela e agrupar os dados. Então, o que essas consultas fazem:

VACUUM recupera o armazenamento ocupado por tuplas mortas. Na operação normal do PostgreSQL, as tuplas excluídas ou obsoletas por uma atualização não são fisicamente removidas de suas tabelas; eles permanecem presentes até que um VACUUM seja realizado.

O CLUSTER reordena fisicamente os dados no disco para que os dados que devem estar próximos um do outro no banco de dados estejam realmente próximos uns dos outros no disco. Em outras palavras, os pontos no Brooklyn agora estão fisicamente armazenados no disco perto de outros pontos no Brooklyn.

Então, como fazer isso? Primeiro, limpe e agrupe os dados:

VACUUM ANALYZE taxizones ("Geom"); VACUUM ANALYZE taxisandy (pu_geom); CLUSTER taxisandy USING pugeom_idx; CLUSTER taxizones USING "Geom_x";

Agora, executar o cluster nos pontos de táxi de fato levou 18 minutos. Essa é uma “despesa única” que pagamos. Depois disso, podemos executar qualquer consulta que quisermos, repetidamente. A consulta é um pouco mais complicada do que a anterior porque escreve os resultados em uma nova tabela:

SELECT taxizones."Geom", sumfare, a.zone INTO sumtable FROM taxizones, (SELECT taxizones.zone, sum(taxisandy.fare_amount) AS sumfare FROM taxizones JOIN taxisandy ON ST_Contains("Geom", pu_geom) GROUP BY zone) AS a WHERE taxizones.zone = a.zone

A consulta foi concluída em 1m 40s. Claro, com PostGIS você tem que levar em consideração o custo: $0.

Porém, ainda é possível otimizar mais essa consulta, pois algumas das zonas de táxi são um pouco grandes, então, a consulta de restrição pode demorar um pouco mais ao comparar as caixas delimitadoras (BBOX) no índice espacial. Para contornar isso, é possível utilizar a função ST_SubDivide para dividir as zonas de táxi maiores em polígonos menores:

Isso significava que os polígonos da minha zona de taxiamento passaram de 263 para 4.666. Agora, pensando racionalmente, quem faria uma sobreposição com 4.666 polígonos ao invés de 263, que é menor? Bem, foi o que foi feito aqui, e de 1m40s o resultado passou para 1m3s.

Mas como foram divididos os polígonos? Veja baixo:

SELECT ST_Subdivide("Geom", 50) AS geom, zone into taxisub FROM taxizones; CLUSTER taxisub USING geom_idx;

E sim, o CLUSTER mais uma vez fez uma grande diferença. O SQL desta vez, nos permite fazer algumas coisas inteligentes. Lembre-se, agora temos 4.666 polígonos porque os 263 polígonos foram subdivididos.

Na consulta abaixo, a parte interna (sub consulta) é o SQL para determinar o total de viagens e a soma das tarifas em cada polígono dos 4.666. Assim, a parte externa da consulta está unindo as zonas de táxis originais (aquele com apenas 263 polígonos) e escrevendo para uma tabela com o resultado final.

SELECT taxizones."Geom" AS geom, count(id) AS numrides, sumfare, a.zone INTO sumtable FROM taxizones, (SELECT taxisub.zone, sum(taxisandy.fare_amount) AS sumfare FROM taxisub JOIN taxisandy ON ST_Contains(geom, pu_geom) GROUP BY zone) AS a WHERE taxizones.zone = a.zone

8. Resultados:

Abaixo, a lista detalhada dos resultados obtidos nos experimentos descritos acima:



É impressionante a forma como algumas das abordagens mais recentes conseguiram melhorar o desempenho do decorrer dos anos.

9. Conclusão

Então, qual a conclusão que podemos tirar disso tudo? Bem, os produtos GIS estão evoluindo e agora estão posicionados para lidar com conjuntos de dados realmente grandes de maneiras que não podíamos fazer antes. Estou impressionado com cada um desses produtos.

Este post foi traduzido e adaptado livremente do post originalmente escrito por Arthur J. Lembo Jr, do blog GIS Advising.

Fonte: GIS Advising

Categories: OSGeo Planet

Antonio Santiago: Express API with autogenerated OpenAPI doc through Swagger

OSGeo Planet - Sat, 2018-10-20 20:31

In past years OpenAPI has arise as the preferred way to document APIs. In this article we will see how easy is document an API created with NodeJS and Express through the Swagger tools.

If you are working in an REST API you more probably will desire to have some API doc where your users could find what are the endpoints of your API, what they do, which parameters they accept and which output they generate.

Categories: OSGeo Planet

gvSIG Team: Ponencias presentadas en las Jornadas Ibéricas de Infraestructuras de Datos Espaciales 2018

OSGeo Planet - Fri, 2018-10-19 08:10

Esta semana hemos participado en las JIIDE 2018, un evento que sirve de encuentro de las principales iniciativas y organizaciones relacionadas con las Infraestructuras de Datos Espaciales, y donde (como no podía ser de otra forma) la Asociación gvSIG ha tenido una participación destacada con 3 ponencias y un taller.

Las sesiones han sido grabadas, por lo que pronto se podrá acceder a ellas, pero para los impacientes que quieran ver qué presentamos os dejamos con las tres presentaciones realizadas. Aplicación de la Suite gvSIG en tres ámbitos muy distintos: la gestión municipal, agricultura y el sector de emergencias y seguridad. Y más allá de nuestras propias ponencias me gustaría destacar que la gran mayoría de soluciones presentadas utilizan tecnologías libres. El software libre ha pasado de alternativa a realidad. Estándares, interoperabilidad, conocimiento abierto…el camino a seguir y construir está claro.

Infraestructuras de Datos Municipales con gvSIG Suite:

gvSIG Suite aplicada a seguridad, emergencias y protección civil:

gvSIG suite aplicado a proyectos de agricultura:

Categories: OSGeo Planet

GeoServer Team: GeoServer 2.13.3 released

OSGeo Planet - Thu, 2018-10-18 17:31

We are happy to announce the release of GeoServer 2.13.3. Downloads are available (zipwar, and exe) along with docs and extensions.

This is a maintenance release recommended for production use (for newer projects please use the 2.14.x series, as 2.13.x will cease to be supported in a few months).
This release is made in conjunction with GeoTools 19.3 and GeoWebCache 1.13.3.

Highlights of this release are featured below, for more information please see the release notes (2.13.32.13.2 | 2.13.1 | 2.13.02.13-RC1 | 2.13-beta).

Improvements and Fixes
  • Allow selection of geometry attribute in app-schema, support mapping files over HTTP connection, push spatial filters over nested geometries down into SQL when possible
  • Performance improvement when reporting dimension values in WMS capabilities, for dimensions out of raster data and presented as “interval and resolution”
  • WCS thread safety fixes when using requests with reprojection and rescaling under high load. Also, when requesting an area inside the bounds of a sparse mosaic, the result might have had less pixels than requested.
  • CSS translator fixed to support mark offset/anchors based on expressions
  • File chooser autocomplete had duplicate entries on Linux
  • REST config, it was not possible to set the default style using a layer PUT
  • GetLegendGraphic ignores the OnlineResource configured in the style for raster layers
About GeoServer 2.13 Series

Additional information on the 2.13 series:

 

Categories: OSGeo Planet

GeoTools Team: GeoTools 19.3 released

OSGeo Planet - Thu, 2018-10-18 17:18
The GeoTools team is pleased to announce the release of GeoTools 19.3: geotools-19.3-bin.zip geotools-19.2-doc.zip geotools-19.3-userguide.zip geotools-19.3-project.zip maven repository This release is the current stable release and as such users and downstream projects should consider moving from older releases to this one. This release is made in conjunction with GeoServer 2.13.3 and
Categories: OSGeo Planet

Fernando Quadro: Community Modules do GeoServer

OSGeo Planet - Thu, 2018-10-18 10:30

Nos últimos posts apresentei algumas extensões como PGRaster, ElasticSearch, Amazon S3 e monitoramento de status. Se você for na página de download do GeoServer, perceberá que esses plugins/extensões não estão listados lá!

Isso porque se você não tiver percebido, todas essas extensões estão armazenadas no que a equipe do GeoServer chama de “Community Modules” (módulos comunitários).

Os módulos comunitários são considerados “pendentes” porque não são oficialmente parte dos lançamentos do GeoServer. Eles são, no entanto, construídos juntamente com as compilações diárias (nightly builds), para que você possa baixar e trabalhar com eles.

Os módulos comunitários são geralmente considerados de natureza experimental e estão em constante desenvolvimento, e só vão para a página de downloads do GeoServer quando já passaram por muitos testes e são considerados estáveis. Um exemplo recente disso, é a extensão para o MongoDb, que estava nos módulos comunitários desde 2014 e este ano foi disponibilizado na página de download do GeoServer.

Para saber todos os módulo que estão disponíveis no ‘Community Module” você pode acessar o site da documentação do GeoServer ou acessar diretamente a página de download dos mesmos. Lembre-se sempre que for baixar, confira a versão do seu GeoServer e da extensão, para que sejam compatíveis (mesma versão).

Fonte: GeoServer Documentation

Categories: OSGeo Planet

GIScussions: Mappery

OSGeo Planet - Thu, 2018-10-18 09:00

In case you missed it, Ken Field and I have started a new little venture called Mappery

The idea started when we were on safari in Tanzania before FOSS4G 2018, hence the elephant logo. Our aim is to gather pictures of “maps in the wild“, who knows where this might go or what a map in the wild might be? If you have a picture of a map that you would like to send to us follow the instructions on the About page.

Inevitably there is a map of Maps in the Wild if that’s your thing

You can follow Mappery on twitter at @MapsintheWild

 

Categories: OSGeo Planet

From GIS to Remote Sensing: Available the French translation of SCP interface

OSGeo Planet - Wed, 2018-10-17 20:02

The interface and the user manual of SCP are developed in English (user manual available at this link). However, it is possible to translate the interface into any language.
I'm very glad to announce the availability of the French translation of the SCP interface.
The whole interface has been translated by Sebastien Peillet (geomatician and developer, currently at Maison de la Télédétection, UMR TETIS). Many thanks to Sebastien Peillet for his excellent work, which will be very helpful to many people.
The French translation is available in the latest update of SCP v. 6.2.5.

The SCP translated in French

Again, many thanks to Sebastien Peillet and to all the volunteers that have translated SCP and the user manual.
Other language translations are still incomplete. I invite you to help translating SCP into your language. It is possible to easily translate the user manual to any language, because it is written in reStructuredText as markup language (using Sphinx). Therefore, your contribution is fundamental for the translation of the manual to your language.
Read more »
Categories: OSGeo Planet

Fernando Quadro: Usando o Amazon S3 para armazenar o cache do GeoServer

OSGeo Planet - Wed, 2018-10-17 10:30

Se você já utiliza o GeoServer na nuvem, sabia que é possível armazenar os dados de cache gerados por ele também na nuvem?

O GWC S3 BlobStore é a extensão do GeoServer que suporta o uso do AWS Simple Storage Service (Amazon S3) como meio de armazenamento para as configurações do GeoWebCache. Veja abaixo, como utilizá-lo:

1. Instalando o plugin S3 BlobStore

1.1 Baixe a extensão do GeoServer. Certifique-se de verificar a versão da extensão com a versão da instância do seu GeoServer!

1.2 Extraia o conteúdo do arquivo para a pasta WEB-INF/lib da instalação do GeoServer.

2. Configurando o plugin S3 BlobStore

Uma vez que o plugin tenha sido instalado, um ou mais BlobStores S3 podem ser configurados através da opção BlobStores. Posteriormente, as camadas armazenadas em cache podem ser atribuídas explicitamente a ele ou um blobstore pode ser marcado como “padrão” para usá-lo em todas as camadas não atribuídas.

Agora já está tudo configurado, e seus dados de cache estão apontando para o AWS S3.

Fonte: GeoServer Documentation

Categories: OSGeo Planet

gvSIG Team: Retransmisión en directo de las 5as Jornadas gvSIG Uruguay

OSGeo Planet - Tue, 2018-10-16 13:17

Las sesiones de ponencias de las 5as Jornadas gvSIG Uruguay, que se celebrarán los días 18 y 19 de octubre en Montevideo (Uruguay), van a ser retransmitidas en directo a través de internet.

Las sesiones de ponencias tendrán lugar el jueves 18 de octubre, y la retransmisión se realizará a través del portal de Vera tv. El enlace directo a la retransmisión es el siguiente.

Podéis consultar toda la información sobre el programa en la web de las jornadas.

Si no podéis acudir a este evento podréis seguir todas las presentaciones en directo de forma online. Y si deseáis acudir, y no os habéis registrado, aún podéis hacerlo desde el mismo portal del evento. Hay aforo limitado. ¡No esperéis al final!

Categories: OSGeo Planet

Fernando Quadro: Curso de OpenLayers 4 – EAD

OSGeo Planet - Tue, 2018-10-16 10:30

Prezado leitor,

Você está querendo desenvolver um WebGIS e apresentar suas informações geográficas na Internet? Não sabe por onde começar, e qual ferramenta utilizar? Então esta é a sua oportunidade!

A GEOCURSOS acaba de lançar o Curso de OpenLayers 4 no formato EAD (videoaulas). Este curso oferece uma visão completa de como criar seu WebGIS utilizando umas das melhores APIs de mapas para front-end que é o OpenLayers.

O curso é voltado para profissionais da área de desenvolvimento de software, com experiência em lógica de programação e noções de SIG e JavaScript, que estejam em busca de aprender a criar aplicações que contenham dados geográficos na internet.

São 15 horas de aulas, todas gravadas e disponíveis no portal do aluno por 3 meses, assim como todo o material didático do curso (slides, apostilas, etc.). Além das videoaulas, o aluno pode esclarecer suas de dúvidas por e-mail diretamente com o instrutor.

Então não perca mais tempo e adquira nosso novo curso #EAD sobre #OpenLayers

Categories: OSGeo Planet

OSGeo-fr: Les rencontres QGIS utilisateurs arrivent !

OSGeo Planet - Tue, 2018-10-16 08:40

Cette année, pour la sixième édition consécutive, l'OSGEO-fr et la AgroTIC Services de SupAgro Montpellier s'associent pour organiser les rencontres utilisateurs QGIS

L’événement se déroulera sur 2 jours :

- Jeudi 13 décembre 2018 Journée de barcamp où l’objectif est que les utilisateurs échangent et travaillent en petits groupes sur des problématiques concrètes.
- Vendredi 14 décembre 2018 Journée de conférence sur le même format que les éditions précédentes.

Nous recherchons des soutiens ainsi que des témoignages pour cette édition dont le thème sera "QGIS - fédérons et structurons nos usages!".

Les formulaires pour proposer votre soutien et des sujets sont d'ores et déjà disponibles sur le site

http://conf.qgis.osgeo.fr

La communauté des utilisateurs ne cesse de grandir et d'attirer de nouveaux métiers. De très nombreuses applications métier sont désormais construites sur la base du couple QGIS et PostGIS: gestion de réseaux d'eau, d'assainissement, de gaz , cadastre, agriculture, gestion de d'aéroports etc..

A l’heure de la prise de conscience de l’importance des données souveraines et des communs, le moment est venu d’accompagner la mise en place de solutions communautaires également pour nos outils métiers.

Quelles sont les initiatives existantes ici et ailleurs qui permettent de construire des solutions communes ?

Quels sont les codes, les bonnes pratiques et les facteurs de réussite de tels projets?

Comment faire pour demain avoir des outils communs et maintenus permettant de se concentrer avant tout sur son propre métier?

Nous aurons le plaisir d’accueillir cette année le nouveau président du groupe QGIS utilisateur Suisse, Hans-Jörg Stark. Il viendra témoigner des actions et des financements impulsés par cette association depuis 2012, et qui constitue une des forces motrices les plus importantes du projet QGIS.

Nous vous invitons à proposer vos retours d’expériences, ou à venir présenter des initiatives que vous souhaiteriez ouvrir et maintenir collectivement.

Les parties techniques de la conférence feront le bilan technique des fonctionnalités de QGIS qui permettent ces développements rapides d’applications, les manques actuellement identifiés, et les groupes d’intérêt déjà à l’œuvre et en recherche d’appui ou de financement.

Les inscriptions ouvrent bientôt, tenez vous prêts!

Categories: OSGeo Planet

Blog 2 Engenheiros: Como converter vértices de polígonos em pontos usando Modelador Gráfico no QGIS?

OSGeo Planet - Tue, 2018-10-16 06:47

Mostramos na postagem anterior como utilizar o Model Builder do ArcGIS. Porém, nem todos utilizam esse software, por isso, iremos mostrar como criar um fluxo de trabalho similar utilizando o QGIS 2.18.

Para isso, utilizaremos a ferramenta Modelador Gráfico (Graphical Modeler), a qual encontra-se no menu Processar do QGIS.

Iremos iniciar nosso tutorial demonstrando como extrair os pontos dos vértices de um polígono (limite de uma unidade de conservação) e em seguida, mostraremos como realizar todo esse procedimento no modelador gráfico.

O que são Unidades de Conservação?

Quem define o que são Unidades de Conservação (UC) é a Lei Federal n. 9.985 do ano 2000, a qual estabelece que a UC é um:

Espaço territorial e seus recursos ambientais, incluindo as águas jurisdicionais, com características naturais relevantes, legalmente instituído pelo Poder Público, com objetivos de conservação e limites definidos, sob regime especial de administração, ao qual se aplicam garantias adequadas de proteção.

Além disso, a Lei 9.985/2000, de modo geral, institui o Sistema Nacional de Unidades de Conservação (SNUC), prevendo como as UC serão criadas, implantadas e geridas.

Dentro do SNUC, foram criadas 12 tipos de UC, de forma a garantir diferentes tratamentos (onde umas apresentam usos mais restritivos e outras que permitem usos mais sustentáveis).

Das 12 categorias de UC, 5 delas são Unidades de Proteção Integral, as quais são apresentadas abaixo:

  • Estação Ecológica;
  • Reserva Biológica;
  • Parque Nacional;
  • Monumento Natural;
  • Refúgio de Vida Silvestre.

E as outras 7 são denominadas Unidades de Uso Sustentável, sendo elas as seguintes:

  • Área de Proteção Ambiental;
  • Área de Relevante Interesse Ecológico;
  • Floresta Nacional;
  • Reserva Extrativista;
  • Reserva de Fauna;
  • Reserva de Desenvolvimento Sustentável;
  • Reserva Particular de Patrimônio Natural.

Você pode conferir as características de cada uma delas no Livro SNUC e Plano Estratégico Nacional de Áreas Protegidas do Ministério do Meio Ambiente, bem como a localização das várias UC no Brasil no site do ICMBio.

Extraindo vértices de um polígono

Agora que sabemos o que é uma Unidade de Conservação, iremos baixar o limite de uma delas e converter os seus vértices em um shapefile de ponto.

Neste tutorial, utilizaremos os limites do Parque Nacional Marinho de Abrolhos, localizado no município de Caravelas (Bahia), o qual pode ser baixado no formato KMZ clicando aqui.

No QGIS, arquivos no formato KMZ e KML são abertos da mesma forma que os shapefiles.

Após abrir o arquivo no formato KMZ, iremos converter ele para shapefile. Para isso, basta clicar com o botão direito sobre ele e selecionar salvar como (e em seguida, marcar como formato de saída ESRI Shapefile).

Se você salvar o shapefile com sistema de coordenadas UTM, lembre-se que a zona UTM para esta região da Bahia é 24S.

Utilizaremos o arquivo vetorial na ferramenta Extract Nodes, a qual esta disponível dentro do menu Processing: Toolbox. Na caixa de ferramentas, basta buscar em QGIS geoalgorithms: Vector geometry tools.

Você irá indicar o shapefile com o limite da UC e definirá onde será salvo o shapefile de pontos que representam os vértices.

Ferramenta Extract Nodes do QIGS para criar shapefile com vértices de um polígono.Ferramenta Extract Nodes do QIGS para criar shapefile com vértices de um polígono.

Ao clicar em Run, o algoritmo será executado e você obterá um shapefile com os pontos representando os vértices do Parque Nacional Marinho de Abrolhos.

Para obter as coordenadas de cada um dos pontos, iremos trabalhar dentro da Tabela de Atributos, especificamente com a Calculadora de Campo (“Field Calculator”).

Clique sobre o shapefile de pontos e selecione Tabela de Atributos e em seguida, clique no botão da Calculadora de Campo (o símbolo é um ábaco).

Iremos realizar esse procedimento duas vezes, uma para obter as longitudes e outra para as latitudes.

Dentro da Calculadora de Campo, selecione Criar um Novo Campo (1), defina um nome para este campo (2), e busque dentro do item Geometry por $x ou $y (dependendo se for para obter longitude ou latitude) e adicione ao campo de expressão (3).

Utilizando a calculadora de campo para obter as coordenadas de cada ponto.Utilizando a calculadora de campo para obter as coordenadas de cada ponto.

Agora, temos uma tabela de atributos com as coordenadas X e Y de cada ponto da UC. Vamos, então, exportá-los para um novo arquivo.

Exportando Tabela de Atributos

Para exportar os resultados para uma tabela externa, ou um arquivo de texto, basta você clicar sobre o shapefile contendo os pontos, selecionar salvar como e marcar para salvar como CSV.

Exportando atributos de um shapefile no formato CSV.Exportando atributos de um shapefile no formato CSV.

Lembre-se de marcar as colunas que você quer exportar para CSV.

Como usar o Modelador Gráfico?

O modelador gráfico é uma forma simples e rápida de criar modelos complexos, ou seja, fluxos de trabalho.

No QGIS, essa ferramenta esta disponível no menu Processar (ou utilizando o atalho Ctrl+Alt+M).

Ao abrir o Modelador Gráfico, você terá acesso aos parâmetros de entrada (1), algoritmos (2) e uma janela para desenhar o fluxo (3).

Janela Principal do Modelador Gráfico do QGIS.Janela Principal do Modelador Gráfico do QGIS.

Iremos adicionar como parâmetro de entrada um + Vector Layer (de forma a receber o KMZ com os limites da Unidade de Conservação), onde definiremos o nome do parâmetro de entrada, o tipo de shapefile (“Polygon”) e se o arquivo é necessário (“Required: Yes”).

Como as operações seguintes são realizadas com shapefiles, precisamos convertes esse arquivo de entrada para shapefile.

Dentro da aba Algorithms, busque por GDAL/OCR: [OGR] Conversion: Convert Format. Dê dois cliques sobre o item e selecione para converter para shapefile.

Em seguida, busque pela ferramenta QGIS geoalgorithms: Vector geometry tools: Extract Nodes. Após dar dois clique nela, marque para ela receber como entrada o arquivo kmz convertido para shapefile.

Agora, procure pela ferramenta QGIS geoalgorithms: Vector table tools: Export/Add geometry tools para adicionar à tabela de atributos as coordenadas de cada ponto. O arquivo de entrada desta ferramenta são os pontos gerados pelo Extract Nodes.

E por fim, vamos utilizar novamente a ferramenta Convert Format para converter o arquivo final para CSV, sendo que você já pode nomear o arquivo de saída dentro desta ferramenta.

O resultado, após inserir todas as ferramentas, é apresentado na figura abaixo.

Aparência do Modelador Gráfico após adicionar todas as ferramentas.Aparência do Modelador Gráfico após adicionar todas as ferramentas.

Após todo esse processo, clique nas engrenagens no topo da janela (“Run Model”) para executar o modelo.

O QGIS irá abrir uma nova janela solicitando o dado de entrada (no caso, o limite da UC) e onde o resultado será salvo (arquivo de saída). Agora é só executar para obter o mesmo resultado que tivemos rodando as ferramentas separadamente.

Lembrando que é possível salvar o seu modelo para ele ser executado em outros momentos.

Ficou com alguma dúvida ao longo desta postagem? Fique a vontade e utilize os comentários para respondermos você.

Categories: OSGeo Planet

Fernando Quadro: Usando a extensão PGRaster do GeoServer

OSGeo Planet - Mon, 2018-10-15 11:39

A extensão PGRaster adiciona a capacidade de simplificar a configuração de um armazenamento de um ImageMosaic baseado no PostGIS Raster. Antes de continuar, certifique-se de dar uma olhada na documentação do plug-in do PostGIS Raster para obter informações básicas. Observe que os arquivos de configuração, criações de tabela e importações de raster explicadas nessa documentação serão tratados automaticamente por este módulo, acreditando que você já tem conhecimento sobre esses assuntos.

Esta extensão permite fazer os seguintes passos automaticamente:

1. Use raster2pgsql (opcionalmente) para importar seu arquivo raster previamente configurados com gdal_retile
2. Crie uma tabela de metadados (opcional) referindo-se a tabelas de tiles criadas através do raster2pgsql
3. Crie a configuração XML ImageMosaic-JDBC contendo parâmetros de conexão com o banco de dados PostGIS, mapeamento de atributos e configuração do coverage.
4. Configure o ImageMosaic-JDBC na parte superior do XML recém-configurado.

Requisitos

  • Você deve ter um banco de dados do PostGIS 2.0 onde seus tiles raster serão armazenados.
  • Os mosaicos de rasterização devem ter sido criados anteriormente, gdal_retile pois este módulo simplesmente os importará e configurará a Store. A documentação do exemplo de configuração do ImageMosaic-JDBC fornece exemplos de como fazer isso.
  • Caso você queira realizar a importação automática dos mosaicos raster para o banco de dados, você precisa ter os executáveis ​​raster2pgsql e psql instalados em sua máquina e configurados no seu PATH. (Caso sua instalação do PostGIS 2.0 esteja na mesma máquina onde você executará o GeoServer, os executáveis ​​já devem estar disponíveis).

Instalação

1. Baixe a extensão pgraster do repositório Community para sua versão do GeoServer na página de download.
2. Descompacte o arquivo no diretório WEB-INF/lib da instalação do GeoServer. No Windows, certifique-se de adicionar:

RASTER2PGSQL_PATH=Drive:\Path\to\bin\folder\containing_raster2pgsqlExecutable

e ao JAVA_OPTS como uma instância:

JAVA_OPTS=-DRASTER2PGSQL_PATH=C:\work\programs\PostgreSQL\9.2\bin

3. Reinicie o GeoServer.

Uso

1. Quanto a qualquer outra configuração de Store, vá para Store -> Adicionar novo store

2. Selecione ImageMosaic-JDBC. Você verá o formulário usual “Adicionar fonte de dados rasterizados”.



Para compatibilidade com versões anteriores, você ainda pode configurar um ImageMosaic-JDBC antigo, especificando a URL de um arquivo de configuração XML válido, como feito no passado (onde todos os componentes do ImageMosaic-JDBC precisam ser configurados manualmente pelo usuário) .

3. Observe a presença de um checkBox que permite prosseguir com a especificação dos parâmetros de configuração automática do PGRaster. Uma vez clicando nele, você verá um conjunto de novos parâmetros para a etapa de configuração automática. Ao ativar essa caixa de seleção, o parâmetro de URL precisa apontar para a pasta principal que contém os arquivos rasters que foram produzidos anteriormente usando gdal_retile.


Outros parâmetros são explicados abaixo:

Limitações

No momento, ele não permite importar pastas de dados que foram criadas com a opção useDirForEachRow do gdal_retile .

Fonte: GeoServer Documentation

Categories: OSGeo Planet

Andrea Antonello: The Geopaparazzi family upgrades... new server and apps!

OSGeo Planet - Mon, 2018-10-15 09:12
In July we released the Geopaparazzi Survey Server and it has been such a great success for ourselves, that we started to miss several features in it and had to develop them.

While doing so we noticed that the Eclipse RAP platform didn't seem to be particularly flexible and supported so we tried a switch to Vaadin... and never looked back since. The whole app has been ported and important functionalities have been added, being the 2 main ones:

The form builderIt is ages now that users ask for a visual form builder. The gvSIG Association has built one for gvSIG that works nicely. But then it still needs to be loaded to the device. Since we started to have a server, we felt this should all be there and allow for easy connection and download.

I think this first version of the form builder is already looking great and very usable:






A more detailed documentation about it can be found in the manual.


The mobile companion app is now able to get the list of forms and install them into the geopaparazzi folder:


The project data downloadIn order to be able to get project data from the server, it is now possible to load datasets on the server:






These dataset are then available to the mobile app:



The project data are downloaded into a dedicated folder and the geopaparazzi user needs to load them manually. So this is not so sophisticated as it is done in the profiles server.

Export databaseWhile it is best to connect to the online database through the port 9092, which is exposed by the server, in some environments it might not be possible (ex. Heroku allows only one port). In this case it is possible to export the database by downloading it.



Send a logThe log sending has been enhanced to allow the user to add some comment that can help the developers to understand the issue:






Geopaparazzi 5.6.2 releasedA new version of geopaparazzi has been released with some bugfixes, enhancements and language updates. This version now allows the user to have multiple forms json files. geopaparazzi will load them all into the add notes view.













Categories: OSGeo Planet

Cameron Shorter: The Open Business - Business Case

OSGeo Planet - Fri, 2018-10-12 04:19

Abstract:Despite many attempts, large companies and governments’ rarely achieve the level of collaboration experienced by Open Source communities. Why?Looked at through the lens of traditional management, Open Source collaboration is time consuming, imprecise, unreliable, hard to manage, rarely addresses short term objectives, and hard to quantify in a business case. And yet, in a digital economy, collaborative communities regularly out-innovate and out-compete closed or centrally controlled initiatives.Backing successful collaboration within traditional business requires us to write compelling, counter-intuitive business cases which explain and justify the elusive practices of collaborative communities.This presentation explains the subtle magic of open strategies in business terms, and will help you convince your boss to back them.

Fifty years ago Garrett Hardin described the tragedy of the commons,where people acting in their own self-interest, inevitably will deplete or spoil a common resource, as each acts in their own self interest.He argued that the tragedy can only be prevented by private property rights or government regulation.And yet, within the last fifty years, we’ve discovered exemplar counter-examples where altruism trumps selfishness. Let’s look at the business case behind one of these examples - the Open Source movement.

Despite governments’ and businesses acknowledging the value of Open Source in policies and initiatives over the last decade. And despite numerous attempts. They rarely achieve the level of collaboration experienced by Open Source communities. Why?
Looked at through the lens of traditional management, Open Source collaboration is time consuming, imprecise, unreliable, hard to manage, rarely addresses short term objectives, and hard to quantify in a business case. And yet, in a digital economy, collaborative communities regularly out-innovate and out-compete closed or centrally controlled initiatives.Backing successful collaboration within traditional business requires us to write compelling, counter-intuitive business cases which explain and justify the elusive practices of collaborative communities.This presentation explains the subtle magic of open strategies in business terms, and will help you convince your boss to back them.I’m going to focus on Open Source Software, but the principles translates across all types of Creative Commons - Open Data, Open Government, Open Standards, and other Open approaches.

This is what we will be covering today:
  • The digital economy,
  • Complexity,
  • Trust,
  • Motivations,
  • Innovation and Obsolescence.

The first thing to recognise is that the Digital Economy has fundamentally changed the rules of business. Ignore this at your own peril.Zero Duplication Costs and the Connectivity of the Internet has led to Wicked Complexity, Rapid Innovation, and on the flip side, Rapid Obsolescence.
Let’s start by talking about Complexity.Software systems have become huge, interdependent and complex.It is no longer possible for one person to understand all of a system’s intricacies.Solving problems requires the collective brain power of many people.
To understand this, we’ll introduce the Cynefin framework, which describes how different decision methodologies should be applied at different levels of complexity.The framework is broken into four decision-making domains.
The Obvious domain is the area of "known knowns".The relationship between cause and effect is clear.Establish the facts ("sense"), categorize, then respond, by following established rules and applying best practices.This is the province of standard operating procedures and legal structures.Beware of complacency, over-simplifying or creating volumes of processes and unwieldy red tape.
The Complicated domain is the "known unknowns".The relationship between cause and effect can be deduced from analysis or expertise and there are a range of right answers.Assess the facts, analyze, and apply the appropriate good operating practice.This is the province of experts.Be aware of the trustworthiness of advice, influence from vested interests, and balancing short versus long term goals.
The Complex domain is for the "unknown unknowns".Cause and effect can only be deduced in retrospect, and there are no right answers.Instructive patterns can emerge by conducting experiments that are safe to fail.This is the provenance of hypotheses and the scientific method.
In the Chaotic domain, cause and effect are unclear, and events are too confusing to wait for a knowledge-based response.Act to establish order; sense where stability lies; respond to turn the chaotic into one of the other domains.This is the domain of firm leadership, tough decisions and action.
Open source collaboration has proven to be very effective within Complex and Complicated domains, which begs the question of “why”?Why is an open approach so effective within complex domains, and conversely, why aren’t open approaches as dominant in Obvious and Chaotic domains?
Let’s start by looking at the characteristics of Open Source.
A study from the University of Masachusetts, which studied tens of thousands of Open Source projects, produced some interesting findings.Firstly, most projects are abandoned, and of those that succeed, most only have a few developers, with the extra developers often coming from another country.(Source data)
On this graph we’ve drawn in the success rate for the projects.As you attract developers, your chance of long term success increases dramatically.This is showing ruthless Darwinian evolution at work.
Effectively, Open Source is an environment where lots of competing ideas are tested.Only projects of exceptional quality attract sustained growth and large communities.
And this is a key characteristic to notice. When you are giving away your software for free, success depends upon:
  • A compelling vision,
  • Clear utility,
  • And being so welcoming and caring that you attract and retain contributors.
The study also noticed that projects which grow:
  • Typically provide fine scaled task granularity, making it easier for people to contribute,
  • And often have attracted financial backing.
And here we start to uncover the magic of Open Source.In the digital economy, there are more developers working on your problem, than you will ever have in your team. When projects can tap into this,Collaboration out-competes competition!
Let’s look at one of the key factors in complicated systems - trust; and question what makes trustworthiness.
It turns out we all make use of a variant of this trustworthiness equation.
  • We trust people who are credible and have a track record of providing reliable advice in the past.
  • We trust people who are open and transparent.
  • We trust ourselves, our family, our friends, because they look out for us, and we look out for them.
  • And we are suspicious of people who stand to gain from advice they give us.

We also trust processes.
  • We trust that the scientific method leads to reliable research that we should act upon.
  • We trust that the competition of market economies leads to better products.
  • We trust that the democratic process leads to fair governance and management of resources.
But, we also know that all processes can be gamed.And the more complex a system, the easier it is to bamboozle people, and game the system.
Part of the reason Open Source has been so successful is that it’s characteristics lead to trustworthiness.These include:
  • Freedom and Altruism,
  • Openness,
  • Bottom up decision making,
  • Do-ocracy,
  • Meritocracy,
  • And modularity.
Let’s look at these in more detail.

… starting with Freedom and Altruism.Open source, by definition, is given away for free, with the freedom to use and extend it as you see fit.Why are open source developers so altruistic?It turns out that it is wrong to assume that we humans are only driven by self interest.As noted by Dan Pink in his book Drive, after our basic needs are met, we are also motivated by …
Autonomy. The desire to be self directed.
Mastery, the urge to get better at stuff.
And Purpose,The desire to do something with meaning and importance.Such altruistically motivated people, who provide significantly more value to the receiver than to the giver, increases the trustworthiness of the giver.
Then there is Openness.Openness and transparency is almost universally applied to all Open Source development and communication.
  • Conversations are public; Everyone has the opportunity to join and contribute;
  • Decisions are made openly;
  • And issues and limitations are published and shared.
Being transparent and open to public critique reduces the potential for hidden agendas and creates trustworthiness.

And within Open Source communities, decisions tend to be made bottom-up rather than top-down.When you can trust the motivations of your community, you are empowered use of bottom up decision making.
This is important, because in a complex system, the person closest to the problem is usually the best qualified to make decisions.
It creates a culture of “do-ocracy”.Within a do-ocracy the person motivated to do the work decides what gets done. Their commitment is a better indicator of true value than a person at the top saying “someone should fix this”.
This leads into Meritocracy.In a meritocracy, the best ideas win, no matter who suggests them. It is the sign of an egalitarian community rather than a hierarchical or dysfunctional one.
But we should be careful not to suggest that open practices easily solves all problems.Open Source projects are highly susceptible to being Loved to Death. This happens when a project attracts an engaging user base without attracting matching contributions. Volunteer become overwhelmed leaving insufficient capacity to cover essential business-as-usual tasks.Don’t to overload the community you depend upon. It is both bad karma and bad business.Successful projects have worked out how to either:
  • Politely say NO to “gifts” of unsupported extra code and excessive requests for help;
  • Or how to help uses become contributors, either in kind, or financially.
If your organisation isn’t ready to act as a good community citizen, actively caring about the community’s long term sustainability, then you will probably have a disappointing Open Source experience. You will make self-centred, short term decisions, and you won’t get the support you need when you most need it. You will likely be better off with proprietary software. (And the community would be better off without you.)
A key strategy for managing complexity is to divide large systems into modular subsystems.Using modular architectures, connected by open standards:
  • Reduces system complexity,
  • Enables interoperability,
  • Which reduces technical risk,
  • it enables collaboration,
  • And facilitates sustained innovation.
It means you can improve one module, without impacting the rest of your system.This helps with maintenance, innovation, and keeping up with latest technologies.
Collaboration is a key focus of both Open Source and Open Standards narratives. Hence, successful Open Source applications usually provide exemplary support for standards.
By comparison, from the perspective of dominant proprietary companies, it makes business sense to apply vendor lock-in tactics, making cross-vendor integration difficult.Adoption of Open Standards threatens vendor lock-in tactics, and consequently dominant vendors are often reluctant and half-hearted in their support of Open Standards.
Effectively, we are talking about monopolies.Because software is so time consuming to create and so easy to copy, it is excessively prone to monopolies.This holds true for both proprietary and open source products. A product that becomes a little better than its competitors will attracts users, developers and sponsors, which in turn allows that product to grow and improve quickly, allowing it to attract more users.This highly sensitive, positive feedback leads to successful software projects becoming “category killers”.
This means that most of the software you own is likely to be out-innovated within a year or two.Your software is not an asset, it is a liability needing to be updated, maintained, and integrated with other systems.It is technical debt, and unless a product is part of your core business, you should try to own as little of it as possible.The question is: should you select Proprietary or Open Source as the alternative?
Open Source and Proprietary business models differ in how their realised value is shared.
Open source licenses are structured such that multiple companies can use and support the same open source product, so the market self corrects any tendencies toward price-fixing.It enables everyone to share in the value created by technology.
By comparison, the ruthless competition between proprietary companies results in “winner takes all” scenarios. Many of the richest people in the world are self made software entrepreneurs.
These are typically people and organisations who have mastered the Chaotic domain.
Let’s take a quick look into the indicators for successful open projects.
To get insights into project health, you can look at Open Hubmetrics. In particular, look for signs of sustained collaboration and growth.
Another strong indicator of a project’s success is whether it has completed an Open Source Foundation’s incubation process.I’ve been involved with the Open Source Geospatial Foundation’s incubation process where we look for indicators of:
  • Quality
  • Openness
  • Community Health
  • Maturity
  • And sustainability

Bringing this all together into a concise elevator pitch:
  • The Digital Economy leads to High Complexity, Rapid Innovation and Rapid Obsolescence. Get with the program, or become obsolete.
  • Increased complexity requires us to trust. So increase the value you place on trustworthiness, openness and transparency.
  • Software is technical debt. It needs significant maintenance to remain current. Own as little of it as possible.
  • For the long term play, Collaboration trumps Competition.
  • Truly care about your community, and they will care about you.
  • Learn how to describe the business case for good behaviour. It is counter-intuitive, but it is the foundation for long term successful business strategies.

© 2018 Cameron Shorter. The text behind these slides, is licensed under a Creative Commons Attribution 4.0 International License.This slide deck is available online.
Categories: OSGeo Planet
Syndicate content