Welcome to Planet OSGeo

July 16, 2019

Prezados Leitores,

Nesta quinta-feira, dia 18/07 as 22h, acontecerá uma Live no canal do YouTube GeoCast denominada “Precisamos falar de PyQGIS”. Ela é uma iniciativa dos amigos Kyle Felipe e Felipe Sodré Barros, que iniciarão um grupo de estudos sobre o PyQGIS.

Se você tem interesse em aprender um pouco sobre essa integração da linguagem Python com o QGIS, não perca esta primeira live, nela serão dadas informações detalhadas de como será o grupo, a periodicidade entre outros detalhes.

Você se interessou? Então não perca a Live do dia 18.



by Fernando Quadro at July 16, 2019 12:08 PM

El 25 y 26 de noviembre tendrá lugar el II Congreso Internacional JUST SIDE (Justicia y Sostenibilidad en el Territorio a través de Sistemas de Infraestructuras de Datos Espaciales), bajo el lema “Complex Social Systems. Geodata Integration in Law and Policy”. Este congreso, organizado por la Red iberoamericana JUST Side, tendrá en esta ocasión como sede la Universidad de Coimbra, tras haber sido celebrada la primera edición en Montevideo (Uruguay). La Asociación gvSIG, como miembro de la Red tendrá una presencia activa en el congreso.

El Congreso tiene como objetivo profundizar y compartir conocimiento alrededor del concepto de Geoderecho, que combina el análisis jurídico de los datos territoriales, ambientales y sociales a partir del uso de herramientas y metodologías de análisis espacial, a fin de obtener información sobre injusticias socio-ambientales que pueda servir como base científica para la adopción o corrección de políticas públicas. La geomática en software libre como herramienta para apoyar la toma de decisiones, para promover y fortalecer las políticas públicas, para hacer frente a los desafíos sociales, ambientales, económicos, jurídicos y democráticos.

El llamado a ponencias está abierto hasta el 15 de septiembre. Se pueden enviar las propuestas al correo just.side@ij.uc.pt. Los resúmenes deben tener un máximo de 1.200 palabras y pueden ser redactados en Castellano, Portugués o Inglés. Todas las propuestas aceptadas tendrán su correspondiente publicación ISBN.

 

by Alvaro at July 16, 2019 07:25 AM

July 15, 2019

And now for the final chapter in the saga of improving InteriorPoint / PointOnSurface.  For those who missed the first two episodes, the series began with a new approach for the venerable JTS Geometry.interiorPoint() for polygons algorithm.  Episode 2 travelled deep into the wilds of C++ with a port to GEOS.  The series finale shows how this results in greatly improved performance of PostGIS ST_PointOnSurface.

The BC Voting Area dataset is a convenient test case, since it has lots of large polygons (shown here with interior points computed).
The query is about as simple as it gets:

   select ST_PointOnSurface(geom) from ebc.voting_area;

Here's the query timings comparison, using the improved GEOS code and the previous implementation:

Data sizeTimeTime
OLD
ImprovementTime
ST_Centroid
5,658 polygons
(2,171,676 vertices)
341 ms4,613 msx 13369 ms

