Welcome to Planet OSGeo

November 16, 2018

Ya está disponible la grabación del taller sobre ‘Generación de informes con gvSIG Desktop’ impartido durante las 14as Jornadas Internacionales gvSIG.

El taller, enfocado a preparar capas y mapas en gvSIG para ser integrados en el diseñador de informes JasperSoft Studio y a crear documentos de tipo ‘Informe’ en gvSIG que incluyesen los informes creados con JasperSoft Studio, se realizó sobre la última versión de gvSIG (gvSIG 2.5), que aún está en desarrollo, para el cual se ha desarrollado este nuevo plugin. No obstante, ya hay una distribución para descargar y probar, incluyendo el creador de informes.

Para iniciar el taller es necesario disponer de:
gvSIG Desktop 2.5.
– JasperSoft Studio: Versión oficial.
Plugin para JasperSoft Studio de Web Service Data Source (descarga mediante registro),  o enlace alternativo.

Se deberán de buscar los tres ficheros .jar del plugin que se encuentran en la carpeta “jss” y copiarlos en la carpeta de JasperSoft/plugins.

Los datos para seguir el taller pueden descargarse de la web oficial (o descarga alternativa).

El vídeo con la grabación del taller es el siguiente:

by Mario at November 16, 2018 01:41 PM

The material of the workshop about environmental modelling using gvSIG and the HortonMachine, given at 14th International gvSIG Conference some days ago, is now available.

Although the screen image is not very clear it can be followed with the teacher instructions, and using the cartography and tutorial available to download at this link.

The HortonMachine library is an open geospatial library integrated in gvSIG containing tools for the management of environmental data and hydro-geomorphological analyses. The algorithms contained in the library are the result of more than 10 years of research, development and real application by different researchers and professionals working in the field of natural hazards.

Recording of this workshop is available here:

by Mario at November 16, 2018 08:39 AM

November 15, 2018

Uno de los sectores en los que estamos realizando cada vez más proyectos desde la Asociación gvSIG es el de la Agricultura. Un área donde la aplicación de la geomática es amplia y que engloba proyectos tanto de gestión como de explotación o investigación.

Durante las pasadas 14as Jornadas Internacionales de gvSIG hubo una sesión dedicada a este tipo de proyectos, de la que ahora os compartimos los vídeos de las presentaciones realizadas.

En primer lugar queremos destacar la ponencia ‘Soluciones gvSIG para Agricultura en la Generalitat Valenciana.’. Muestra como el software libre se está aplicando para poner en marcha aplicaciones tan importantes como las que conllevan la gestión de las ayudas de la PAC (la Política Agraria Común) y la gestión del Registro general de la producción agrícola (REGEPA). Aplicaciones con un alto nivel de complejidad técnica ya que deben implementar todo tipo de reglas topológicas.

En segundo lugar un proyecto de investigación muy interesante llevado a cabo por Ángel Marqués-Mateu con título ‘Cartografía de precisión de la salinidad del suelo en cultivos de arroz.

Para finalizar la presentación de GODAN, ‘The role of open data and innovation in ensuring global food security’ que nos remarca la importancia que pueden tener los datos abiertos y el software libre.

¡Qué los disfrutéis!

by Alvaro at November 15, 2018 02:13 PM

November 14, 2018

Bajo este titular ha sido referenciado hoy en la práctica totalidad de la prensa el sistema impulsado por Diputació de València, a través del área de Información Territorial de Divalterra y el Consorcio Provincial de Bomberos y desarrollado en colaboración con la Asociación gvSIG. La plataforma, basada en gvSIG Online, fue presentada en las pasadas 14as Jornadas Internacionales de gvSIG. Ver como la Suite gvSIG está formando parte de importantes proyectos, por dimensión y por su influencia en mejorar la vida de los ciudadanos, es algo que nos produce una enorme satisfacción.

Os dejamos con la información extraída de la nota de prensa oficial y con un vídeo de presentación de la solución:

El Circuit Ricardo Tormo de Cheste estrenará el fin de semana del 16 al 18 de noviembre, durante la celebración del Gran Premio de Motociclismo, un sistema pionero de gestión de emergencias para prevenir y dar la respuesta más ágil a los incidentes que puedan registrarse tanto en el recinto como en el entorno del Circuit, incluidas las carreteras de acceso y los núcleos de población cercanos.

Se trata de un servidor cartográfico que utiliza tecnología GIS e incluye los datos procedentes del Plan de Autoprotección del Circuito, y se presenta de manera digital a través de cualquier equipo informático. De esta manera, se agilizan las consultas y se dispone al momento de todo tipo de información de utilidad para dar respuesta a las emergencias. El servidor cartográfico permitirá agilizar la gestión de cualquier incidente de seguridad. De esta manera, se agilizan las consultas y se dispone al momento de todo tipo de información de utilidad para dar respuesta a las emergencias.

Además, desde el Consorcio Provincial de Bomberos se dará acceso a esta herramienta informática a todos los organismos implicados en garantizar la seguridad en la concentración deportiva, como Delegación de Gobierno, Guardia Civil, Generalitat Valenciana y la propia seguridad del Circuit, con el fin de asegurar una máxima coordinación entre todas las partes.

El oficial jefe de Prevención del Consorcio Provincial de Bomberos de Valencia, Jorge Sánchez, explica que “la cantidad de información que nos aporta, agiliza de manera muy importante la toma de decisiones en momentos en los que cada segundo que se gane puede ser vital”.

Sánchez indica que “en España no hay ningún organismo con una herramienta GIS tan potente como esta para la gestión de emergencias” y avanza que “ya se está trabajando para aplicarla a otras infraestructuras como los edificios de la Universidad, Metrovalencia, las Fallas, etc”.

El director del Proyecto, Antonio Mas, explica que “el proceso se ha desarrollado en completa coordinación con el Consorcio de Bomberos, para asegurar que las funcionalidades que se iban desarrollando desde Divalterra eran las que realmente resultaban de utilidad para ellos”.

Para ello, se recopiló toda la documentación existente, que estaba en formato papel, y tras la definición de los términos y cartografía a implementar, se procedió a elaborar todos los mapas en formato digital. Una vez implementada la parte gráfica, se procedió al volcado de toda la documentación recopilada.

Así, recoge imágenes y datos detallados sobre los accesos y salidas del recinto, elementos de protección, recorrido hasta los accesos, rutas de evacuación, gradas, locales, recintos y edificios, y también todas las actividades de riesgo de empresas próximas, así como el posible transporte de mercancías peligrosas.

De esta manera, este servidor cartográfico permite, ante una emergencia, saber en qué punto exacto se ha producido el incidente y a qué distancia se encuentran los accesos y salidas más cercanas, cuál es el recorrido, los hidrantes más próximos, las características de la infraestructura donde se ha producido, si existen elementos colindantes o las zonas industriales próximas y sus planes de evacuación, entre otra información de utilidad.

by Alvaro at November 14, 2018 03:28 PM

O CSW é um padrão para expor um catálogo de entidades geoespaciais através do procotolo HTTP. Em um portal GeoNode, os pontos de extremidade (endpoints) do CSW são fornecidos pelo pycsw, que é um componente subjacente do GeoNode. Alternativamente, se necessário, é possível substituir o pycsw pelo GeoNetwork.

No GeoNode, você pode acessar facilmente o registro CSW de uma camada, clicando no botão Baixar Metadados na página da camada. Um formulário aparecerá e você poderá acessar os metadados fornecidos pelo pycsw em uma série de diferentes formatos (Atom, Dublin, FGDC, Text, HTML e muitos outros).

Por exemplo, ao clicar no link ISO, você acessará os metadados da camada no formato ISO, que corresponde a essa solicitação GetRecordById no pycsw:

http://localhost:8000/catalogue/csw?outputschema=http%3A%2F%2Fwww.isotc211.org%2F2005%2Fgmd&service=CSW&request=GetRecordById&version=2.0.2&elementsetname=full&id=8bcf5bfc-5cfc-11e7-8103-02d8e4477a33

Você também pode notar outras informações que foram geradas pelo GeoNode nos bastidores quando a camada foi carregada:

  • Identificador da camada, que identifica exclusivamente a camada no catálogo (observe que a solicitação GetRecordById usa esse identificador para acessar o registro)
  • Data de criação
  • Sistema de referência espacial e caixa delimitadora (BBOX)
  • URL da miniatura
  • Formato do recurso
  • Vários endpoints do OGC

Se você quiser adicionar metadados ausentes, visite a página de metadados da camada e pressione em Editar Camada > Editar Metadados.

1. Operações pycsw

O pycsw implementa todas as operações do padrão CSW, incluindo as opcionais:

  • GetCapabilities: recupera metadados de serviço do servidor
  • DescribeRecord: permite que um cliente descubra elementos do modelo de informações suportado pelo serviço de catálogo de destino
  • GetRecords: procura registros usando uma série de critérios
  • GetRecordById: recupera metadados para um registro (camada) do catálogo por seu id
  • GetDomain (opcional): recupera informações de tempo de execução sobre o intervalo de valores de um elemento de registro de metadados ou um parâmetro de solicitação
  • Harvest (opcional): cria / atualiza metadados pedindo ao servidor para “puxar” metadados de algum lugar
  • Transaction (opcional): criar / editar metadados “empurrando” os metadados para o servidor

O pycsw é uma implementação do serviço OGC CSW escrita em Python. Iniciado em 2010 (mais formalmente anunciado em 2011), o pycsw permite a publicação e descoberta de metadados geoespaciais por meio de várias APIs (CSW 2 / CSW 3, OpenSearch, OAI-PMH, SRU), fornecendo um componente de metadados e catálogo baseado em padrões para infraestruturas de dados espaciais. O pycsw é Open Source, lançado sob uma licença MIT e executado em todas as principais plataformas (Windows, Linux e Mac OS X).