As expected, there is a dramatic improvement in performance.  The improved ST_PointOnSurface runs 13 times faster than the old code.  And it's now as fast as ST_Centroid.  It's also more robust and tolerant of invalid input (although this test doesn't show it).

This should show up in PostGIS in the fall release (PostGIS 3 / GEOS 3.8).

On to the next improvement... (and also gotta update the docs and the tutorial!)

by Dr JTS (noreply@blogger.com) at July 15, 2019 05:53 AM

July 12, 2019

We are officially on the fast lane of preparations and with every day that passes, new and exciting pieces receive their perfect spot in the puzzle. Some pieces are strikingly visible, some are less, but together they will come to be your FOSS4G2019.

With great pleasure we announce that today the FOSS4G2019 puzzle has received a new palpable, important piece: the detailed schedule! Preparing it was not an easy task, yet it was one of the most enjoyable ones! By reading through all the accepted abstracts in order to identify the most appropriate slot for each one, we could grasp the maturity and coherence, yet dynamicity and progressiveness of the open source geospatial fully developed ecosystem. We are confident that we have succeeded in transposing this in the 11 parallel tracks, one of which is, of course, the academic track .

For those of you that crave for a closer, more in-depth and hands-on study into the entrails of the open source ecosystem, make your choice out of the 44 workshops and 6 labs on display.

Beyond doubt, the global FOSS4G has become the must-attend event for all geospatial professionals, novices, students, professors or researchers, be they developers, users, entrepreneurs, open source evangelists or proprietary software believers, geographers or mathematicians, geologists or computer scientists, oceanographers or land surveyors. Within the 11 tracks of FOSS4G2019 Bucharest one can find each and every single category, yet, true valuable progress resides in all of us standing shoulder to shoulder, looking in the same direction and bringing all our contributions to compose the geospatial role in making our world a better place. Let us all stand shoulder to shoulder and listen to the inspiring keynote speakers of FOSS4G2019 Bucharest! With years of experience in various backgrounds, knowledge and goodwill they envision the geospatial directions of progress and, in August 2019, they come from all across the world to share their vision with us!

We invite you to browse the FOSS4G2019 Bucharest detailed schedule and construct your preliminary trajectory throughout the most awaited geospatial conference of the year using the interactive features from presentation, workshop and lab pages.

Haven’t registered yet? We strongly advise that you do, as it’s best to secure your place at the coolest geospatial event of the year!

by Vasile Crăciunescu at July 12, 2019 03:03 PM

July 11, 2019

A interação com os usuários do nosso programa gvSIG é primordial e qualquer novo canal de comunicação é sempre bem vindo. A Associação gvSIG segue disponibilizando o uso das listas de discussão como principal forma de contato com os usuários, quer seja pelo grande número de usuários, quer seja pelo histórico que fica disponível a todos. No entanto, um chat pode ser um canal de interação que pode ser interessante em muitos momentos e situações, e que pode perfeitamente complementar as formas de contato dos usuários com o time do gvSIG.

Baseados na sugestão do usuário do twitter @ideaplusgeo (alterego desse que vos fala), a Associação gvSIG resolveu criar um novo grupo no Telegram, destinado ao gvSIG Suite. O grupo é aberto a qualquer pessoa que queira participar, e será um prazer contar com a sua presença. Nesse grupo já estão participando os membros da Associação gvSIG, usuários e desenvolvedores.

Aproveitando este fato, estamos abrindo também um grupo no Telegram voltado para os usuários de língua portuguesa, o grupo gvSIG Brasil, um espaço para compartilharmos dicas, tutoriais, links, dúvidas, entre outros assuntos relacionados ao gvSIG, em português.  Esse espaço vem se somar ao grupo gvSIG Brasil no Facebook, no qual você também é convidado a participar.

Se você é um usuário e/ou desenvolvedor, ou ainda, quer conhecer mais sobre esse excelente SIG, aproveite e venha participar de nossas comunidades!

by eliazerk at July 11, 2019 06:16 AM

July 10, 2019

Les modules sur gvSIG Online du cours gratuit sur les systèmes d’information géographiques appliqués à la gestion des municipalités sont maintenant disponibles.

gvSIG Online est une solution intégrale en logiciel libre pour gérer l’information spatiale d’une entreprise en suivant le modèle des IDS (Infrastructures de données spatiales).

Avec gvSIG Online, un conseil municipal peut organiser son information géographique de la façon la plus efficace possible, en ayant différents outils, aussi bien pour générer des cartes que pour gérer la base de données spatiales de l’organisation, mais aussi parier sur des technologies gratuites pour garantir leur indépendance technologique.

Une IDS permet d’organiser toute l’information géographique, en facilitant sa location et son accès en temps réel, en évitant la duplication et l’information, en résolvant le problème d’accès à l’information mise à jour et en permettant l’interopérabilité avec l’information géographique aussi bien en interne qu’avec d’autres entreprises.

Dans ces modules, vous ne pourrez pas effectuer directement les exercices, car une mise en oeuvre de la plateforme est nécessaire, mais vous pourrez ce qui peut être fait avec gvSIG Online.

Si vous êtes intéressé(e) pour une mise en oeuvre de gvSIG Online dans votre municipalité, ou dans n’importe quel type d’organisation, vous pouvez nous contacter en nous écrivant à l’adresse : info@gvsig.com, et nous vous donnerons plus d’informations à ce sujet.

Nous publierons dans le courant de la semaine prochaine le module sur gvSIG Mobile. Le certificat sera disponible quand ce module aura été publié.

Pour suivre ce cours, aucune inscription n’est nécessaire, vous n’avez qu’à suivre les vidéo-tutoriaux. Vous trouverez une section “questions fréquentes” au premier post de ce cours, avec toutes les informations importantes.

Modules:

Module 16.1: gvSIG Online (Publier une cartographie)

Lors de ce module, vous pouvez voir comment connecter gvSIG Desktop et gvSIG Online, comment effectuer une édition sur l’application et publier cette information géographique.

Module 16.2: gvSIG Online (Edition basique)

Lors de ce module, nous allons voir comment créer et charger de nouvelles couches dans gvSIG Online, et comment marchent les outils d’édition basiques disponibles dans gvSIG Online. De plus nous allons expliquer comment télécharger de nouveaux shapefiles sur tous les pays du mone, pour effectuer de nouvelles opérations dans gvSIG Online, mais aussi dans gvSIG Desktop.

Autres modules:

by Mario at July 10, 2019 11:25 AM

GeoNode 2.10 Released

The GeoNode dev team is proud to announce the release of GeoNode 2.10 stable!

GeoNode 2.10 ships a lot of new features:

  • MapStore2 Client v1.3.1
  • Release Changelog
  • Updated to Django 1.11+
  • Updated to GeoServer 2.14.3
  • Updated pycsw to 2.4.0
  • Updated Celery to 4.2.1

and a lot of fixes and code refactoring from 2.8 Release.

Don't upgrade before backing up your data!

There are a lot of internal changes from version 2.8 to 2.10

Installation Instructions

Installation Guides

Getting support

You can report any issues or feature requests in our Issue Tracker in Github.

And a big thank you to all the developers and contributors for the big effort. See you in our Users mailing list

July 10, 2019 12:00 AM

July 09, 2019

Como muchos de ustedes ya sabrán GeoForAll es una red de promoción de la ciencia geoespacial abierta que fomenta el intercambio y la cooperación mutua entre sus integrantes, a través de actividades de capacitación, intercambio académico, difusión, disponibilidad de materiales didácticos, elaboración de proyectos conjuntos, entre otras. Sus principios fundamentales incluyen: software libre y abierto, estándares abiertos, datos abiertos, recursos educativos abiertos, y acceso libre a publicaciones de investigación.

geoforallC

Tratando de honrar estos principios hemos realizado un taller sobre SIG básico con gvSIG como una de las actividades de IASC 2019 (XVII Conferencia Bienal IASC, titulada “En defensa de los comunes: Desafíos, Innovación y Acción”, Lima -Perú- del 01 al 05 de julio del 2019). El taller formó parte de las actividades previas a la Conferencia, desarrollándose el día viernes 28 de junio. Se realizó en modalidad de video-conferencia (instructor remoto -en Uruguay- y asistentes en aula, con apoyo de instructor en el lugar).

IMG_9778

Es trascendental destacar la importancia de expandir las sinergias y colaboraciones con la comunidad IASC (Asociación Internacional para el Estudio de los Bienes Comunes). En este sentido es que entendemos esta actividad es sólo una de muchas que seguramente se concretarán en el futuro.

IMG_4554

Tal como prometimos ponemos ahora a disposición de toda la Comunidad los materiales, guías y video-tutoriales de este taller de manera que cualquiera que quiera podrá reproducir lo realizado en el mismo.

En este enlace podrán descargar la carpeta ACTIVIDAD, la que contiene:

  • ​8 archivos
    • ​​4 archivos .zip que corresponden a las 4 capas de información geográfica (IG) descargadas del sitio de NaturalEarth y que se utilizan en el taller (países del mundo, sus divisiones administrativas de primer orden, los bordes continentales y los principales centros poblados del mundo); al descomprimirlos se generan las 4 carpetas que también están en esta carpeta ACTIVIDAD y que tienen igual nombre
    • 2 archivos pdf correspondientes a las guías del taller
      • ​​una guía pre-taller, que explica cómo buscar y descargar IG de internet (los 4 archivos que se mencionan antes), cómo descargar y ejecutar gvSIG, y cómo deplegar la IG descargada en gvSIG; la guía finaliza explicando cómo guardar lo realizado, creando un proyecto de gvSIG que es con el que parte el taller propiamente dicho
      • la guía del taller, donde se explica en detalle todo lo realizado durante el mismo
    • ​una planilla (HDI.dbf) necesaria para uno de los ejercicios
    • el archivo gvsproj. que se crea siguiendo las instrucciones de la guía mencionada anteriormente (en caso de que al querer abrir este archivo no encuentre las capas, preguntará dónde hallarlas; solamente habrá que cargarlas desde las carpetas que se encuentran en esta misma carpeta y que se describen a continuación)
  • 5 carpetas
    • ​4 carpetas, producto de descomprimir los archivos .zip que contienen las capas de IG que se utilizan en este taller; cada carpeta contiene 7 archivos, 5 de los cuales corresponden a la IG propiamente dicha -el shapefile- y los 2 restantes a información de esta IG
    • una carpeta “MAPA DE CALOR” que contiene las 3 capas de IG necesarias para ejercicios del taller

En este enlace podrán acceder a la lista de reproducción de los video-tutoriales de lo realizado en el taller, explicando paso a paso todo el proceso: desde la búsqueda y descarga de IG hasta la creación de un mapa para compartir o imprimir.

IMG_20190628_143059

Quisiéramos agradecer a los organizadores de IASC 2019 por permitirnos la oportunidad de compartir esta instancia de capacitación. También agradecer a Marino Carhuapoma quien ofició de instructor de apoyo en el lugar. Y muy especialmente nuestro agradecimiento hacia Charlie Schweik (University of Massachusetts Amherst) quien hizo posible que esto sucediera.

by Sergio Acosta y Lara at July 09, 2019 03:38 PM

July 08, 2019

July 07, 2019

In the past, network analysis capabilities in QGIS were rather limited or not straight-forward to use. This has changed! In QGIS 3.x, we now have a wide range of network analysis tools, both for use case where you want to use your own network data, as well as use cases where you don’t have access to appropriate data or just prefer to use an existing service.

This blog post aims to provide an overview of the options:

  1. Based on local network data
    1. Default QGIS Processing network analysis tools
    2. QNEAT3 plugin
  2. Based on web services
    1. Hqgis plugin (HERE)
    2. ORS Tools plugin (openrouteservice.org)
    3. TravelTime platform plugin (TravelTime platform)

All five options provide Processing toolbox integration but not at the same level.

If you are a regular reader of this blog, you’re probably also aware of the pgRoutingLayer plugin. However, I’m not including it in this list due to its dependency on PostGIS and its pgRouting extension.

Processing network analysis tools

The default Processing network analysis tools are provided out of the box. They provide functionality to compute least cost paths and service areas (distance or time) based on your own network data. Inputs can be individual points or layers of points:

The service area tools return reachable edges and / or nodes rather than a service area polygon:

QNEAT3 plugin

The QNEAT3 (short for Qgis Network Analysis Toolbox 3) Plugin aims to provide sophisticated QGIS Processing-Toolbox algorithms in the field of network analysis. QNEAT3 is integrated in the QGIS3 Processing Framework. It offers algorithms that range from simple shortest path solving to more complex tasks like Iso-Area (aka service areas, accessibility polygons) and OD-Matrix (Origin-Destination-Matrix) computation.

QNEAT3 is an alternative for use case where you want to use your own network data.

For more details see the QNEAT3 documentation at: https://root676.github.io/index.html

Hqgis plugin

Access the HERE API from inside QGIS using your own HERE-API key. Currently supports Geocoding, Routing, POI-search and isochrone analysis.

Hqgis currently does not expose all its functionality to the Processing toolbox:

Instead, the full set of functionality is provided through the plugin GUI:

This plugin requires a HERE API key.

ORS Tools plugin

ORS Tools provides access to most of the functions of openrouteservice.org, based on OpenStreetMap. The tool set includes routing, isochrones and matrix calculations, either interactive in the map canvas or from point files within the processing framework. Extensive attributes are set for output files, incl. duration, length and start/end locations.

ORS Tools is based on OSM data. However, using this plugin still requires an openrouteservice.org API key.

TravelTime platform plugin

This plugin adds a toolbar and processing algorithms allowing to query the TravelTime platform API directly from QGIS. The TravelTime platform API allows to obtain polygons based on actual travel time using several transport modes rather, allowing for much more accurate results than simple distance calculations.

The TravelTime platform plugin requires a TravelTime platform API key.

For more details see: https://blog.traveltimeplatform.com/isochrone-qgis-plugin-traveltime

by underdark at July 07, 2019 09:46 AM

July 03, 2019

Prezados leitores,

Neste post falei um pouco sobre alguns projetos de Big Data e Data Science que estão sendo realizados em Nova York pela equipe da CARTO, empresa referência global em GIS, com base em metodologias que tem sido muito estudadas na academia e colocados em prática no mercado.

Sage Research Methods é o melhor guia de métodos, fornecendo mais de 1000 livros de alta qualidade, obras de referência, artigos de periódicos e vídeos instrucionais que mostram as metodologias de pesquisa de acadêmicos e especialistas de todo o mundo.

No outono passado, eles se juntaram a CARTO na sua sede em Nova York para trabalhar junto com sua equipe de ciência de dados na criação de guias de vídeo, seguindo passo a passo as pesquisas realizadas e o processo por trás de dois de seus mais recentes projetos de dados espaciais.

1. Entendendo o uso de parques públicos de NYC com a ciência de dados espaciais

Neste projeto, os cientistas de dados visualizaram e analisaram mais de um milhão de pontos de dados anônimos de GPS móveis e dados abertos (open data) do Departamento de Parques e Recreação de Nova York. Isso os permitiu analisar especificamente como as pessoas passam o tempo e interagem com outras pessoas nos parques públicos da cidade de Nova York. Esse tipo de detalhe pode ajudar a criar regulamentos, políticas de parques, projetos futuros e muito mais.

2. Usando a Ciência de Dados para melhorar as vendas de Food Trucks

Os avanços na Inteligência de Localização e na ciência de dados espaciais continuam a transformar as práticas de negócios e os processos de tomada de decisões de negócios, e o planejamento do local é um exemplo importante dessa mudança. Com insights de novos fluxos de dados, é possível determinar quais sites têm maior probabilidade de aumentar as vendas para empresas sazonais, temporárias e móveis.

Neste projeto a equipe de ciência de dados trabalhou com um mês de dados anônimos de transações para cada um dos 10 food trucks. Usando essas informações, eles puderam avaliar o desempenho atual, criar modelos de receita cada vez mais confiantes e, finalmente, prever os seis locais de food truck com melhor desempenho para futuras operações na cidade de Nova York.

Fonte: CARTO Blog

by Fernando Quadro at July 03, 2019 01:46 PM

July 02, 2019

O mapa da roda é um mapa para lugares acessíveis a cadeiras de rodas. Através do site, qualquer pessoa pode facilmente encontrar, registrar e avaliar lugares em todo o mundo.

O projeto, que está disponível desde 2010, foi concebido para ajudar usuários de cadeira de rodas e pessoas com outras deficiências de mobilidade a planejar seu dia de uma maneira mais previsível.

Atualmente, mais de 900.000 cafés, bibliotecas e muitos outros locais públicos estão registrados. Todos os dias, mais de 300 novas locais são adicionadas. O Wheelmap também está disponível como um aplicativo gratuito para iPhone, Android e Windows Phone. Assim, o mapa pode ser convenientemente usado na estrada através do smartphone.

Wheelmap.org é um projeto dos HERÓIS SOCIAIS, um grupo de jovens dedicados que trabalham juntos para desenvolver projetos criativos desde 2004, para conscientizar e, na melhor das hipóteses, eliminar problemas sociais.

by Fernando Quadro at July 02, 2019 01:25 PM

July 01, 2019

June 30, 2019

We are extremely pleased to announce the winning proposals for our 2019 QGIS.ORG grant programme. Funding for the programme was sourced by you, our project donors and sponsorsNote: For more context surrounding our grant programme, please see: QGIS Grants #4: Call for Grant Proposals 2019.

The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. For the first time, this year we did not accept proposals for the development of new features. Instead proposals should focus on infrastructure improvements and polishing of existing features.

Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 of the 10 submitted proposals by means of a ranked selection form. The full list of votes are available here (on the first sheet). The second sheet contains the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:

A couple of extra notes about the voting process:

  • The PSC has an ongoing program to fund documentation so elected to fund the proposal “Open documentation issues for pull requests” even if this increases the total funded amount beyond the initial budget.
  • Although the budget for the grant programme was €20,000, the total amount for the winning proposals is €22,200. This increase is possible thanks to the generous support by our donors and sponsors this year.
  • Voting was carried out based on the technical merits of the proposals and the competency of the applicants to execute on these proposals.
  • No restrictions were in place in terms of how many proposals could be submitted per person / organization, or how many proposals could be awarded to each proposing person / organization.
  • Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We received 31 votes from 16 community representatives and 15 user group representatives.

On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!

A number of interesting and useful proposal didn’t make it because of our limited budget; we encourage organizations to pick up one of their choice and sponsor it.

by underdark at June 30, 2019 08:12 PM

June 28, 2019

We are pleased to announce the release of GeoServer 2.15.2 with downloads (zip|war), documentation (html) and extensions.

This is a stable release recommended for production. This release is made in conjunction with GeoTools 21.2 and GeoWebCache 1.15.2. Thanks to everyone who contributed to this release.

For more information see the GeoServer 2.15.2 release notes.

Improvements and Fixes

This release includes a number of fixes and improvements, including:

  • Upgrade jackson to 2.9.9
  • Upgrade spring-security-oauth2 version from 2.0.11 to 2.0.16
  • Parameter Extractor plugin cannot mangle URL correctly if Monitor plugin is installed
  • Fix warning message “Unable to find property ‘format.wfs.DXF’ for preview component”
  • Integrated GWC fails to seed layers if any data security is configured
  • WCS 2.0 scaling policies do not account for scaling factor already applied during read (due to subsampling and overview)
  • Unresolvable Spring circular reference on Solr module
  • REST exception handler and controllers do not always set the response content type
  • Advanced Projection Handling can generate vertical gaps in output images when reprojecting
  • Parameter Extractor plugin prevents the Monitor plugin to log requests
  • WMTS multidimensional, support bboxes spanning the dateline

About GeoServer 2.15 Series

Additional information on the 2.15 series:

Java 11 comparability is the result of a successful code-sprint. Thanks to participating organizations (BoundlessGeoSolutionsGeoCatAstun TechnologyCCRi) and sprint sponsors (Gaia3Datolosgeo:ukAstun Technology).

by tbarsballe at June 28, 2019 09:32 PM

June 27, 2019

Contact with users of our software is essential and any new channel to be in contact is welcome. In the gvSIG Association we continue supporting mailing lists use because they reach a large number of users and mails are recorded in a archive service, but we understand that a chat can sometimes be more useful for certain type of conversations.

Following the proposal of one of the gvSIG users on Twitter, @ideaplusgeo, we have decided to create a new Telegram group dedicated to gvSIG Suite. The channel is open to anyone who wants to use it, we will be happy to be closer to you. In this channel there will be members of the gvSIG Association as well as users and developers of the gvSIG Suite. Feel free to talk about the topics that are interesting for you. Welcome!

by Mario at June 27, 2019 03:53 PM

El contacto con los usuarios de nuestro software es algo primordial y cualquier nuevo canal de comunicación para estar en contacto es bienvenido. En la Asociación gvSIG seguimos apoyando el uso de las Listas de correo ya que llegan a un gran número de usuarios y queda constancia de ellas en un historial, pero entendemos que un chat a veces puede ser de mayor utilidad para cierto tipo de  conversaciones.

A raíz de la consulta de uno de los usuarios de gvSIG en Twitter @ideaplusgeo, hemos decidido abrir un nuevo grupo de Telegram dedicado a gvSIG Suite. El grupo es abierto para cualquiera que lo desee, estaremos encantados de teneros un poco más cerca. En este grupo estaremos desde miembros de la Asociación gvSIG, hasta usuarios o desarrolladores. Sentiros libres de hablar de los temas que os interesen. ¡Bienvenidos!

by Óscar Martínez at June 27, 2019 03:08 PM

June 26, 2019

June 25, 2019

Después del primer Geobloggers celebrado en Valencia en 2017, llega el segundo encuentro de los apasionados de los Sistemas de Información Geográfica y ciencias afines para hablar del mundo y entorno GEO y desde la Asociación gvSIG no podíamos faltar a la cita.

Tal y como informan desde la organización del evento, este segundo encuentro se plantea bajo la pregunta ¿HACIA DÓNDE VAMOS? y reunirá destacados ponentes del muy diversos ámbitos GEO (ahí estamos nosotros!!), que nos darán su particular visión de lo que puede acontecer en los próximos años y cuál será el perfil de los futuros profesionales que trabajen en estas áreas.

Fecha: 27 de junio. El evento se desarrollará en la Escuela Técnica Superior de Ingenieros en Topografía, Geodesia y cartografía de la Universidad Politécnica de Madrid.

Se podrá seguir el II encuentro mediante streaming,  en la página Facebook de la ETS de Ingenieros en Topografía , Geodesia y Cartografía de la UPM (@ETSITopografia). El evento será gratuito y para asistir como espectador te puedes apuntar en el siguiente enlace: FORMULARIO DE INSCRIPCIÓN

Con todas las presentaciones entregadas, se realizará un especial en la Revista Internacional MAPPING.

A todos los asistentes se les regalará la suscripción en formato digital de la revista.


PROGRAMA

9:00-9:20 Apertura del II Encuentro a cargo del Director de la Escuela JESÚS VELASCO.

9:20-9:45 JUAN TORO. GeoBlogger Interés por la Geomática. ROBERTO MATELLANES FERRERAS. GeoBlogger GIS & BEER. GERSÓN BELTRÁN LÓPEZ. Geomarketing Strategist & CMO en Play&go experience

9:45-10:10 ROBERTO RODRÍGUEZ SOLANO. ETS de Montes, Forestales y del Medio Natural, UPM.

10:10-10:25 ANA DOMINGO PRECIADO. RRSS Geomática UPM.

10:25-10:50 BELÉN SORIA. Senior Community Analyst Lead HERE MAP. Blog Here map.

10:50-11:15 ANTONIO FEDERICO R. PASCUAL. GeoBlogger Blogg IDEE

11:15-11:45 Pausa Café

11:45-12:10 PALOMA VERDEJO HERRERAS. Senior Consultant Indra. GeoBlogger Mundogeomática.

12:10-12:35 SERGIO DOMENECH ZUECO. Solution Egineer Esri España. Blog Esri.

12:35-13:00 ÁLVARO ANGUIX. Director General Asociación gvSIG. Blog gvSIG.

13:00-13:25 GORGI ÁLVAREZ. GeoBlogger Geofumadas

13:25-13:30 Comunicado convocatoria 2021 y Final Acto

 

by Alvaro at June 25, 2019 02:10 PM

Quando trabalhamos com visualização de dados espaciais, sempre buscamos facilitar a leitura do nosso mapa. E isso é obtido por meio da escolha dos símbolos mais adequados para representar nossos dados.

Dessa forma, nesta postagem, vamos explorar as opções que o QGIS 3.4 apresenta para mostrar nossos dados.

Embora a postagem tenha sido criada usando o QGIS 3.4, é possível aplicar as opções apresentadas em qualquer versão do QGIS, exceto aquelas que foram implementadas na versão 3.

Iremos mostrar as possíveis representações utilizando o shapefile das Áreas Contaminadas e Reabilidadas do estado de Minas Gerais. Esses dados podem ser baixados no site do Instituto Pristino.

Para modificar a simbologia de um shapefile, você deverá adicioná-lo ao QGIS, e na lista de camadas, clicar sobre ele e selecionar Propriedades. Na janela que será aberta, seleciona a guia Simbologia.

Como acessar o menu simbologia no QGISClique sobre o shapefile e selecione Propriedades para acessar o menu Simbologia.

Na janela de Simbologia, temos vários menus que podem ser acessados clicando sobre eles. A imagem a seguir mostra eles e em seguida, apresentamos uma descrição das possibilidades de cada um deles. Obviamente, conforme o tipo de feição (ponto, linha ou polígono), as opções de simbologia irão variar (mas de modo geral, elas são similares).

Menu Simbologia do QGISMenu Simbologia do QGIS

No menu de simbologia do QGIS (1) você encontrará diferentes opções para representar seus dados. No primeiro menu (2) você definirá como seus dados serão apresentados conforme o seu tipo. As opções usualmente disponíveis são:

  • Nenhum símbolo: Nenhum simbolo é apresentado para esta camada;
  • Símbolo único: Todos as feições serão representadas por apenas um único simbolo;
  • Categorizado: Este item é utilizado para criarmos símbolos diferentes para categorias diferentes, onde estas categorias são representadas por textos (ex. Tipo de Contaminante, Classe de Uso do Solo ou Bairro);
  • Graduado: As feições serão representadas por um conjunto de cores que esta relacionada a uma quantidade, isto é, números (ex. Concentração do Contaminante, Área Impermeabilizada ou População);
  • Baseado em Regra: Nesta opção, você poderá criar regras específicas para o seu conjunto de dados (ex. Locais contaminados por Benzeno serão representados por um X enquanto locais reabilitados que foram contaminados com Arsênio serão apresentados como um O).

Já na caixa indicada com (3) na figura anterior, você poderá montar o seu símbolo. Por exemplo, você pode clicar sobre o botão + na parte inferior desta caixa e adicionar sobre o símbolo existente um X, ou adicionar duas bolas com cores diferentes.

E no menu do tipo de camada (4), você poderá modificar o tipo do símbolo, indicando se ele será representado por uma fonte, elipse, um marcador simples, SVG ou criado pelo gerador de geometrias.

Símbolo Único (com Vários Marcadores)

Neste primeiro exemplo, vamos classificar nossos pontos com um quadrado que contém dois triângulos dentro.

Modificando símbolo único com vários marcadores.Modificando símbolo único com vários marcadores.

Antes de adicionarmos mais marcadores ao nosso símbolo, vamos modificar o marcador existente (1) e convertê-lo em um quadrado vermelho. Clique sobre o marcador existente e nas opções abertas (3), coloque tamanho (size) 4, cor de preenchimento (fill color) Vermelho, cor de contorno (stroke color) Preto, estilo do contorno (Stroke style) Linha Sólida/Solid Line, Espessura do contorno (Stroke width) Hairline e selecione o símbolo Quadrado no final da barra de rolagem.

As outras opções você pode manter as que estiverem, mas lembre-se que temos opções para:

  • Rotação (Utilizado para girar o marcador adicionado);
  • Offset (Para deslocar o símbolo na grade);
  • Ponto de Ancoragem (Onde o marcador vai ficar “grudado”).

Adicione outros dois marcadores (2) e modifique as opções (3) deles. Mude o marcador para triângulo, com fundo branco, tamanho 3 e com rotação igual à 0 e o outro igual à 180.

Por fim, você pode configurar as opções de transparência, tipo de mistura e efeitos da camada no menu (4).

Símbolos Categorizados

Neste tópico, vamos separar nossos itens pela classificação da área contaminada, para diferenciar as áreas que estão sob investigação, intervenção, monitoramento ou reabilitada.

Criação de símbolos categorizados no QGIS.Criação de símbolos categorizados no QGIS.

Para realizar essa classificação, escolha no item Coluna a opção CLASSIFICA e clique sobre o botão Classificar na parte inferior da janela. Você pode clicar sobre os símbolos separadamente e editá-los (nos mesmos moldes que mostramos no tópico anterior) ou aplicar uma classificação para todos clicando em Símbolo (logo abaixo da opção Coluna) ou em Rampa de Cores (Color ramp).

Lembre-se que a classificação é baseada nos itens disponíveis na tabela de atributos do shapefile.

Símbolos Graduados

Como nosso shapefile não contém uma coluna com um dado numérico relacionado à contaminação, vamos utilizar a coluna Lat (isto é, Latitude) para apresentar nossos símbolos graduados.

Símbolos graduados no QGIS.Símbolos graduados no QGIS.

Nesta opção de representação, podemos escolher a coluna que iremos mostrar usando a opção Coluna (Column), o tipo de símbolo em Símbolo (Symbol), formato da legenda (Legend format), se a classificação será por cores ou por tamanho (Method) e a rampa de cores (Color ramp).

Podemos ainda escolher como os dados serão distribuídos escolhendo o modo de representação (menu logo abaixo das classes). Entre as opções disponíveis temos Intervalos Iguais (Equal Interval), Quartis (Quantile), Quebras Naturais Jenks (Natural Breaks Jenks), Desvio padrão (Standard Deviation) e Quebras Claras (Pretty Breaks).

Nesta situação, é interessante também aprendermos a editar a rampa de cores. Para editá-la, basta clicar sobre ela e a seguinte janela será aberta.

Rampa de cores no QGISRampa de cores no QGIS.

Na janela da rampa de cores, você pode definir qual é a primeira e ultima cor da rampa (1), adicionar ou excluir cores (2), estabelecer qual é a posição da referida cor na rampa (3) ou editar a rampa como um todo usando os gráficos (4).

Símbolos baseados em Regras

Neste tipo de símbolo, criamos regras específicas para representar nossos dados. Por exemplo, vamos criar um símbolo para as áreas já reabilitadas que estavam contaminadas por benzeno.

Para acessar a janela de regras, clique no sinal de mais (1) e em seguida uma nova janela será aberta, sendo que após inserir sua regra, ela vai aparecer ficar disponível na janela principal (2).

Símbolos baseados em regras no QGIS.Símbolos baseados em regras no QGIS.

Na janela aberta para inserir a regra, você irá adicionar um rótulo para o seu símbolo (neste caso, colocamos Reabilitada sem Benzeno), e na caixa Filtro, iremos clicar no botão com um E para inserir a seguinte expressão:

"ETAPA_DE_G" = 'Área Reabilitada' AND "CONTAMINAN" =  'BTEX e HPA'

Com ela, passamos para o QGIS que queremos todos os locais onde a coluna ETAPA_DE_G é igual à Área Reabilitada e o CONTAMINAN é igual à BTEX e HPA. Quando essas duas condições são satisfeitas, o símbolo que criarmos para ela será mostrado.

Editando regras dos símbolos no QGIS.Editando regras dos símbolos no QGIS.

Lembrando que após você inserir a expressão, clique no botão Test para confirmar se há algum ponto que satisfaça as condições que você colocou (e se a função esta funcionando).

Modificando o Tipo de Camada do Símbolo

Agora que vimos os principais tipos de representação dos símbolos, vamos modificar um pouco os tipos de camadas do símbolo, que podem ser modificadas em qualquer um dos itens que mostramos acima.

Marcador do tipo Fonte

Ao selecionar esse tipo de marcador (1) podemos selecionar uma fonte existente e utilizar as letras disponíveis (2) para representar nossos pontos.

Criando um marcador usando as fontes no QGIS.Criando um marcador usando as fontes no QGIS.

Marcador baseado em Vetor (SVG)

Em alguns mapas, costumamos representar localidades com símbolos mais sofisticados, sendo que, normalmente, são utilizados imagens vetoriais. Dentro do QGIS, ao selecionar essa opção, já temos a disposição alguns vetores, bastando apenas selecionar o que melhor se encaixa na representação dos seus dados.

Marcador do tipo SVG no QGIS.Marcador do tipo SVG no QGIS.

Além dos arquivos SVG disponíveis no QGIS, também é possível baixar outros arquivos e utilizados. Softwares como InkScape podem ser utilizados para criá-los ou você pode baixar eles de sites como publicdomainvectors.org.

Marcador com Vetor baseado em Campo

Este é um bom item para shapefiles que contenham dados quantitativos, de forma a representar esses dados com linhas de tamanhos diferentes e outras informações com ângulos diferenciados.

Aplicamos esse marcador utilizando a coluna Lat e Long do nosso shapefile, note que conforme os pontos se distanciam do centro, há uma inclinação das retas.

Marcador baseado em campo no QGIS.Marcador baseado em campo no QGIS.

Algumas ideias que podem aproveitar esse tipo de marcador são direção do vento, orientação de falhas geológicas, direção da foto registrada, entre outros.

Gerador de Geometrias (Geometry Generator)

Embora seja também um tipo de camada do símbolo, colocamos ele em separado pois sua utilização depende de linhas de código. Ao selecionar esse item, você irá se deparar com um painel em branco com o seguinte código:

$geometry

Esse código faz com que o QGIS apresente a geometria da feição em questão. No nosso caso, os pontos das áreas contaminadas.

Vamos modificar um pouco esse código e adicionar um buffer de 50 metros em cada um dos pontos, sem recorrer às ferramentas do QGIS, usando somente o gerador de geometrias.

buffer($geometry, 0.0005)

Lembre-se que nosso arquivo de áreas contaminadas encontra-se em coordenadas geográficas, por isso nosso buffer foi de 0,0005 graus (equivalente aos 50 metros desejados).

Outro fator interessante do gerador de geometrias é que você não esta preso ao tipo de feição do arquivo, pois ao gerar o buffer, você esta criando um polígono, logo, terá que modificar uma das opções abaixo do menu dos tipos de camadas (isto é, o item tipo de geometria).

Buffer com Gerador de Geometrias no QGIS.Buffer com Gerador de Geometrias no QGIS.

Outra função interessante é a make_line(), a qual possibilita criar linhas entre diferentes pontos. Neste caso, criamos uma linha entre todas as áreas contaminadas e a área contaminada identificada com o ID 1.

Criando linhas usando o gerador de geometrias no QGIS.Criando linhas usando o gerador de geometrias no QGIS.

O código para esse tipo de função é apresentado abaixo.

make_line(
$geometry,
geometry(get_feature_by_id('MG_areas_contaminadas_reabilitadas_2017', 1))
)

Existem muitas possibilidades para criação de símbolos no gerador de geometrias, basta um pouco de estudo e diferentes possibilidades surgirão.

Isso tudo se aplica às linhas também?

Sim, apesar de algumas particularidades desta feição, a edição de linhas também segue os mesmos princípios que vimos até agora.

Por exemplo, um dos tipos de camada disponíveis para as linhas são as flechas, possibilitando converter suas linhas em flechas e indicar uma direção. Outro exemplo é a linha de marcadores, onde você indicar um marcador para se repetir ao longo da linha.

E os polígonos?

De forma semelhante aos pontos e linhas, temos as mesmas representações dos dados e temos ainda os polígonos invertidos (ótimos para criar mascaras nos seus mapas) e os polígonos em 2,5D.

Nos tipos de camadas disponíveis, temos diferentes tipos de preenchimento (gradiente, linha, pontos, raster, SVG e degrade no formato do polígono).

E com isso, finalizamos nossa postagem abordando os vários tipos de simbologia que o QGIS nos possibilita realizar. Você ficou com alguma dúvida? Escreva ela nos comentários que estaremos respondendo.

Quer aprender a criar seus mapas de localização no QGIS 3.4? Confira nosso curso online clicando aqui.

Referências Consultadas.

Quick guide to geometry generator symbol layer. Anita Graser. Disponível em <https://anitagraser.com/2017/04/08/a-guide-to-geometry-generator-symbol-layers/>. Acesso em 20 jun. 2019.

by Fernando BS at June 25, 2019 06:01 AM

June 24, 2019

Authors: Giuseppe Modica, Joao Silva and Giandomenico De Luca. The availability of very high resolution (VHR) images acquired from sensors assembled on unmanned aerial vehicles (UAVs) has introduced a new set of possibilities for classifying land cover types at finer levels of spatial detail, thus granting environmental monitoring with more precision and efficiency while opening […]

by Giuseppe Modica at June 24, 2019 12:40 PM

Context

Since last year we (the QGIS communtity) have been using QGIS-Server-PerfSuite to run performance tests on a daily basis. This way, we’re able to monitor and avoid regressions according to some test scenarios for several QGIS Server releases (currently 2.18, 3.4, 3.6 and master branches). However, there are still many questions about performance from a general point of view:

  • What is the performance of QGIS Server compared to QGIS Desktop?
  • What are the implications of feature simplification for polygons and lines?
  • Does the symbology have a strong impact on performance and in which proportion?

Of course, it’s a broad and complex topic because of the numerous possibilities offered by the rendering engine of QGIS. In this article we’ll look at typical use cases with geometries coming from a PostgreSQL database.

Methodology

The first way to monitor performance is to measure the rendering time. To do so, the Map canvas refreshis activated in the Settings of QGIS Desktop. In this way we can get the rendering time from within the Rendering tab of log messages in QGIS Desktop, as well as from log messages written by QGIS Server.

The rendering time retrieved with this method allows to get the total amount of time spent in rendering for each layer (see the source code).

But in the case of QGIS Server another interesting measure is the total time spent for a specific request, which may be read from log messages too. There are indeed more operations achieved for a single WMS request than a simple rendering in QGIS Desktop:

The rendering time extracted from QGIS Desktop corresponds to the core rendering time displayed in the sequence diagram above. Moreover, to be perfectly comparable, the rendering engine must be configured in the same way in both cases. In this way, and thanks to PyQGIS API, we can retrieve the necessary information from the Python console in QGIS Desktop, like the extent or the canvas size, in order to configure the GetMap WMS request with the appropriate WIDTH,, HEIGHT , and BBOX parameters.

Another way to examine the performance is to use a profiler in order to inspect stack traces. These traces may be represented as a FlameGraph. In this case, debug symbols are necessary, meaning that the rendering time is not representative anymore. Indeed, QGIS has to be compiled in Debug mode.

Polygons

For these tests we use the same dataset as that for the daily performance tests, which is a layer of polygons with 282,776 features.

Feature simplification deactivated

Let’s first have a look at the rendering time and the FlameGraph when the simplification is deactivated. In QGIS Desktop, the mean rendering time is 2591 ms. Using to the PyQGIS API we are able to get the extent and the size of the map to render the map again but using a GetMap WMS request this time.

In this case, the rendering time is 2469 ms and the total request time is 2540 ms. For the record, the first GetMap request is ignored because in this case, the whole QGIS project is read and cached, meaning that the total request time is much higher. But according to those results, the rendering time for QGIS Desktop and QGIS Server are utterly similar, which makes sense considering that the same rendering engine is used, but it is still very reassuring :).

Now, let’s take a look to the FlameGraph to detect where most of the time is spent.

 

Undoubtedly the FlameGraph’s are similar in both cases, meaning that if we want to improve the performance of QGIS Server we need to improve the performance of the core rendering engine, also used in QGIS Desktop. In our case the main method is QgsMapRendererParallelJob::renderLayerStatic where most of the time is spent in:

Methods Desktop % Server %
QgsExpressionContext::setFeature 6.39 6.82
QgsFeatureIterator::nextFeature 28.77 28.41
QgsFeatureRenderer::renderFeature 29.01 27.05

Basically, it may be simplified like:

Clearly, the rendering takes about 30% of the total amount of time. In this case geometry simplification could potentially help.

Feature simplification activated

Geometry simplification, available for both polygons and lines layers, may be activated and configured through layer’s Properties in the Rendering tab. Several parameters may be set:

  • Simplification may be deactivated
  • Threshold for a more drastic simplification
  • Algorithm
  • Provider simplification
  • Scale

Once the simplification activated, we varied the threshold as well as the algorithm in order to detect performance jumps:

The following conclusions can be drawn:

  • The Visvalingam algorithm should be avoided because it begins to be efficient with a high threshold, meaning a significant lack of precision in geometries
  • The ideal threshold for Snap To Grid and Distance algorithms seems to be 1.05. Indeed, considering that it’s a very low threshold, the precision of geometries is still pretty good for a major improvement in rendering time though