Fonte: Paolo Corti

by Fernando Quadro at November 14, 2018 10:30 AM

November 13, 2018

A partir do PostGIS 2.3, a extensão do postgis foi alterada para não permitir mais a realocação. Todas as chamadas de função agora são qualificadas pelo esquema.

Embora essa alteração tenha corrigido alguns problemas com a restauração do banco de dados, ela criou o problema, pois se você instalou o PostGIS em um esquema diferente daquele que você desejava, não é intuitivo como movê-lo para um esquema diferente. Felizmente há uma maneira de fazer isso.

Para este exemplo, o PostGIS foi instalado no esquema padrão para demonstrar como movê-lo para outro esquema. Você pode executar estas etapas usando o psql, pgAdmin ou qualquer outra ferramenta desejada.

A maioria das pessoas tem seu esquema padrão configurado como public, caso você não especifique explicitamente um esquema na instalação, geralmente o PostGIS será instalado no esquema public.

CREATE EXTENSION postgis;

Agora vou criar um novo esquema para movê-lo e adicionar este esquema ao search_path:

CREATE SCHEMA postgis;
 
ALTER DATABASE mydb 
SET search_path = public, postgis;

Se você estiver executando o PostGIS 2.3 ou superior, tente mudar para um esquema diferente usando o comando abaixo:

ALTER EXTENSION postgis 
  SET SCHEMA postgis;

Isso irá falhar e o banco irá plhe apresentar o seguinte erro “ERRO: a extensão “postgis” não suporta SET SCHEMA”.

Para permitir o movimento, siga estes passos:

UPDATE pg_extension 
  SET extrelocatable = TRUE 
    WHERE extname = 'postgis';
 
ALTER EXTENSION postgis 
  SET SCHEMA postgis;
 
ALTER EXTENSION postgis 
  UPDATE TO "2.4.1next";
 
ALTER EXTENSION postgis 
  UPDATE TO "2.4.1";

Observe o uso da expressão next. É necessário utilizar a expressão next nesta etapa para atualizar todas as referências das funções do esquema atual para o novo do esquema. Next é projetado para permitir a atualização de uma extensão do postgis para uma versão já existente. Tentar executar UPDATE TO “2.4.1” quando você já está no 2.4.1 acionaria um erro, pois você já está nessa versão.

Fonte: PostGIS

by Fernando Quadro at November 13, 2018 10:30 AM

As promised some time ago in “The new QML widgets in QGIS – When widgets get unbridled” we still owe you some fancy unicorns, but first let’s have a look at another nice feature that has been introduced in QGIS 3.4 LTR,  the reading of PostgreSQL JSON and JSONB types.
With JSON you have a lot of possibilities for storing unstructured data. In our case, it’s mainly interesting when the data are stored as an array or a JSON object. Let’s have a look at two examples.

Visualize Postgres JSON data with common widgets

With the usual QGIS widgets “List” and “Key/Value” you are able to display JSON arrays and simple JSON objects.

JSON array as List

[
    "European dark bee",
    "Carniolan honey bee",
    "Buckfast bee"
]

Simple JSON object as Key/Value

{
    "nomenclatura":"Apis mellifera mellifera",
    "name":"European dark bee",
    "link":"https://en.wikipedia.org/wiki/European_dark_bee"
}

Or of course both as plain text in the “Text Edit” widget:

Say hi to Postgres JSON in QML widget

Probably, your JSON data does not look really nice with the aforementioned widgets, luckily since QGIS 3.4, you are free to create your own QML widget. Since QGIS already loads the JSON data into structures that are supported by QML, we can use all the JSON data within the QML code.
Let’s assume you have the JSON array from above and you like the elegance of the blue of Jacques Majorelle. You create your personal list widget by adding the JSON field as an expression:

import QtQuick 2.0
Rectangle {
    width: 310; height: 250; color: "grey"
    Column {
        anchors.horizontalCenter: parent.horizontalCenter
        anchors.verticalCenter: parent.verticalCenter
        spacing: 5
        Repeater {
            model:expression.evaluate("\"jvalue\"")
            Rectangle {
                color: "#6050dc"
                width: 300; height: 50; radius: 10.0
                Text {
                    anchors.centerIn: parent
                    font.pointSize: 24
                    text: modelData
                }
            }
        }
    }
}

You will have your very personal list:

JSON also allows storing more complex data, like for example a list of objects. In that case, you will reach the limits of the common QGIS widgets.
Let’s assume you have a table looking like this:

nomenclatura name link
Apis mellifera mellifera European dark bee https://en.wikipedia.org/wiki/European_dark_bee
Apis mellifera carnica Carniolan honey bee https://en.wikipedia.org/wiki/Carniolan_honey_bee
Apis mellifera Buckfast bee https://en.wikipedia.org/wiki/Buckfast_bee

In JSON it would be stored like this:

[
    {"nomenclatura":"Apis mellifera mellifera","name":"European dark bee","link":"https://en.wikipedia.org/wiki/European_dark_bee"},
    {"nomenclatura":"Apis mellifera carnica","name":"Carniolan honey bee","link":"https://en.wikipedia.org/wiki/Carniolan_honey_bee"},
    {"nomenclatura":"Apis mellifera","name":"Buckfast bee","link":"https://en.wikipedia.org/wiki/Buckfast_bee"}
]

With the QML Widget you can use the QML TableView to visualize:

import QtQuick 2.0
import QtQuick.Controls 1.4
TableView {
    width: 600
    model: expression.evaluate("\"jvalue\"")
    TableViewColumn {
        role: "nomenclatura"
        title: "Nomenclature"
        width: 200
    }
    TableViewColumn {
        role: "name"
        title: "Name"
        width: 200
    }
    TableViewColumn {
        role: "link"
        title: "Wikipedia"
        width: 200
    }
}


Or, even more powerful, you can create your super individual table using the model and create each row by using a QML Repeater.
Additionally, you can use a lot of fancy stuff like:

  • mouse interaction
  • animation
  • opening an external link
  • … and so on


The QML code for that looks like this.

import QtQuick 2.0
Rectangle {
    width: 610; height: 500
    Column {
        anchors.horizontalCenter: parent.horizontalCenter
        anchors.verticalCenter: parent.verticalCenter
        Repeater {
            model: expression.evaluate("\"jvalue\"")
            Row {
                id: theRow
                height: mouseArea1.containsMouse || mouseArea2.containsMouse || mouseArea3.containsMouse ? 70 : 50;
                Rectangle { color: "lightblue";
                            border.width: 1
                            width: 150; height: parent.height
                            Text { anchors.centerIn: parent
                                   font.pointSize: 10; text: modelData.nomenclatura }
                            MouseArea {
                                id: mouseArea1
                                anchors.fill: parent
                                hoverEnabled: true
                            }
                }
                Rectangle { color: "lightgreen";
                            border.width: 1
                            width: 150; height: parent.height
                            Text { anchors.centerIn: parent
                                   font.pointSize: 10; text: modelData.name }
                            MouseArea {
                                id: mouseArea2
                                anchors.fill: parent
                                hoverEnabled: true
                            }
                }
                Rectangle {
                            id: linkField
                            color: "lightyellow";
                            border.width: 1
                            width: 300; height: parent.height
                            Text { anchors.centerIn: parent
                                   font.pointSize: 10; text: modelData.link }
                            MouseArea {
                                id: mouseArea3
                                anchors.fill: parent
                                hoverEnabled: true
                                onPressed: linkField.state = "PRESSED"
                                onReleased: linkField.state = "RELEASED"
                                onClicked: Qt.openUrlExternally(modelData.link)
                            }
                            states: [
                                State {
                                    name: "PRESSED"
                                    PropertyChanges { target: linkField; color: "green"}
                                },
                                State {
                                    name: "RELEASED"
                                    PropertyChanges { target: linkField; color: "lightyellow"}
                                }
                            ]
                            transitions: [
                                Transition {
                                    from: "PRESSED"
                                    to: "RELEASED"
                                    ColorAnimation { target: linkField; duration: 1000}
                                },
                                Transition {
                                    from: "RELEASED"
                                    to: "PRESSED"
                                    ColorAnimation { target: linkField; duration: 1000}
                                }
                            ]
                }
            }
        }
    }
}

And that’s it

I hope you liked reading and you will enjoy using it to make beautiful widgets and forms. If you have questions or inputs, feel free to add a comment.
… and in case you still asking where the promised unicorns are. Here’s is a super-fancy implementation 😉

by David at November 13, 2018 08:00 AM

November 12, 2018

Prezado leitor,

Se você usa o GeoServer, já teve ter percebido que desde a versão 2.8.x existe um problema na tradução para o português brasileiro (pt-BR).

O que parece ter ocorrido, é que quando se foi criar os arquivos properties usaram como base os arquivos do idioma espanhol que ainda não estavam finalizados, por isso o GeoServer hoje tem termos em inglês, português e espanhol.

Eu gostaria então de convidar você, que utiliza o GeoServer e tem uma certa fluência em inglês, para que nos ajude a finalizar essa tradução para a próxima versão do GeoServer, que será a 2.15.x.

Quem se interessar, peço que se cadastre no Site Oficial da tradução:

Página Oficial de tradução do GeoServer
Página Oficial de tradução do GeoServer (Equipe pr-BR)

Quem se registrar já pode iniciar iniciar a tradução!

by Fernando Quadro at November 12, 2018 10:30 AM

November 11, 2018

November 10, 2018