For now, these tests have been run on the full extent of the layer. However, we still have a Maximum scale parameter to test, so we’ve decreased the scale of the layer:

And in this case, results are pretty interesting too:

Several conclusions can be drawn:

  • Visvalingam algorithm should be avoided at low scale too
  • Snap To Grid seems counter-productive at low scale
  • Distance algorithm seems to be a good option

Lines

For these tests we also use the same dataset as that for daily performance tests, which is a layer of lines with 125,782 features.

Feature simplification activated

In the same way as for polygons we have tested the effect of the geometric simplification on the rendering time, as well as algorithms and thresholds:

In this case we have exactly the same conclusion as for polygons: the Distance algorithm should be preferred with a threshold of 1.05.

For QGIS Server the mean rendering time is about 1180 ms with geometry simplification compared to 1108 ms for QGIS Desktop, which is totally consistent. And looking at the FlameGraph we note that once again most of the time is spent in accessing the PostgreSQL database (about 30%) and rendering features (about 40%).

 

 

 

 

 

Symbology

Another parameter which has an obvious impact on performance is the symbology used to draw the layers. Some features are known to be time consuming, but we’ve felt that a a thorough study was necessary to verify it.

 

Firstly, we’ve studied the influence of the width as well as the Single Symbol type on the rendering time.

Some points are noteworthy:

Simple Line is clearly the less time consuming

– Beyond the default 0.26 line width, rendering time begins to raise consequently with a clear jump in performance

 

Another interesting feature is the Draw effects option, allowing to add some fancy effects (shadow, glow, …).

However, this feature is known to be particularly CPU consuming. Actually, rendering all the 125,782 lines took so long that we had to to change to a lower scale, with just some a few dozen lines. Results are unequivocal:

 

The last thing we wanted to test for symbology is the effect of the Categorized classification. Here are the results for some classifications with geometry simplification activated:

  • No classification: 1108 ms
  • A simple classification using the column “classification” (8 symbols): 1148 ms
  • A classification based on a stupid expression “classification x 3″ (8 symbols): 1261 ms
  • A classification based on string comparison “toponyme like ‘Ruisseau*'” (2 symbols): 1380 ms
  • A classification with a specific width line for each category (8 symbols): 1850 ms

Considering that a simple classification does not add an excessive extra-cost, it seems that the classification process itself is not very time consuming. However, as soon as an expression is used, we can observe a slight jump in performance.

Labeling

Another important part to study regarding performance is labeling and the underlying positioning. For this test we decreased the scale and varied the Placement parameter without tuning anything.

Clearly, the parallel labeling is much more time consuming than the other placements. However, as previously stated, we used the default parameters for each positioning, meaning that the number of labels really drawn on the map differs from a placement to another.