If you follow me on Twitter, you have probably already heard that the ebook of “QGIS Map Design 2nd Edition” has now been published and we are expecting the print version to be up for sale later this month. Gretchen Peterson and I – together with our editor Gary Sherman (yes, that Gary Sherman!) – have been working hard to provide you with tons of new and improved map design workflows and many many completely new maps. By Gretchen’s count, this edition contains 23 new maps, so it’s very hard to pick a favorite!

Like the 1st edition, we provide increasingly advanced recipes in three chapters, each focusing on either layer styling, labeling, or creating print layouts. If I had to pick a favorite, I’d have to go with “Mastering Rotated Maps”, one of the advanced recipes in the print layouts chapter. It looks deceptively simple but it combines a variety of great QGIS features and clever ideas to design a map that provides information on multiple levels of detail. Besides the name inspiring rotated map items, this design combines

  • map overviews
  • map themes
  • graduated lines and polygons
  • a rotated north arrow
  • fancy leader lines

all in one:

“QGIS Map Design 2nd Edition” provides how-to instructions, as well as data and project files for each recipe. So you can jump right into it and work with the provided materials or apply the techniques to your own data.

The ebook is available at LocatePress.

by underdark at November 10, 2018 02:58 PM

Con motivo de las 5as Jornadas gvSIG Uruguay (Montevideo, 18-19 octubre 2018) se impartió un taller de “Scripting: Exprimiendo / Extendiendo gvSIG ” por parte de Carlos Colombana.

Ahora se ha publicado el material de dicho taller, en el que se muestran las principales funcionalidades del módulo de Scripting, con el fin de obtener el máximo rendimiento y de expandir las capacidades de gvSIG. En él se ven las principales etapas del proceso de desarrollo de add-ons, para el caso particular de un geo-codificador de direcciones geográficas.

Podéis descargar el material para poder seguir el taller desde el siguiente enlace.

by Mario at November 10, 2018 09:45 AM

November 08, 2018

Ya está disponible la grabación del Taller de gvSIG aplicado a Geología impartido durante las 14as Jornadas Internacionales gvSIG.

En este taller se aborda un análisis integrado que permite la toma de decisiones relacionadas con cuestiones tan dispares como la investigación de recursos minerales, la protección del patrimonio paleontológico, la rentabilidad económica de una explotación minera o su viabilidad ambiental. Todo ello a través de distintas herramientas de edición y geoprocesos de gvSIG desde una perspectiva geológica, realizando una cartografía a partir de datos tomados en campo y la planificación de una investigación geológica. Además se utilizan fuentes de información pública procedentes de diferentes administraciones.

Para realizar este taller podéis descargar la cartografía desde el siguiente enlace.

Si tenéis alguna duda sobre el manejo de gvSIG en la realización de este taller podéis utilizar la lista de usuarios del proyecto.

Y aunque los últimos minutos no estén disponibles aquí tenéis el vídeo con más de dos horas de taller para practicar:

 

by Mario at November 08, 2018 10:34 PM

Tom Kazimiers trabalha como engenheiro de software no Howard Hughes Medical Institute, em um software colaborativo de reconstrução e análise de neurônios chamado CATMAID, que é usado para pesquisa em neurociência.

O PostGIS é utilizado nesse projeto para representar os neurônios em um espaço 3D. Eles consistem em pontos 3D que fazem referência a seus nós pai ou a raiz, quando eles não têm pai. Juntamente com sinapses, nuvens de pontos e malhas para modelar compartimentos em um conjunto de dados, eles modelam os aspectos espaciais do mundo da neurociência. Os usuários criam essas reconstruções neuronais manualmente de forma colaborativa, e os programas de segmentação podem ser usados ​​como fonte de dados adicional.

Usando seus índices espaciais, o PostGIS ajuda a consultar rapidamente os neurônios em um determinado campo de visão. O espaço de um único projeto contém, por vezes, centenas de milhões de pontos individuais interconectados. Também é possível fazer consultas de interseção (BBOX) entre os neurônios e as malhas dos compartimentos, que depois se refinam no front-end fazendo testes de interseção mais precisos.

Este software é usado por alguns laboratórios de pesquisa e, todos eles fazem sua própria hospedagem com um servidor dedicado. A razão principal para isso é que com conjuntos de dados maiores, eles se beneficiam de máquinas com muita RAM (> 256G), unidades SSD e muitas CPUs, além de acesso rápido a dados locais para, por exemplo, dados de imagem.

Muito interessante saber que o PostGIS funciona tão bem em contextos não-GIS também.

Fonte: PostGIS Blog

by Fernando Quadro at November 08, 2018 10:30 AM

ASITA 2018

GeoSolutions sarà presente alla 22esima conferenza nazionale ASITA dal 27 al 29 Novembre 2018 presso l'hotel Four Points Sheraton a Bolzano con un proprio stand, dove vi aspettano per parlare di come poter soddisfare i vostri bisogni attraverso i nostri prodotti Open Source GeoServer, MapStore e GeoNode ed attraverso i nostri piani di supporto professionale e consulenza.
 
Durante la conferenze i tecnici di GeoSolutions prenderanno parte Martedì 27 Novembre dalle ore 14:30 alle ore 18:30 alla sessione parallela #2 "Infrastrutture di dati geografici e interoperabilità" con i seguenti interventi:
  • MapStore: Modern WebMapping con OpenLayers, Leaflet e React con Mauro Bartolomeoli
  • GeoServer, il server open source per la gestione interoperabile dei dati geospaziali con Andrea Aime
  • INSPIRE services con GeoServer ed HALE, state of the art con Simone Giannecchini

Inoltre, Mercoledì 28 Novembre dalle ore 11:30 alle ore 13:30 Simone Giannecchini terrà un workshop dal titolo "Infrastrutture per dati territoriali con i prodotti Open Source di GeoSolutions: introduzione e casi di successo" dove dopo una prima sessione di approfondimento sulla offerta di GeoSolutions  e sui propri prodotti Open Source verranno mostrati alcuni casi di successo a livello italiano ed internazionali di infrastrutture di dati geosapaziali create in collaborazione con GeoSolutions. Di seguito l'agenda dettagliata.

  • GeoSolutions, chi siamo e cosa facciamo
  • Introduzione ai prodotti Open Source di GeoSolutions: GeoServer, MapStore, GeoNode
  • Il SIT del Comune di Bolzano
  • La SDI del Comune di Genova
  • Un esempio di piattaforma DAAS (data-as-a-service) commerciale per il mondo Oil&Gas
  • Un esempio di piattaforma DAAS (data-as-a-service) commerciale per il mondo Earth Observation
  • La piattaforma IHP-WINS dell'UNESCO
If you are interested in learning about how we can help you achieving your goals with our open source products GeoServerGeoNodeMapStore and GeoNetwork as well as throw our Enterprise Support Services and GeoServer Deployment Warranty offerings, feel free to contact us!
 
The GeoSolutions team,

by simone giannecchini at November 08, 2018 10:00 AM

November 07, 2018

Cuando se trabaja con vidas humanas la elección de la tecnología no es algo baladí. Cuando se trata de analizar datos que pueden darnos la información necesaria para evaluar la seguridad ciudadana tampoco.

En las pasadas 14as Jornadas Internacionales de gvSIG hubo un par de sesiones temáticas dedicadas a la Seguridad, Emergencias y Protección Civil. Ponencias cuya grabación ahora ya tenéis disponible para su consulta.

Aplicar nuestros conocimientos y ver cómo se aplica la tecnología que impulsamos para proyectos como los que os traemos en este post nos produce a todo el equipo de la Asociación gvSIG una enorme satisfacción. El software libre, el conocimiento, al servicio de la gente, en las situaciones más críticas.

En primer lugar os enlazamos el vídeo a la ponencia titulada ‘Base de datos geográfica de artefactos explosivos improvisados’. Proyecto relacionado con la lucha antiterrorista que hemos abordado para MINUSMA (Misión Multidimensional Integrada de Estabilización de las Naciones Unidas en Malí).

Antes de seguir, una ponencia invitada a este post…la presentación del proyecto SIGAPRED que fue realizada unos días antes en las 5as Jornadas gvSIG de Uruguay. El motivo, la relación directa con el post, en ella se habla de la IDE implantada en  el Observatorio de Estudios Sobre Convivencia y Seguridad Ciudadana de la Provincia de Córdoba (Argentina)

Pasamos a una ponencia con una componente tecnológica ‘especial’, en la que hemos integrado en gvSIG Online algoritmos que permiten determinar la cobertura de REMER, la Red de Radio Emergencia de la Dirección General de Protección Civil y Emergencias.

El año pasado presentaron la puesta en marcha de gvSIG Online, y este año el Consorcio Provincial de Bomberos de Valencia nos muestra como utilizan una Infraestructura de Datos Espaciales en software libre para la prevención y gestión de emergencias. Muy recomendable ver la evolución del proyecto y su expansión a todo tipo de ámbitos relacionados con la actividad del CPB Valencia.

Geoscan, expertos en geología y SIG, nos mostraron como gvSIG ha sido utilizado como herramienta de apoyo en el estudio de deslizamientos

Llevamos varios años impartiendo cursos para la Escuela Nacional de Protección Civil de España. Es especialmente satisfactorio ver como los alumnos aplican gvSIG a temas como los accidentes de mercancías peligrosas en carretera

Seguimos con la presentación del policía local Gilberto Díaz, que nos presentó la ponencia ‘Perspectivas de gvSIG en materia de siniestralidad vial’

Y para acabar os traemos dos ponencias relacionadas con trabajos de investigación en los que estamos trabajando junto a expertos en estadística de la Universitat Jaume I, por un lado nuevos desarrollos en gvSIG para criminología que pronto estarán disponibles:

…y por otro el uso de gvSIG para el análisis de datos geoestadísticos en el 112 (número único de asistencia a la ciudadanía ante cualquier tipo de emergencia).

Y si llegados a este punto, os preguntáis cómo aún no estáis trabajando con la Suite gvSIG y colaborando con la Asociación gvSIG, y queréis contactar con nosotros…os dejamos un email info@gvsig.com

by Alvaro at November 07, 2018 05:28 PM

Prezados leitores,

Hoje vamos falar sobre dois assuntos que estão bastante na “moda”, que é Open Data (Dados abertos) e Smart Cities (Cidades Inteligentes). Tenho lido bastante sobre esses assuntos nos últimos tempos e tenho visto algumas coisas que sinceramente não tem me agradado muito aqui no Brasil.

O primeiro ponto, é que tenho visto algumas cidades (prefeituras) implantarem acesso Wi-fi gratuito a população e após isso se auto intitularem Smart City, o que eu discordo totalmente. O conceito de Smart City é muito mais amplo que apenas disponibilizar Wi-fi a população.

Eu acredito que não tem como se tornar uma Smart City sem a implantação de Open Data. E vou além, sem que a população seja envolvida de uma forma que a própria veja a importância e o retorno que esses dados abertos trazem a ela própria.

Um modelo que vejo como referência tanto em Smart City como em Open Data é Nova Iorque. Lá, tudo começou a muitos anos atrás:

Como podem ver na imagem acima Nova Iorque já tem a cultura de disponibilizar dados desde 1974, porém em 2012 foi criada uma lei que diz que em Nova Iorque é obrigatório a disponibilização de dados abertos! Aqui no Brasil, eu não vejo outro caminho para que isso possa se tornar uma realidade. Eu sei que já temos o decreto da INDE, que é um grande avanço para disponibilização de dados, principalmente quando falamos em dados geoespaciais, porém, eu gostaria de ver algo mais enérgico, com prazos determinados para implantação, mesmo que esses prazos para as agencias governamentais sejam mais amplos (10 anos por exemplo, na esfera Municipal).

Outro ponto que vejo em Nova Iorque, é que eles tem um departamento full time trabalhando para que a implementação e a implantação dos dados abertos funcionem, e acho que precisamos disso também aqui no Brasil, talvez algo ligado ao IBGE, mas que pense 24h em dados abertos, e que possa dar suporte a todas as instâncias do governo (Federal, Estadual e Municipal).

E por último e não menos importante, para dar certo é essencial que haja engajamento com a população, ou seja, inserir a população nesse cenário, criando aplicativos para que o próprio cidadão possa inserir informação, indicar quando uma informação estiver errada, e principalmente usufruir do resultados dessas informações processadas através de aplicativos que serão desenvolvidos e que irão melhor a vida do cidadão.

Gostaria deixar claro que tudo que escrevi acima, é a minha opinião, e se você tiver uma visão diferente, fique a vontade de deixar seu comentário para que possamos conversar e trocar uma ideia.

Vou deixar alguns links sobre a questão do Open Data em Nova Iorque, para aqueles que tenham interesse no assunto:

GovTech – How New York City Tells the Story of its Open Data Work

Harvard Datasmart – New York City Open Data a Brief History

Amny – Open data is changing how New York City Government Work

by Fernando Quadro at November 07, 2018 01:08 PM

Ya se encuentran disponibles las presentaciones realizadas en las 5as Jornadas gvSIG Uruguay, que tuvieron lugar los días 18 y 19 de octubre en Montevideo.

También está disponible la grabación de las ponencias y de los talleres que se impartieron durante las jornadas para ser visualizados online.

Los talleres que se impartieron durante las jornadas fueron los siguientes: “R espacial y R con gvSIG”, “Scripting: Exprimiendo / Extendiendo gvSIG ” y “gvSIG Batoví”.

En el apartado de comunicaciones se puede encontrar el material necesario para poder seguirlos.

Si no pudiste asistir a las jornadas ya tienes todas las presentaciones y su grabación, así como una gran cantidad de material didáctico nuevo sobre gvSIG gracias a la grabación de los talleres.

by Mario at November 07, 2018 12:40 PM

It has rained a lot since we last wrote about MVT encoders performance. Taking advantage of the recent Postgis 2.5 release, we decided to update our measurements and explain why we made the switch and started generating vector tiles in the database.

Why?

A few weeks ago we decided to change our main tiler (Windshaft) to use Postgis’ St_AsMVT instead of node-mapnik as the default technology to generate MVT. Some of the reasons behind this decision were:

  • Database servers are scaled depending on customer needs, that means that by encoding MVTs in those servers we have more resources available to generate tiles faster. This also minimizes the friction between different users sharing resources in the tiler.
  • Reduce the network load between the database and the tiler as small geometries are discarded early in the process.
  • Mapnik bindings are limited (node, c++, python) while the only requirement to use Postgis is a database connection. As new projects arise inside CARTO, we can share the same encoder independently of their programming language. In a similar way, once we update Postgis all those projects benefit automatically from it.
  • It is easier for CARTO to improve Postgis as we have contributed to the project more frequently than to Mapnik.
  • Better overall performance.


How?

Our main concern when preparing the transition was to have the process be as seamless as possible, which meant having the tiles generated by St_AsMVT match the ones from Mapnik as close as reasonably possible.

Aside from multiple bugs fixed in Postgis 2.4.6 and 2.5, we introduced various performance improvements as a PARALLEL implementation. Tile by tile comparison even led us to find and address issues in our Mapnik stack.

Nevertheless, there are still some differences between the two renderers:

  • When working in PARALLEL, St_AsMVT duplicates keys and might introduce repeated values. This is discouraged in the spec, but valid nevertheless.
  • They have different behaviour when working with invalid geometries. Although it varies case by case, Mapnik tends to drop the invalid geometries and Postgis tries to fix them.
  • Depending on the encoding and simplification, Mapnik might not simplify the geometries as much as Postgis when retrieving them from the database so you might want to do an extra simplification step by passing the simplify_distance distance parameter to mapnik-vector-tile.
  • Mapnik assigns an id to each feature by generating it sequentially by tile. Postgis doesn’t add it as it’s optional per the MVT spec. In the next major release of Postgis (3.0) you will be able to assign it using a table column.
  • Mapnik orders feature properties alphabetically, while Postgis outputs them by their other in the database.

Performance comparison

As we mentioned before, one of the reasons that move us to use Postgis to generate vector tiles was performance and the graph at the header of the post shows the impact that it had in some of our platform benchmarks in production.

We set up a simple framework to test performance, not only to compare Mapnik and Postgis encoders but also different iterations of St_AsMVT.

Methodology

Datasets

To be able to compare distinct geometry types, we loaded several public datasets into the database using CARTO’s Import API:

We used simple SELECT queries as any complexity added there would affect both encoders in the same way.

Requests

We launched http requests against the tiler, running each different one at least 50 times and 30 seconds, and discarded the first 5 iterations to reduce the impact of hard drive cache misses.

The requests cover a different amount of geometries per tile and, in some cases, different amount of columns to be able to see the impact of attribute encoding. Since we observed a clear difference when geometries are discarded because of their size, we also had different zoom levels.

Server

The specs of the machine are:

  • Intel i7-5820K with 6 cores and 12 threads. Postgres had 10 worker processes available.
  • 32GB of RAM. Postgres had 4GB available for shared buffers, enough to fit these tables.
  • Linux running PostgreSQL 11.0, Postgis 3.0.0dev r16981, GEOS 3.7.0, protobuf 1.3.1, node 9.11.1 and node-mapnik v3.6.2-carto.11.
  • Any setup required (Windshaft, PostgreSQL) was identical between runs except for the setting to switch between encoders.

Results

Here are some of the most representative graphs derived from our tests:

  • Point geometries had a similar performance:


  • When we increased the number of columns per point we observed that properties encoding is faster (~1.2x) in Postgis:


  • Line geometries were encoded faster in St_AsMVT: 0.5x to 1.5x improvement depending on the zoom level.


  • Polygon geometries were faster in Mapnik (1.5x faster in some cases). When we analyzed it we observed that over 90% of the CPU cycles in St_AsMVTGeom went spent in St_MakeValid:


  • Postgis was faster discarding small polygons. In the extreme cases where everything is discarded it, e.g. city boundaries in the tile [0/0/0], it can be up to 20x faster.


Takeaways

One of the important aspects to consider when generating vector tiles is that their size and the time it takes to generate them it is highly tied to the number of properties that each geometry has associated. As seen above, the same point tile generated using St_AsMVT takes 9x more time when moving from 5 properties to 42. Consider optimizing your requests by simply removing unnecessary columns from the SQL queries.

A second element to consider is that since points aren’t simplified automatically by zoom level, the lower the zoom the more points were included in each tile. Point aggregations are a good way to work around this and improve performance by encoding too many points that are going to be rendered in the same place anyway.

Another idea we considered in the past was disabling polygon validation but we have discarded it as one single invalid polygon can pollute whole visualizations. It would be interesting to analyze why Postgis validation (based on GEOS) is way slower than Mapnik’s (based on Boost), and addressing this would benefit multiple SQL functions that use it, like St_IsValid.

As I final note, beware that Mapbox Vector Tile Specification version 3 is currently under development. It will bring new feature types and improvements to reduce tile size, but it will require adapting encoders and decoders which could impact performance.

November 07, 2018 08:00 AM

November 06, 2018

Individuality is the definition of freedom. And freedom is the fundamental requirement of man’s mind. QGIS possibly cannot give you all the freedom you require in life. But at least a lot of freedom in how you manage your work. QGIS 3.4.0 LTR was released last week and it comes loaded with features supporting big freedom in the configuration of your projects.  Let’s focus on the QML Widget. QML is the smart casual look of widgets. With the help of some simple code, you will be able to visualize your data in the attribute form like never before. You can display beautiful charts, complex JSON data, and fancy colored unicorns. 