Points

The last kind of geometries we have to study is points. Similarly to polygons and lines, we used the same dataset as that of performance tests, that is a layer with 435588 points.

In the case of points geometries geometry simplification is of course not available. So we are going to focus on symbology and the impact of marker size.

Obviously Font Marker must be used carefully because of the underlying jump in performance, as well as SVG Symbols. Moreover, contrary to Simple Marker, an increase of the size implies a drastic augmentation in time rendering.

General conclusion

Based on this factual study, several conclusions can be drawn.

Globally, FlameGraph for QGIS Desktop and QGIS Server are completely similar as well as rendering time.

It means that if we want to improve the performance of QGIS Server, we have to work on the desktop configuration and the rendering engine of the QGIS core library.

Extracting generic conclusions from our tests is very difficult, because it clearly depends on the underlying data. But let’s try to suggest some recommendations :).

Firstly, geometry simplification seems pretty efficient with lines and polygons as soon as the algorithm is chosen cautiously, and as long as your features include many vertices. It seems that the Distance algorithm with a 1.05 threshold is a good choice, with both high and low scale. However, it’s not a magic solution!

Secondly, a special care is needed with regards to symbology. Indeed, in some cases, a clear jump in performance is notable. For example, fancy effects and Font Marker SVG Symbol have to be used with caution if you’re picky on rendering time.

Thirdly, we have to be aware of the extra cost caused by labeling, especially the Parallel  placement for line geometries. On this subject, a not very well-known parameter allows to drastically reduce labeling time: the PAL candidates option. Actually, we may decrease the labeling time by reducing the number of candidates. For an explicit use case, you can take a look at the daily reports.

In any case, improving server performance in a substantial way means improving the QGIS core library directly.

Especially, we noticed thanks to FlameGraph that most of the time is spent in drawing features and managing the data from the PostgreSQL database. By the way, a legitimate question is: “How much time do we spend on waiting for the database?”. To be continued 😉

If you hit performance issues on your specific configuration or want to improve QGIS awesomeness, we provide a unique QGIS support offer at http://qgis.oslandia.com/ thanks to our team of specialists!

by Paul Blottière at June 24, 2019 07:56 AM

June 19, 2019

You are using QGIS and look for support services to improve your experience and solve problems ? Oslandia is here to help you with our full QGIS editor service range ! Discover our team members below.

You will probably interact first with our pre-sales engineer Bertrand Parpoil. He leads Geographical Information System projects for 15 years for large corporations, public administrations or hi-tech SME. Bertrand will listen to your needs and explore your use cases, to offer you the best set of services.

Régis Haubourg also takes part in the first steps of projects to analyze your usages and improve them. GIS Expert, he knows QGIS by heart and will make the most of its capabilities. As QGIS Community Manager at Oslandia, he is very active in the QGIS community of developers and contributors. He is president of the Francophone OSGeo local chapter ( OSGeo-fr ), QGIS voting member, organizes the French QGIS day conference in Montpellier, and participates to QGIS community meetings. Before joining Oslandia, he led the migration to QGIS and PostGIS at the Adour-Garonne Water Agency, and now guides our clients with their GIS migrations to OpenSource solutions. Régis is also a great asset when working on water, hydrology and other specific thematic subjects.

Loïc Bartoletti develops QGIS, specializing in features corresponding to his fields of interests : network management, topography, urbanism, architecture… We find him contributing to advanced vector editing in QGIS, writing Python plugins, namely for DICT management. Pushing CAD and migrations from CAD tools to GIS and QGIS is one of his major goals. He will develop your custom applications, combining technical expertise and functional competences. When bored, Loïc packages software on FreeBSD.

Vincent Mora is senior developer in Python and C++, as well as PostGIS expert. He has a strong experience in numerical simulation. He likes coupling GIS (PostGIS, QGIS) with 3D numerical computing for risk management or production optimization. Vincent is an official QGIS committer and can directly integrate your needs into the core of the software. He is also GDAL committer and optimizes low-level layers of your applications. Among numerous activities, Vincent serves as lead developer of the development team for Hydra Software, a tool dedicated to unified hydraulics and hydrology modelling and simulation based on QGIS.

Hugo Mercier is an officiel QGIS committer too for several years. He regularly talks in international conferences on PostGIS, QGIS and other OpenSource GIS softwares. He will implement your needs with new QGIS features, develop innovative plugins ( like QGeoloGIS ) and design and build your new custom applications, solving all kind of technological challenges.

Paul Blottière completes our QGIS committers : very active on core development, Paul has refactored the QGIS server component to bring it to an industry-grade quality level. He also designed and implemented the infrastructure allowing to guarantee QGIS server performances. He dedicated himself to QGIS server OGC certification, especially for WMS (1.3). Thanks to this work QGIS is now a reference OGC implementation.

Julien Cabièces recently joined Oslandia, and quickly dived into QGIS : he contributes to the core of this Desktop GIS, on the server component, as well as applications linked to numerical simulation. Coming from a satellite imagery company with industrial applications, he uses his flexibility to answer all your needs. He brings quality and professionalism to your projects, minimizing risks for large production deployments.

You may also meet Vincent Picavet. Oslandia’s founder is a QGIS.org voting member, and is involved in the project’s evolution and the organization of the community.

Aside from these core contributors, all other Oslandia members also master QGIS integrate this tool into their day-to-day projects.

Bertrand, Régis, Loïc, Vincent (x2), Hugo, Paul et Julien are in tune with you and will be happy to work together for your migrations, application development, and all your desires to contribute to the QGIS ecosystem. Do not hesitate to contact us !

by Vincent Picavet at June 19, 2019 12:03 PM

June 18, 2019

Prezados leitores,

Provavelmente é de seu conhecimento que podemos filtrar o resultado de uma consulta WFS (registros) através do CQL Filter. Porém, caso você não tenha conhecimento existe uma outra forma de filtrar seus dados em uma requisição WFS.

Imagine que você possui uma view no seu banco de dados, e ela está configurada como uma camada no seu GeoServer. Esta view possui 23 colunas, porém você só precisa utilizar 3 colunas. Você acha que tem necessidade de você ficar trazendo informações de 20 colunas que você não vai utilizar em cada requisição WFS?

A resposta é não. Você pode utilizar o parâmetro PropertyName na sua requisição WFS e informar o nome das colunas que você realmente necessita. Veja como:

https://localhost:8080/geoserver/wfs?request=GetFeature&service=WFS&version=1.0.0&typeName=topp:states&outputFormat=csv&PropertyName=(STATE_NAME,STATE_ABBR,WORKERS)

Com a requisição acima, recebemos apenas as colunas que realmente iremos utilizar, e com isso diminuímos o trafego de informações “desnecessárias” transitando na rede de dados e aumentamos a performance da nossa aplicação.

by Fernando Quadro at June 18, 2019 12:35 PM

June 17, 2019

Prezados leitores,

Vocês sabiam que é possível exigir que um ou mais arquivos estejam disponíveis para que o GeoServer suba?

Se o diretório de dados estiver em um sistema de arquivos da rede, pode ser desejável, por razões de segurança, que um ou mais arquivos ou diretórios existam antes do GeoServer iniciar, para evitar que o GeoServer volte a uma configuração insegura padrão se o diretório de dados parecer estar vazio devido à perda deste recurso de rede.

Para exigir que arquivos ou diretórios existam, use qualquer um dos métodos para definir a variável GEOSERVER_REQUIRE_FILE. Não especifique um ponto de montagem, pois isso ainda existirá se um sistema de arquivos de rede não estiver disponível; em vez disso, especifique um arquivo ou diretório dentro de uma montagem de rede. Por exemplo:

Variável de ambiente:

export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml

Propriedade do sistema Java:

CATALINA_OPTS="-DGEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml"

Parâmetro de contexto de servlet:

<web-app>
  ...
  <context-param>
    <param-name>GEOSERVER_REQUIRE_FILE</param-name>
    <param-value>/mnt/server/geoserver_data/global.xml</param-value>
  </context-param>
  ...
</web-app>

Você pode ainda especificar vários arquivos ou diretórios que devem existir, separando-os com o separador de caminho ( : no Linux, ; no Windows):

Variável de ambiente:

export GEOSERVER_REQUIRE_FILE=/mnt/server/geoserver_data/global.xml:/mnt/server/data

Para a propriedade do Java e para o parâmetro de contexto do servlet, basta seguir a mesma lógica acima.

Fonte: GeoServer Documentation

by Fernando Quadro at June 17, 2019 10:30 AM

June 13, 2019

Le quatrième groupe de modules du cours gratuit sur les systèmes d’information géographiques appliqués à la gestion des municipalités est maintenant disponible. Ce modules vont nous permettre de montrer comment créer des cartes destinées à être imprimées, mais également comment géoréférencer des images, ainsi que le travail en 3 dimensions réalisable sur gvSIG Desktop.

Nous publierons dans le courant de la semaine prochaine les modules sur gvSIG Online et gvSIG Mobile. Le certificat sera disponible quand ces modules auront été publiés.

Pour suivre ce cours, aucune inscription n’est nécessaire, vous n’avez qu’à suivre les vidéo-tutoriaux. Vous trouverez une section “questions fréquentes” au premier post de ce cours, avec toutes les informations importantes.

Modules:

Module 13: Cartes

Lors de cette vidéo, nous allons montrer comment créer une carte, destinée à être sauvegardée, imprimée, exportée en format PDF ou PostScript … Et où il est possible d’insérer les vues sur lesquelles nous avons travaillé.

Sur cette carte, il est possible d’insérer tous types d’éléments, comme du texte, une flèche, une échelle, une légende, des images ou des logos, des graphiques, des lignes …

La cartographie à suivre dans cette vidéo est disponible en cliquant sur ce lien.

Module 14: Géoréférencement d’images

Lors de cette vidéo, nous allons montrer comment géoréférencer une image. Parfois, les techniciens d’une municipalité ont en possession des images qui ne sont pas géoréférencées. Ils peuvent aussi avoir une vieille carte en format papier, dont les données peuvent être requises pour effectuer des analyses ou des opérations comme la délimitation des municipalités dans le détail par exemple. Certaines images au format papier n’ont pas de coordonnées, donc si l’on choisit de les insérer dans une vue, elles auront les coordonnées “0,0” et ne seront référencées avec aucune cartographie. Pour remédier à cela, une image doit être géoréférencée.

La cartographie à suivre dans cette vidéo est disponible en cliquant sur ce lien.

Module 15: gvSIG 3D

Lors de cette vidéo, nous allons montrer quelles sont les fonctionnalités principales de l’extension 3D dans gvSIG, basées sur l’application WorldWind de la NASA. Les vues 3D que nous pouvons créer sont des vues plates, dans le cas de travaux sur des zones locales, ou des vues sphériques, quand l’objectif est de les visualiser sur la sphère terrestre.

Dans les vues 3D, nous pouvons visualiser des modèles numériques de terrain, et superposer d’autres couches sur ces MNT, comme par exemple une orthophoto.

Et si l’on a une couche vecteur avec des bâtiments et un champ (dans la table attributaire) contenant le nombre d’étages ou la hauteur des bâtiments, il est possible d’appliquer des opérations d’extrusion pour voir les polygones verticalement.

La cartographie à suivre dans cette vidéo est disponible en cliquant sur ce lien.

Autres modules:

by Mario at June 13, 2019 12:09 PM

Todos los que trabajéis en el ámbito de la gestión municipal en España os habréis encontrado en alguna ocasión con la necesidad de disponer de una capa de secciones o distritos censales de uno o varios municipios.

Con gvSIG Desktop es muy sencillo poder cargar la capa de secciones censales que ofrece el INE (Instituto Nacional de Estadística) y después crear una nueva capa con las secciones censales del municipio o municipios que necesitemos.

Lo primero que debéis hacer es descargar la capa de secciones censales de toda España. Disponible aquí. Tras descomprimir el archivo que se descarga, tal y como muestra el vídeo, ya podéis cargarlo en gvSIG Desktop (asignando a la Vista la proyección de la capa), consultar el campo que contiene el identificador de municipio del INE y seleccionar todas las secciones censales de dicho municipio. Por último exportamos a una nueva capa…y listo. Extremadamente sencillo.

Esa capa tiene un campo con el código de distrito censal, por lo que a partir de ella podemos generar otra capa de distritos censales aplicando el geoproceso de “Disolver”. Tal y como muestra este segundo vídeo.

by Alvaro at June 13, 2019 10:59 AM

We pleased to share the GeoServer 2.14.4 maintenance release. Downloads are provided (zip|war) along with docs (html) and extensions.

This is a maintenance release of the GeoServer 2.14 series and is a recommended update for existing installations.

A large number of individuals contributed to this release, with efforts primarily focused on the setup of a new build box for the team. Thanks to Torben, Tom, Andrea and Jody for their work restoring the build server. Some activities (windows installer, pdf user guide, CITE testing) are still available to work on.

This release is made in conjunction with GeoTools 20.4 and GeoWebCache 1.14.4. For more information please see GeoServer release notes (2.14.4 |2.14.3 | 2.14.2 | 2.14.1|2.14.0|2.14-RC).

Improvements and Fixes

This release includes a number of new features and improvements:

  • Improvements to security integration with tiles seeding now working against secured layers, and WCS now supporting “challenge” mode
  • A subtle rendering fix when advanced projection handling is used to remove small vertical gaps in polygon output.
  • Improved rendering for followLine and maxAngleDelta support.
  • REST API now supports layer names that including dot character
  • Include coverage metadata in WCS 2.0.1 GetCapabilities and DescribeCoverage output. Similar improvements for for GetFeatureInfo access to coverage metadata.
  • WCS 1.0.0 support for elevation and custom dimensions
  • Default security configuration restricts WFS StoredQuery management operations to administrator access
  • Application schema has improved its support for xpath with the ability to support multiple matches
  • Style validation is better able to handle internationalization in descriptive text such as title and description
  • A small but important fix in how URL connection parameters are stored and transfered
  • Many dependencies have been updated, along with small bug fixes as described in the release notes.

About GeoServer 2.14 series

Additional information on the GeoServer 2.14 series:

by jgarnett at June 13, 2019 03:10 AM

June 12, 2019

Sometimes we need to convert a line layer into equispaced points layer, that is, points that are separated by a certain distance from each other.

This type of layers can be generated almost immediately thanks to a geoprocess in gvSIG Desktop.

For that we only have to indicate the line layer from which the point layer will be created and the distance between the points.

At this video you can see an example where a point layer is generated from a line layer that represents the streets of a city:

by Mario at June 12, 2019 07:43 AM

A popular SQL party trick is to generate the Mandelbrot set using Common Table Expressions (CTEs) to implement the required iteration.   The usual demo outputs the image using ASCII art:




This is impressive in its own way...  but really it's like, so 70's, man.

Here in the 21st century we have better tooling for describing graphics using text - namely, Scalable Vector Graphics (SVG).  And best of all, it's built right into modern browsers (finally!).  So here's the SQL Mandelbrot set brought up to date with SVG output.

A straightforward conversion of the quert is relatively easy.  Simply render each cell pixel as an SVG rect element of size 1, and use a grayscale colour scheme. But  a couple of improvements produce a much better result:
  1. A more varied colour palette produces a nicer image
  2. Using one SVG element per cell result in a very large file, which is slow to render.  There's a lot of repeated pixels in the raster, so a more compact representation is possible  
The colour palette is easily improved with a bit of math (modulo cumbersome SQL syntax).  Here I use a two-ramp palette, sweeping through shades from black to blue, and then through tints to white.

A simple way of reducing raster size is to use Run-Length Encoding (RLE).  This works well with SVG because the rect element can simply be extended by increasing the width attribute.  The tricky part is using SQL to merge the rows for contiguous same-value cells .  As is often the case, a straightforward procedural algorithm requires some cleverness to accomplish in SQL.  It had me stumped for a while.  The solution seemed bound to involve window functions, but trying various combinations of the multitudinous options available didn't produce the desired result.  Then I realized that the problem is isomorphic to that of merging contiguous date ranges.  That is a high-value SQL use case, and there's numerous solutions available.  The two that stand out are (as discussed here):
  • Start-of-Group - this approach uses a LAG function to flag where the group value changes, followed by a running SUM to compute a unique index value for each group (run, in this case).  Group rows are then aggregated on the index
  • Tabibitosan - this is a clever and efficient approach, but is harder to understand and less general