How it’s done

Let’s start with an example. In the Attribute Form configuration in the Layer Properties you have first to activate the drag and drop designer. Not only can you drag the field- and relation-items from the available widget list to the form layout list, but also a QML Widget. When you drop this item, it creates an “instance” of a QML Widget. This means, you can drag and drop as many QML Widgets as you like to have on your form and configure each of them individually.

QML (Qt Modelling Language) is a user interface specification and programming language. It allows developers and designers alike to create highly performant, fluidly animated and visually appealing applications. QML offers a highly readable, declarative, JSON-like syntax with support for imperative JavaScript expressions combined with dynamic property bindings. Source: Qt documentation

It’s a bit like an HTML page on the attribute form but very well integrated with Qt.
On dropping the item, the configuration dialog pops up. After closing you can come back to it by double-clicking the item in the form layout list, like you do it with containers and tabs. If your don’t know QML that much yet, the default snippets from the drop-down can create an example of a rectangle, a pie chart or a bar chart. This could help you to create your own widget. On the right you can see a preview of your widget in real time. There are powerful layout possibilities to design it according to your ideas. For more information about it see the QML layout part of the Qt documentation.

But a chart makes no sense if there is no data. Of course, you can enter the data directly into your QML code, but most likely you need the data of the features to be visualized. This brings us to expressions. You can use them like you are used to in Default Values, Constraints and Display Messages. You’ll find the well-known expression builder widget in this configuration as well.

Using expressions

So let’s assume we want to visualize who holds what share of a forest. These forests are owned by the country (national), the canton (cantonal) or private. To keep it simple we have three attributes for that: national_share,cantonal_share and private_share.
After creating the default pie chart you will find this snippet in the QML code text area:

PieSeries {
    id: pieSeries
    PieSlice { label: "First slice"; value: 25 }
    PieSlice { label: "Second slice"; value: 45 }
    PieSlice { label: "Third slice"; value: 30 }
}

Let’s set the field expressions into the PieSlice-values. Just select them in the expression widget and add them with the + into the chart.

As you can see the expressions in the code are wrapped inside expression.evaluate("<expression>"). This means there are no limits in using expressions.
You are open to use more complex expressions like e.g. for the title property of the pie chart:

title: expression.evaluate("CASE WHEN @layer_name LIKE \"forest\" THEN \"Forest\" ELSE @layer_name END")

Or in case the task with forest shares would be solved with relations to other layers by filling up a model with the children and the children’s share. This is possible by using expressions with the help of the expression functionrelation_aggregate.
More information about expressions can be found in the QGIS Documentation.
Back to our example. The result will look like this on the attribute form. It visualizes the share values in the pie chart.

The visualization is not (yet) updated in real time when the values change. But this would be a nice thing to have in the future… If you would like to support this, please contact us.

And that’s it

I hope you liked reading and you will enjoy using it to make beautiful widgets and forms. If you have questions or inputs, feel free to add a comment.
… and in case you still asking where the promised unicorns are. Well you have to wait for the part 2 of this article 😉
 

by David at November 06, 2018 06:30 AM

November 05, 2018

 

 

This post summarizes personal reports of community members who attended the 20th Hackfest in Stone Town, Zanzibar the week before the FOSS4G in Dar Es Salaam.

Report from Matteo Ghetta

QGIS developers spent 3 days in the beautiful island of Zanzibar were they worked on bug fixing, improvement of new features and documentation enhancements. It is extremely important for developers to meet together and spend some days working side by side given that the geographical distribution is very wide.

Thanks to the (local government & Yves Barthelemy) we had the chance to visit the Land Mapping Commission in Stone Town: It has been an amazing experience for both developers and local council. Moreover developers visited the SUZA (University of Zanzibar) and saw the local infrastructure and GIS related workflow.

  • I have merged many PR of the documentation
  • Many old and not old issues have been closed or the author has been pinged
  • Many new additions to the documentation both small corrections and new sections from scratch
  • A new version of DataPlotly released
  • A small presentation of DataPlotly to the QGIS crew

Report from Mario Baranzini

I spent one day of the Hackfest contributing to the SLYR project, improving the conversion of LAB colors. SLYR (https://github.com/nyalldawson/slyr) is a project started and almost entirely developed by Nyall (which was not present to the Hackfest) which aims to provide tools to extract and convert symbols from ESRI .lyr and .style files and use them in QGIS. Nyall has recently worked hard on the project and perhaps soon sponsorship will allow further development.

Around this theme there is a keen interest. Even during the FOSS4G there has been discussion of the conversion of ESRI symbols and there was also a presentation of how the conversion in Israel is currently managed.

During the rest of the hackfest, I worked on the implementation of the new QField file selector.

Report from Denis Rouzaud

Report from Tim Sutton

Firstly let me thank the QGIS project for contributing to my travel and accommodation costs – I am most grateful for the support! This hackfest was special for me because it is the first hackfest in an African country. As an African born person living in the interface between “first world” and “third world”, I have always had a particular social agenda with QGIS: To bring spatial tools to support responsible and sustainable management of our world. There is a huge technological and skills divide between Europe and less developed societies where QGIS can be a valuable social enabler in helping to advance the standard of living and quality of life. Hosting a hackfest in an environment where we don’t have tree cadastres, street furniture cadastres and every aspect of civilian life mapped and systematised is an important way to build empathy and understanding in our QGIS core community members for a broader cross-section of our user base. Having the opportunity to meet with users from ZMI (the Zanzibar Mapping Initiative) and students from the local university was a really uplifting experience. ZMI are building the national cadastre from the ground up using QGIS, PostGIS and UAV mapping. We were privileged to have a number of Zanzibar residents join us on the hackfest and get to experience just how appreciative they are, first hand.

There were a number of interesting topics that arose during the hackfest which I will try to summarise here:

Certification:

We held an extended meeting on the QGIS Certification Programme, mainly detailing how we should go about the review process for onboarding new organisations.

Mac OS Build:

I spent quite a bit of time struggling with my MacOS build on QGIS. It’s definitely an area of the project that needs more work as the process can be non-trivial and the brew based formulas quickly become outdated.

QField Show and Tell:

Matthias showed off the latest version of QField and all the hard work they have been putting into the QGIS mobile client. This Android based version of QGIS for mobile data gathering is a really great project and is getting more and more useful with each release. There was also a translation sprint for QField during which I translated it to Afrikaans.

QField Autobuilds:

Denis and Matthias showed off the work they have done to automate the .apk builds for QField. Their system combines Travis and some git hooks to automatically build .APK’s whenever a pull request os made or a tag is made. See the QField travis for details: https://github.com/opengisch/QField/blob/master/.travis.yml

Plotly plugin:

Matteo Ghetta showed off the latest capabilities of the Data Plotly plugin for QGIS 3. The plugin supports the creation of a wide assortment of charts from your layer’s attribute data. See the plugin homepage here for examples and more detail: https://github.com/ghtmtt/DataPlotly 

Governance:

I took the opportunity to sign off the statute changes from 2017 general meeting. This was my last official act as outgoing project Chair. I was also extremely humbled to be awarded an Honorary PSC membership during the FOSS4G2018 conference.

TimRecievesHonoraryPSCMembership
Easter Eggs:

I contributed a couple of new easter eggs to QGIS. While easter eggs are fun, the data behind these hidden tools provide an important history of the project. I took the opportunity of having many long-time QGIS community members around the dinner table to collate all the previous QGIS meet-up dates. You can view this as a map here: https://github.com/qgis/QGIS/blob/master/resources/data/qgis-hackfests.json 

The spatial clustering of these events shows that going to Zanzibar and getting out of our geographical comfort zone is a really useful endeavour.

Report from Paolo Cavallini

During the HF in Zanzibar I mainly worked on:

  • Plugins: I cleaned up the queue of unapproved plugins, contacting all individual authors, fixing what was possible and deprecating the worst cases; we also solved a long standing issue with a contentious plugin
  • Issues: I examined many tickets, especially those waiting for feedback
  • Training certification: through a very productive meeting we defined clear rules for accepting certifying organizations, with the main aim of driving people to actively support the project:
    • in the application process, the proponent should explain what are his contribution to QGIS project
    • following an initial review, the application will be sent to local QGIS groups for their opinion, which should take place in less than one monthly; where there is no user group, the responsibility will fall entirely on PSC shoulders
    • the training material for each course should be released with a free license, and a review will be done; if the material is not of adequate quality, this is a cause for refusal
    • then PSC will take a decision and publish the contributions as stated by the proponent, for transparency
  • Other meetings helped focusing on our mission, defining the relationship between volunteer and paid work, and other
  • I visited the Land Mapping Commission and the University, soliciting a tighter cooperation with QGIS project.

Report from Admire Nyakudya

During the heck fest in Zanzibar, I mainly worked on porting some common plugin we use to QGIS 3. The plugins I mainly worked on were Cogo Parcel plugin and Sg Diagram downloader. We visited the Zanzibar mapping agency and interacted with the people who were working on capturing cadastral data using QGIS and explained them about the COGO Parcel plugin which streamlines capturing cadastral boundaries in QGIS and storing the results in a PostgreSQL database. To summarise the work I was working on during the heck fest.

  • Port Cogo Plugin from QGIS 2 to make it compatible with QGIS 3. This has been achieved and now awaiting one of my team members to approve the pull request.
  • Expand functionality being offered by the COGO Parcel plugin to include the new reporting framework in QGIS 3.
  • Investigate ways to generate projects on the fly after talking to Matteo and seeing the work he has done with QGIS project generator.

I also went to the Zanzibar university to see ways in which QGIS is being used in the local university and how students are integrating drone imagery with QGIS.

Report from Matthias Kuhn

The highest value of hackfests is actually to meet and greet and discuss ideas and bigger plans. There is a lot of communication on a high bandwidth channel (also known as face-to-face) that strengthens the community. This helps to quickly overcome technical problems sometimes. Or to give someone some tips and tricks you normally wouldn’t come to (e.g. optimizing a git workflow) that results in a long-term gain because of sustainable productivity improvements. I tend to walk around once in a while and just randomly bump into people where I – more or less successfully – try to help them solve their issues or discuss approaches. In the same area, there is the possibility to informally discuss plans about organization, workflows and strategies. The concept of an LTR was to a big degree discussed and built at a hackfest in Essen some years ago. This year there was a very interesting discussion about the topic LTR. For how much time the “long” in the term “long term release” should stand, about the life cycle of releases and of long-term releases. One of the important things when it comes to this question is what organisations think and do – because, in the end, it is mostly for organisations that the LTR exists – and how development resources can be assigned to the task of keeping a high quality of an LTR during its whole lifetime. There are no conclusions yet, but synchronizing on these ideas is often the seed for tomorrow’s exciting changes.

We were also visited by a group of students from the local university. It was really refreshing to talk to them about open source and QGIS and how we work and what the challenges of spatial data and GIS infrastructure are on an island like Zanzibar.

Feature-wise, the main thing I worked on feature wise was a new snap to grid functionality that is available for digitizing tools. It allows configuring a precision for vector layers. Whenever a new node is added or an existing one is edited on this vector layer, it will be automatically placed on this grid. Normally this is used to force the objects on a layer to something like cm or mm resolution.

And then, of course, I did my daily bunch of (mostly volunteer) pull request reviewing, some code cleanup and some bugfixes.

Report from Marco Bernasocchi

https://photos.app.goo.gl/seX2kSJ9vKxKBZt58

The Zanzibar hackfest was a special one for me, my first hackfest as QGIS.org co-chair. My main goal was definitely to get as much information out of Tim as possible so that I wouldn’t have to keep on bugging him all time 🙂

Beside that, multiple meetings where planned to which I took part, as Paolo already explained, we had very good meetings about:

  • Certifications meeting
  • Trademark discussion
  • Creating a membership system that allows entities that are not allowed to budget sponsoring money to instead become paying members.
  • Other meetings helped focusing on our mission, defining the relationship between volunteer and paid work, and other

On the first two days, we were joined by a largish group of local students to whom I explained how the structure of QGIS.org works and where they could help. I also helped them choosing a task to work and mentored them.

As I mentioned before, I spent a lot of time asking a lot of questions to Tim to get the biggest possible knowledge transfer about running QGIS.org and some time choosing and booking restaurants for our evening “meetings”

On the technical side, I worked with Mario on a new implementation of the QField File selector.

After everybody left, the OPENGIS.ch team stayed one day longer and introduced Mario to the real Brighton-style hackfest with take-away pizza 😉

 

by Tim Sutton at November 05, 2018 08:35 PM

The first ‘build’ of the next gvSIG Desktop version for testing is already available. You can download it from the ‘Development versions downloads‘ section of the gvSIG Association website.

With this we encourage you to help us to stabilize the next  gvSIG Desktop 2.5. Mainly we ask you for testing these ‘builds’ during this error fixing phase and you tell us all the incidents that you find at the mailing list.

This first ‘build’ is available with installable distributions for Windows and Linux, and from the first RC (Release Candidate) there will be portable versions, including a distribution for Mac.

gvSIG Desktop 2.5 has a lot of novelties. Not all of them are included at this build (for that it’s not a RC yet). Among the novelties of this new version there are some of them that are remarkable, for example the report designer, the option to work with virtual fields, field importer, quick map exporter/generator, ring map,…

Besides it will integrate all the novelties that were published after 2.4 version. (black icons, option to select and count duplicate values, SIGPAC XML files loading, 3D vector layer into 2D layer conversor, plugin to create forms for gvSIG Mobile, plugin to capture coordinates, integration with gvSIG Mobile, Epanet, The Horton MachineStatistics Viewer, v.4 support of Cadastre GML INSPIRE in Spain and update of several plugins)

In the next weeks we will publish detailed information about the novelties of this version.

We look forward to your collaboration! Time to test!

by Mario at November 05, 2018 01:12 PM

Ya tenemos disponible el primer ‘build’ para testeo de la próxima versión de gvSIG Desktop. Lo podéis descargar desde el apartado de versiones en desarrollo de gvSIG Desktop de la web de la Asociación gvSIG.

Con ello os animamos a que nos ayudéis a estabilizar lo que será el próximo gvSIG Desktop 2.5. Principalmente os pedimos que durante esta fase de corrección de errores probéis estos ‘builds’ y nos vayáis comunicando en la lista de usuarios todas aquellas incidencias que encontréis.

Este primer ‘build’ está disponible con instalables para Windows y Linux, y a partir de la primera RC (Release Candidate – Candidata a final) ya habrá versiones portables, incluyendo una distribución para Mac.

gvSIG Desktop 2.5 viene cargado de novedades. No todas están disponibles en este build (por eso todavía no es una RC). Entre las novedades de esta nueva versión se encuentran algunas tan llamativas como el diseñador de informes, el trabajo con campos virtuales, un importador de campos, exportador/generador rápido de mapas, ring map,…

Además integrará todas las novedades publicadas posteriormente a la versión 2.4. (iconos Black, selección y conteo de duplicados, carga ficheros XML SIGPAC, 3D a 2D, crear formularios para gvSIG Mobile, capturador de coordenadas, integración con gvSIG Mobile, Epanet, The Horton Machine, Visor estadístico, soporte v.4 del GML INSPIRE de Catastro y actualización de varios plugins)

En las próximas semanas iremos publicando información detallada sobre las novedades de esta versión.

¡Esperamos vuestra colaboración! ¡A testear!

by Mario at November 05, 2018 01:12 PM

November 03, 2018

As a software engineer at the Howard Hughes Medical Institute, I work on a collaborative neuron reconstruction and analysis software called CATMAID 1 (screenshot: 3), which is used for neuroscience research. We use PostGIS to represent neurons in a 3D space.

They consist of 3D points that reference their parent nodes or are the root [=soma of neuron] if they have no parent). Together with synapses, point clouds and TIN meshes for modeling compartments in a dataset, they model the spatial aspects of our neuroscience world. Users create those neuron reconstructions manually in a collaborative fashion plus segmentation programs can be used as additional data source. Using its spatial indices, PostGIS helps us to quickly query neurons in a particular field of view. The space of a single project contains sometimes 100s of millions of interconnected individual points. We also do bounding box intersection queries between neurons and compartment meshes, which then refine in the front-end by doing more precise intersection tests.

This software is used by quite a few research labs and as far as I know they all do their own hosting with a dedicated server and this is what we do as well. The reason being mainly that wth larger datasets, we benefit from machines with a lot of RAM (>256G), fast SSD/NVMe drives and many CPUs as well as fast local data access for e.g. image data.

Thanks so much for making PostGIS work well in non-GIS contexts too—-it makes my life much easier!

by Tom Kazimiers at November 03, 2018 12:00 AM

November 02, 2018

Thumb

At the TimeMachine conference, the MapTiler Team introduced the very first application showing maps in augmented reality running from the browser without a need to install any mobile app. No need to have a flagship Apple device, it runs on any mobile phone. Try it now!

Three simple steps to get maps in AR on your phone

Step 1: Open on your phone or tablet: maptiler.com/ar

Step 2: Point your camera at the printed sheet or at the picture below

Step3: Watch the magic!

MapTiler AR marker

The application works entirely with your computer screen, but you will get even better results if you print the sheet (in colors or on a monochrome printer).

In both cases, you will get a map of Venice you can zoom in and work with as with any other map. The date on the top shows the depicted year as the city development progress during the last 1000 years. It is a prototype of the TimeMachine Atlas project, which has been just announced.

The technology behind this application

Our AR app is in the phase of a tech demo for now, but you can already start building your own with our maps from MapTiler Cloud service. It offers global map data in vector format and hosting for own geodata. They can be turned into tiles using MapTiler Desktop and then uploaded to MapTiler Cloud, styled and used in any application with open-source JavaScript libraries or mobile SDKs.

Our current AR app is built around AR.js library, which is an open-source project using WebGL and WebRTC technology. The same code will run in the future also on devices with native AR support (ARCore & ARKit), once they are exposed via WebVR because our code runs directly in a web browser.

We used modified Mapbox GL JS library for displaying the map. Let us know if you are our customer and want to utilize the code in your project.

Try the Augmented Reality on your device now

The AR application runs on every mobile device with a camera using just the web browsers. Try it yourself at maptiler.com/ar!

by Petr Sloup (info@klokantech.com) at November 02, 2018 11:00 AM

Vanguard Appraisals is new to the GIS world. In fact, we aren’t really in the GIS world; we just kind of brush up against it. We do mass property appraisal for entire county and city jurisdictions, and we develop software to collect, price and maintain values. We also host assessment data online so that homeowners can search and find property information much simpler from the comfort of their own home. Our software and websites are used in 7 states (IA, IL, MN, MO, NE, ND, SD).

Continue Reading by clicking title hyperlink ..

by Andy Colson at November 02, 2018 12:00 AM

November 01, 2018

We are pleased to announce the GRASS GIS 7.4.2 release

What’s new in a nutshell