The solution presented uses Start-of-Group, for clarity.  RLE reduces the number of SVG elements to about 12,000 from 160,000, and file size to 1 MB from 11 MB, and hence much faster loading and render time in a web browser.

Here's the output image, with the SQL query producing it below (also available here).



Here's how the query works:
  1. x is a recursive query producing a sequence of integers from 0 to 400 using standard SQL
  2. z is a recursive query creating the Mandelbrot set on a 400x400 grid.  A scale and offset maps the grid cell ordinates into the complex plane, centred on the Mandelbrot set.  The query computes successive values of the set equation for each cell.  A cell is terminated when it is determined that the equation limit is unbounded.   
  3. itermax selects the maximum iterations for each cell.  This result set contains the final result of the Mandelbrot computation
  4. runstart finds and flags the start of each RLE "run" group for each row of the raster
  5. runid computes an id for each run in each row
  6. rungroup groups all the cells in each run and finds the start and end X index
  7. plot assigns a colour to each run, based on the iteration limit i
  8. the final SELECT outputs the SVG document, with rect elements for each run

WITH RECURSIVE
x(i) AS (
VALUES(0)
UNION ALL
SELECT i + 1 FROM x WHERE i ≤ 400
),
z(ix, iy, cx, cy, x, y, i) AS (
SELECT ix, iy, x::FLOAT, y::FLOAT, x::FLOAT, y::FLOAT, 0
FROM
(SELECT -2.2 + 0.0074 * i, i FROM x) AS xgen(x, ix)
CROSS JOIN
(SELECT -1.5 + 0.0074 * i, i FROM x) AS ygen(y, iy)
UNION ALL
SELECT ix, iy, cx, cy,
      x*x - y*y + cx AS x, y*x*2 + cy, i + 1
FROM z
WHERE x*x + y*y < 16.0
AND i < 27
),
itermax (ix, iy, i) AS (
SELECT ix, iy, MAX(i) AS i
FROM z
GROUP BY iy, ix
),
runstart AS (
SELECT iy, ix, I,
CASE WHEN I = LAG(I) OVER (PARTITION BY iy ORDER By ix)
THEN 0 ELSE 1 END AS runstart
FROM itermax
),
runid AS (
SELECT iy, ix, I,
SUM(runstart) OVER (PARTITION BY iy ORDER By ix) AS run
FROM runstart
),
rungroup AS (
SELECT iy, MIN(ix) ix, MAX(ix) ixend, MIN(i) i
FROM runid
GROUP BY iy, run
),
plot(iy, ix, ixend, i, b, g) AS (
SELECT iy, ix, ixend, i,
CASE
WHEN i < 18 THEN (255 * i / 18.0 )::integer
WHEN i < 27 THEN 255
ELSE 0 END AS b,
CASE
WHEN i < 18 THEN 0
WHEN i < 27 THEN (255 * (i - 18) / (27 - 18 ))::integer
ELSE 0 END AS g
FROM rungroup
ORDER BY iy, ix
)
SELECT '<svg viewBox="0 0 400 400" '
  || ' style="stroke-width:0" xmlns="http://www.w3.org/2000/svg">' 
  || E'\n'
|| string_agg(
'<rect style="fill:rgb('
      || g || ',' || g || ',' || b || ');"  '
|| ' x="' || ix || '" y="' || iy
|| '" width="' || ixend-ix+1 || '" height="1" />', E'\n' )
|| E'\n' || '</svg>' || E'\n' AS svg
FROM plot;





by Dr JTS (noreply@blogger.com) at June 12, 2019 04:54 AM

June 11, 2019

En determinadas ocasiones necesitamos convertir una capa de líneas en una de puntos equiespaciados, es decir, en puntos que estén separados una determinada distancia entre sí.

Este tipo de capas se pueden generar de forma casi inmediata gracias a un geoproceso en gvSIG Desktop.

Simplemente debemos indicar la capa de líneas a partir de la que generar la capa de puntos y la distancia entre los puntos.

En el siguiente vídeo podéis ver un ejemplo en el que a partir de una capa que representa los ejes de una ciudad generamos una de puntos.

by Alvaro at June 11, 2019 04:34 PM

June 10, 2019

I'm glad to release a new update of the Semi-Automatic Classification Plugin v. 6.3.0.
This version includes some new features and bug fixing.


Following the changelog:
-added SWIR1 and SWIR2 variables in Band calc
-added NBR calculation in Band calc index calculation
-fixed issue with OSM tile service
-fixed issue with USGS Spectral Library v.6
-fixed issue with band set creation after multiple image download
-fixed issue with band calc name of outputs

Read more »

by Luca Congedo (noreply@blogger.com) at June 10, 2019 06:13 PM

When talking to government audiences, I like to point out that the largest national mapping agency in the world resides in a building decorated like a hypertrophic kindergarten, in Mountain View, California. This generally gets their attention.

The second most important year in my career in geospatial was 20051, the year that Google Maps debuted, and began the migration of “maps on computers” from a niche market dominated by government customers to the central pivot of multiple consumer-facing applications.

The echoes of 2005 lasted for several years.

  • Microsoft quickly realized it was dramatically behind in the space, “MapPoint” being its only spatial product, and went on an acquisition and R&D spree.
  • Esri started moving much more quickly into web technology, slavishly aping Google product direction (spinny globes?! yes! JSON on the wire!? yes! tiled basemaps?!? oh yes!) in what must have been an embarassing turn for the “industry leader” in GIS.
  • Navteq and Teleatlas transitioned quickly from industry darlings (selling data to Google!) to providers of last resort, as more nimble data gatherers took up the previously-unimagineable challenge of mapping the whole world from scratch.
  • Open source did its usual fast-follower thing, churning out a large number of Javascript-and-map-tiles web components, and pivoting existing rendering engines into tile generators.

A funny thing happened in the shake out, though. Nobody ever caught up to Google. Or even came very close. While Google has abandoned Maps Engine–their foray into “real GIS”–their commitment to core location data, knowing where everything is and what everything is, all the time and in real time, remains solid and far in advance of all competitors.

Probably even before they rolled out the iPhone in 2007 Apple knew they had a “maps problem”. Once they added a GPS chip (a development that was only awaiting a little more battery oomph) they would be beholden to Google for all the directions and maps that made the chip actually useful to phone users.

And so we eventually got the Apple maps debacle of 2012. It turns out, building a global basemap that is accurate and includes all the relevant details that users have come to expect is really really really hard.

In an excellent article on the differences between Google and Apple’s maps, Justin O’Beirne posited:

Google has gathered so much data, in so many areas, that it’s now crunching it together and creating features that Apple can’t make—surrounding Google Maps with a moat of time.

Even the most well-funded and motivated competitors cannot keep up. Microsoft came the closest early on with Bing Maps, but seems to have taken their foot off the gas, in acknowledgement of the fact that they cannot achieve parity, let alone get ahead.

And so what? So what if Google has established Google Maps as a source of location data so good and so unassailable that it’s not worth competing?

Well, it sets up an interesting future dynamic, because the competitive advantage those maps provide is too large to leave unchallenged.

  • Apple cannot afford to have their location based devices beholden to Google–a direct competitor now via Android–so they have continued to invest heavily in maps. They’ve been a lot quieter about it after the debacle, but they haven’t given up.
  • Amazon AWS is the unchallenged leader in cloud computing, but Google wants a bigger piece of the cloud computing pie, and they are using Google Maps as a wedge to pull customers into the Google Cloud ecosystem. I have heard of multiple customers who have been wooed via combined Maps + Cloud deals that offer discounted Cloud pricing on top of Maps contracts. Why not put it all in one data centre?
  • Salesforce has just purchased Tableau, pulling one of the largest BI companies into the largest enterprise cloud company. Analytics has a lower need for precise location data, but Salesforce customers will include folks who do logistics and other spatial problems requiring accurate real-time data.

Someone is going to take another run at Google, they have to. My prediction is that it will be AWS, either through acquisition (Esri? Mapbox?) or just building from scratch. There is no doubt Amazon already has some spatial smarts, since they have to solve huge logistical problems in moving goods around for the retail side, problems that require spatial quality data to solve. And there is no doubt that they do not want to let Google continue to leverage Maps against them in Cloud sales. They need a “good enough” response to help keep AWS customers on the reservation.

How will we know it’s happening? It might be hard to tell from outside the Silicon Valley bubble. Most of the prominent contributors to the New Mapping Hegemony live behind the NDA walls of organizations like Google and Apple, but they are the kinds of folks Amazon will look to poach, in addition to members of Microsoft’s Bing team (more conveniently already HQ’ed in Seattle).

I think we’re due for another mapping space race, and I’m looking forward to watching it take shape.


1. The most important event of my geospatial career was the release of the iPhone 3GS with a GPS chip as a standard component.

June 10, 2019 01:00 PM