After a bit more than four months of development the new update release GRASS GIS 7.4.2 is available. It provides more than 50 stability fixes and improvements compared to the previous stable version 7.4.1. An overview of the new features in the 7.4 release series is available at New Features in GRASS GIS 7.4.

Efforts have concentrated on making the user experience even better, providing many small, but useful additional functionalities to modules and further improving the graphical user interface. Segmentation now support extremely large raster maps. Dockerfile and Windows support received updates. Also the manual was improved. For a detailed overview, see the list of new features. As a stable release series, 7.4.x enjoys long-term support.

Binaries/Installer download:

Source code download:

More details:

See also our detailed announcement:

About GRASS GIS

The Geographic Resources Analysis Support System (https://grass.osgeo.org/), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities in a single integrated software suite. GRASS GIS includes tools for spatial modeling, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It also provides the capability to produce sophisticated presentation graphics and hardcopy maps. GRASS GIS has been translated into about twenty languages and supports a huge array of data formats. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The GRASS Development Team, October 2018

The post GRASS GIS 7.4.2 released appeared first on GFOSS Blog | GRASS GIS and OSGeo News.

by neteler at November 01, 2018 06:15 PM

October 31, 2018

Todos los interesados en las Infraestructuras de Datos Espaciales tienen ya disponibles las ponencias presentadas en las JIIDE 2018, entre las que hubo una importante presencia de la Asociación gvSIG. Además de un taller en el que mostramos la facilidad de trabajo con gvSIG Online para crear geoportales, se impartieron 3 presentaciones que ya tenéis disponibles para consulta.

Las ponencias presentadas son un claro ejemplo de la madurez y rápida implantación que está teniendo gvSIG Online, en ámbitos tan relevantes como la gestión municipal, las emergencias, la seguridad ciudadana o la agricultura. El software libre ha dejado de ser una alternativa para posicionarse como la tecnología prioritaria en el mundo de las IDE.

Os dejamos los enlaces a nuestras ponencias:

Para cualquier duda que tengáis…o interés en implantar las soluciones gvSIG para poner en marcha vuestras IDE, podéis contactarnos en info@gvsig.com

by Alvaro at October 31, 2018 07:05 PM

This is the fifth progress report of the GDAL SRS barn effort. A lot of activity in PROJ developments has been done this month again.

New conversion and transformation methods referenced in the EPSG database have been integrated:
  • Projection methods: Lambert Conic Conformal (2SP Michigan) and Laborde Oblique Mercator
  • "Change of Vertical Unit", "Vertical offset" and other fixes relative to vertical component handling
  • "Axis order reversal"
  • "Affine parametric transformation", and its implementation in PROJ computation core
  • "Molodensky-Badekas" transformation, and its implementation in PROJ computation core
Regarding database-related activities:
  • Make concatenate operation building from proj.db robust to inverse sub-operations (the EPSG database lists chained operations, but does not indicate if the forward or reverse path must be taken)
  • Reference transformation grids available in the proj-datumgrid-* packages, such as NAD83 -> NAD83(HPGN) grids, OSTN15_NTv2_OSGBtoETRS.gsb
  • Add a celestial_body table and celestial_body property to ellipsoid, as a provision to handle non-Earth bodies
  • Add a text_definition column to geodetic_crs and projected_crs to allow definition by PROJ string (or WKT)
  • Add  the possibility of defining in 'other_transformation' a transformation defined by a PROJ pipeline
  • The createOperations() method that returns transformations between two CRS is now able to find pivot CRS when no direct transformation path exists. One notable fact to underline is that the pivot is not necessarily WGS84, and several candidate pivots are explored. When transforming from CRS A to CRS B, the database will be searched for all CRS C for which there is a referenced transformation from/to both CRS A and CRS B (advanced users may also be able to restrict the candidate(s) pivot to use)
  • Import PROJ.4 definitions contained currently data/IGNF into the database in a relational form. A script to directly use the official registry as the source, instead of the PROJ.4 strings that derive from it, has also been developed but is not used yet.
  • Import of the CRS definitions and transformations between horizontal CRS from the CSV files of the published Esri Projection Engine Database Documentation. The projected CRS are imported with their ESRI WKT definition directly put in the database, so ongoing work is in progress to be able to ingest this WKT1 variant in the WKT2-based form used internally by PROJ.
  • Update the CRS and transformations to EPSG dataset v9.5.4
The addition of the DerivedEngineeringCRS, DerivedParametricCRS and DerivedTemporalCRS classes mark the completion of the implementation of the full ISO-19111:2018 CRS modelling

A rather tedious task has consisted in optimizing the code (mostly by avoiding a lot of unnecessary instanciation of temporary C++ objects, involving looking frequently at disassembled output to locate them) to make the generated binary lighter. This has enabled an optimized build to go down from 3.1 to 2.6 MB

The Doxygen-generated documentation of the C++ API has been integrated with the general PROJ documentation in ReST format, with the Breathe module.

An initial C API that makes part of the C++ functionality available to C users has also been added.

Finally, a RFC has been written to officially submit this work for PROJ PSC approval (doubling the size of a code base and changing its language requirements is not a mundane detail). This RFC has now been officially adopted, and will make it possible to ultimately merge this work into PROJ master. You may skim through it to look at a few examples of the use of the projinfo utility that demonstrates part of the new capabilities developed.

by Even Rouault (noreply@blogger.com) at October 31, 2018 11:17 AM

October 30, 2018

Prezados leitores,

Eu gostaria de compartilhar com vocês que hoje saiu o resultado da Eleição de Membros da OSGeo, na qual fui um dos nomes indicados. Esta é a segunda indicação que recebo para participar da eleição, a primeira aconteceu em 2011.

Para que não conhece a Fundação Geoespacial de Código Aberto (Open Source Geospatial Foundation – OSGeo) é uma organização sem fins lucrativos cuja missão é promover a adoção global de tecnologia geoespacial aberta por ser uma base de software inclusiva dedicada a uma filosofia aberta e desenvolvimento participativo voltado para a comunidade.

Dito isso, quero comunicá-los que hoje me tornei um “OSGeo Charter Member“, e pra mim é uma honra fazer parte do quadro de membros dessa fundação. Gostaria de aproveitar pra agradecer ao Jody Garnett que foi quem lembrou do meu nome e me indicou para a eleição.

by Fernando Quadro at October 30, 2018 04:58 PM

Thumb

The TimeMachine project allows traveling through the time by mapping the last 2000 years of history. The MapTiler Team joins the effort and contributes its know-how in the field of geographical data visualization and building online maps. With a prototype called The Venice Time Machine Atlas for EPFL Lausanne, it shows how historical data and maps can be presented to the broad audience.

TimeMachine project

The TimeMachine project is an educative collaborative effort mapping last 2000 years of history. There are about two hundred institutions involved ranging from museums and archives to high-tech companies working in the field of artificial intelligence and digitization. The MapTiler Team is involved as an expert in the field of modern as well as historical maps.

TimeMachine Atlas prototype

Our prototype of the TimeMachine Atlas is a Map of Venice, which is changing throughout ages - showing the last 1000 year of the city’s development. The demo project is available on the timemachineatlas.eu address.

The geographical data were supplied by university employees and equipped with a time stamp determining building start date and its duration. Technologically, TimeMachine Atlas is a follow up of our previous Roman Empire vector map.

The map is armed with a time slider, which automatically plays the city’s evolution based on historical data or can bring you to your favorite era. Users can compare this map with a modern map, satellite view or two other scanned historical maps. Data are available also in 3D and with additional information about selected buildings like name, time duration and others.

Technical details, collaboration and future

The TimeMachine Atlas technology is powered by our own OpenMapTiles toolset, which is an open-source project for serving vector tiles. It is available at openmaptiles.org and the source code is published under the free BSD / CC-BY license on GitHub.

The suggested data model for future development is based on OpenStreetMap tagging convention with added start_date and end_date tags. Using open- and well-known data format will boost further collaboration on the project. Open data format allows usage of a set of existing tools: e.g., vector tiles can be generated from GIS data (drawn in QGIS, supplied in Shapefiles) and turned into vector tiles for example by the upcoming MapTiler Desktop v10.

The data has no vendor lock-in and can be ported to various environments from which they can be served. Currently, they are hosted on the MapTiler Cloud service, which offers worldwide maps which can be easily customized to fit the old maps’ feeling, hosting for additional geodata and global satellite layer.

The whole project is collaborative, with open-data and open-source community-driven development. We hope that the map will grow with the contributions from other project partners working on time machines in Amsterdam, Budapest, Paris and other cities and countries.

Experience the web application yourself!

The TimeMachine Atlas prototype for Venice is available online at timemachineatlas.eu.

by Petr Pridal (info@klokantech.com) at October 30, 2018 11:00 AM

October 28, 2018

We are pleased to announce the release of QGIS 3.4 ‘Madeira’! Madeira was the location of our developer meeting in February 2018.

Windows installers and Ubuntu/debian binaries are already out, and all the packagers are actively preparing packages for the other operating systems. We’ll keep you updated when different packages and installers become available.

QGIS 3.4 comes with tons of new features, as you can see in our visual changelog.

QGIS 3.4 will become the first LTR of version 3. Based on our current plans, 3.4 will replace 2.18 as LTR in February 2019.

We would like to thank the developers, documenters, testers and all the many folks out there who volunteer their time and effort (or fund people to do so). From the QGIS community we hope you enjoy this release! If you wish to donate time, money or otherwise get involved in making QGIS more awesome, please wander along to qgis.org and lend a hand!

QGIS is supported by donors and sponsors. A current list of donors who have made financial contributions large and small to the project can be seen on our donors list. If you would like to become and official project sponsor, please visit our sponsorship page for details. Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts. A complete list of current sponsors is provided below – our very great thank you to all of our sponsors!

QGIS is Free software and you are under no obligation to pay anything to use it – in fact we want to encourage people far and wide to use it regardless of what your financial or social status is – we believe empowering people with spatial decision making tools will result in a better society for all of humanity.

by underdark at October 28, 2018 12:11 PM

October 25, 2018

Economía y Productividad. Seguro que alguno de vosotros, cuando vio el lema de estas 14as Jornadas Internacionales de gvSIG, pensó…¿y esto de la productividad qué tiene que ver con un proyecto de geomática con software libre? Incluso algún despistado podría pensar que esto son unas jornadas de economía. Y lo son, en cierto modo.

Hasta ahora nuestros lemas destacaban bien la parte más técnica: geolocalizando las TIC, conoce el territorio gestiona la realidad; bien la parte más social, más solidaria del proyecto. Compartiendo el conocimiento, conocer para transformar…es posible, es real. En las 8as Jornadas el lema ‘Tecnología, Solidaridad, Negocio’ ponía el foco en la solidaridad como eje central sobre el que debería girar la ciencia y la economía. Esto sigue siendo así.

Pero con el paso de los años nos hemos encontrado con dos sucesos que van de la mano. Primero, el avance imparable del software libre, de proyectos como gvSIG, que dejan de ser una alternativa a ocupar espacios antes impensables. Hablamos de los grandes proyectos, de trabajar con las grandes organizaciones.

En segundo lugar, la reacción a esto del viejo modelo de especulación con el conocimiento. La reacción del software cerrado o privativo ha pasado por intentar apropiarse del discurso del software libre. Si bien no puede de sus conceptos, lo intenta con las etiquetas. Si no puede con su ética, se apropia de la estética. Más de uno recordará el ‘…is open’, para presentar uno de los software que hace años monopolizaba el mercado.

Pero es que este año, sus conferencias (que casualidad, son estos mismos días), se anunciaban con la frase ‘Comparte tu trabajo. Inspira a la comunidad’.

La verdad es que no deja de resultar curioso. Las jornadas de la compañía de referencia de las soluciones cerradas hablando de compartir y comunidad, y una de las jornadas de soluciones de geomática libre de referencia a nivel internacional hablando de Economía y Productividad.

En un primer vistazo se podría pensar que cada ‘uno’ se quiere acercar a los valores del ‘otro’. Pero si algo nos enseña la ciencia, la Academia (donde estamos), es que debemos ser rigurosos, debemos ir más allá de las etiquetas con las que cada uno nos presentamos, porque eso son los lemas, etiquetas, puestas en escena. Debemos analizar con detalle.

Así que vayamos a las esencias. Aumentemos el nivel de abstracción. Cuando una organización, la que sea, basa gran parte de su modelo de negocio en la venta de licencias, de soluciones cerradas ¿que sentido tiene hablar de compartir? ¿Compartir productos capados que generan dependencia? ¿tecnologías limitadas por la imposibilidad del acceso al conocimiento?

¿Y qué sentido tiene de hablar de inspirar a la Comunidad? Con soluciones cerradas, las Comunidades de las que habla siempre serán comunidades limitadas. ¿Qué se quiere? ¿Inspirar comunidades limitadas?

Ahora situémonos en proyectos libres como los de la Asociación gvSIG. Y que recordemos una vez más si es necesario: Que ser libre no implica menor o mayor calidad de software sino acceso al conocimiento. Derecho de utilización, modificación y distribución.

Y preguntémonos, ¿Cómo se es más productivo? En soluciones que comparten y dan acceso al conocimiento, que se construyen conjuntamente, que permiten invertir sólo en aquello que necesitamos, que impulsan empresas locales expertas en tecnología, que permiten reutilizar, que nos hacen soberanos en la toma de decisiones, que reducen asimetrías o en productos que nos limitan, que especulan con el conocimiento, que generan gasto, que nos hacen dependientes de proveedores únicos que determinan nuestro futuro tecnológico, única y exclusivamente, en base a sus políticas comerciales.

Echemos un vistazo a las realidades que se van a presentar en estas jornadas, a los talleres, aplicaciones a sectores tan relevantes como la agricultura o el medio ambiente, tan críticos como la seguridad y la protección civil. Miremos los proyectos que se han presentado durante estos 14 años de jornadas internacionales que llevamos en Valencia (y en tantas otras, unas 50, en Francia, Alemania, Italia, Rusia, México, Argentina, Brasil, Uruguay, Venezuela, Paraguay, Perú y Chile ) y todo a pesar del estigma y las falsedades que se han querido hacer contra las soluciones libres, contra proyectos como el propio gvSIG. ¿Podemos hablar de economía y productividad?

No sólo podemos sino que debemos empezar a reivindicar el impacto que tiene la adopción de proyectos de software libre como gvSIG en la economía, en la productividad. Si el foco lo centramos ahí. Si conseguimos esto, entonces se podrán generar cambios de mayor calado, a nivel estructural.

Y aquí lo dejamos…

Bienvenidos a todas y todos a las 14as Jornadas Internacionales de gvSIG.

by Alvaro at October 25, 2018 06:03 PM

Hoje veremos como é possível aumentar a performance de sua consulta espacial com join, de uma maneira de certa forma “estranha”. Para este teste de desempenho com o PostGIS onde queremos saber quantos pontos estão dentro de cada polígono, temos: Uma coleção de polígonos de tamanhos variáveis ​​e uma coleção de pontos.

Esse teste é uma boa maneira de testar indexação, cálculos de pontos em polígonos e sobrecarga geral.

1. Configuração

Primeiro baixe alguns polígonos e alguns pontos:

Países
Lugares

Carregue os shapefiles em seu banco de dados:

shp2pgsql -s 4326 -D -I ne_10m_admin_0_countries.shp countries | psql performance
shp2pgsql -s 4326 -D -I ne_10m_populated_places.shp places | psql performance

Agora estamos prontos com 255 países e 7343 lugares.

Uma coisa a notar sobre os países é que eles são objetos bastante grandes, com 149 deles tendo vértices suficientes para serem armazenados em tuplas TOAST.

SELECT count(*) 
  FROM countries 
  WHERE ST_NPoints(geom) > (8192 / 16);

2. Desempenho de baseline

Agora podemos executar o teste de desempenho de baseline.

SELECT count(*), c.name 
  FROM countries c 
  JOIN places p 
  ON ST_Intersects(c.geom, p.geom) 
  GROUP BY c.name;

Essa consulta levou 25 segundos. Se você colocar o processo em um profiler enquanto o executa, descobrirá que mais de 20 segundos são gastos na função pglz_decompress, e não fazendo algoritmos espaciais ou geometria computacional, apenas descomprimindo a geometria antes de entregá-la ao processamento real.

Porém, existem maneiras inteligentes de evitar essa sobrecarga:

  • Correção do PostgreSQL para permitir a descompactação parcial de geometrias.
  • No formato de serialização incluir uma chave hash exclusiva na frente das geometrias.

Essas são maneiras legais de manter a compactação para geometrias grandes e ser mais rápido ao alimentá-las.

No entanto, eles ignoram uma abordagem mais brutal e facilmente testável para evitar a descompressão: apenas não comprimem em primeiro lugar.

3. Um truque estranho

O PostGIS usa a opção de armazenamento “principal” para seu tipo de geometria. A opção principal tenta manter as geometrias na tabela original até que elas fiquem muito grandes, depois as compacta e as move para TOAST.

Existe outra opção “externa” que mantém as geometrias, e se elas ficarem muito grandes, são movidas para TOAST descomprimidas. O PostgreSQL permite que você altere o armazenamento em colunas em tempo de execução, portanto não é necessário hackear ou codificar para tentar isso.

-- Altere o tipo do storage
ALTER TABLE countries
  ALTER COLUMN geom
  SET STORAGE EXTERNAL;

-- Force a reescrita da coluna
UPDATE countries
  SET geom = ST_SetSRID(geom, 4326);

-- Execute novamente a query  
SELECT count(*), c.name 
  FROM countries c 
  JOIN places p 
  ON ST_Intersects(c.geom, p.geom) 
  GROUP BY c.name;

A junção espacial agora é executada em menos de 4 segundos .

Qual é a penalidade?

  • Com um armazenamento “principal” a tabela + toast + index é de 6MB.
  • Com um armazenamento “externo” a tabela + toast + index é de 9MB.

4. Conclusão

Para uma penalidade de armazenamento de 50%, em uma tabela que possui objetos muito maiores do que a maioria das tabelas espaciais, alcançamos uma melhoria de desempenho de 500%. Talvez não devêssemos aplicar compressão à nossa geometria?

Usar o armazenamento “principal” foi principalmente uma chamada de julgamento quando decidimos, não foi aferido nem nada – é possível que estivéssemos errados. Além disso, apenas objetos grandes são compactados; uma vez que a maioria das tabelas é cheia de pequenos objetos (linhas curtas, pontos), mudar para “externo” por padrão não teria qualquer efeito no tamanho do armazenamento.

Este post foi traduzido e adaptado livremente do post originalmente escrito por Paul Ramsey, do blog CleverElephant.

Fonte: Blog CleverElephant

by Fernando Quadro at October 25, 2018 10:30 AM

October 24, 2018

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

by Fernando Quadro at October 24, 2018 10:30 AM

October 23, 2018

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

by Fernando Quadro at October 23, 2018 10:30 AM

October 22, 2018

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

by Fernando Quadro at October 22, 2018 10:30 AM

October 20, 2018

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.

October 20, 2018 08:31 PM

October 19, 2018

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:

by Alvaro at October 19, 2018 08:10 AM