Welcome to Planet OSGeo

June 25, 2016

Gis-Lab

Опыт классификации космоснимка Landsat с помощью Semi-Automatic Classification Plugin в QGIS

Новая статья описывает опыт работы с Semi-Automatic Classification Plugin для QGIS для классификации снимка Landsat с целью выявления лесонарушений на примере НП “Орловское полесье”, а также содержит пошаговую инструкцию для лесного дешифрирования снимка с помощью данного плагина.

Автор: Карпачев Андрей Петрович, научный сотрудник НП “Орловское полесье”.

Прочитать | Обсудить

null

null

by Александр Мурый at June 25, 2016 04:15 PM

Paulo van Breugel

Climate data sets, which one to select?

For species or vegetation modelling, one of the first choices to make is the selection of explanatory variables, which in most cases will include climatic or bioclimatic data sets. One of the most widely used global climate data sets in biogeographic and ecological research is from Worldclim (Hijmans et al., 2005). Alternative global rainfall data […]

by pvanb at June 25, 2016 03:07 PM

Nathan Woodrow

Improving you styling workflow with the QGIS style dock – Part 1 – Live Styles!

This post is part of a series exploring the new style dock.

  • Part 1 – Styles
  • Part 2 – Plugin pages
  • Part 3 – New panel API

A while ago did a post about the new style dock in QGIS. The first stage was getting labels working and then moving on to styles. After many iterations of the UIs and the APIs I’m pretty happy with the release state of the dock. We now have styles (vector and raster), labels, saved styles, undo redo, and plugin support (yep!)

Of all the features I have added to QGIS this is my favorite. Nothing has made me feel more productive then working on this feature and seeing the gains it allows in day to day work.

If you haven’t used the style dock yet I would strongly encourage you to grab the nightly QGIS builds and give it a crack, F7 to open anytime, or use the paint brush icon on the layers panel.   I’m not bragging when I say that it will change your life in QGIS for the better, it has become a part of my daily workflow. No going back!

Dock break down

breakdown

As you can see in the image there is a few main things in the dock, the layer selection, style options selector (come back to this later), undo/redo, live update and apply.

Live Updates

One of the key things for me when doing this dock was instant feedback. I really hated the open close, change, apply, repeat workflow of the old dialogs.  Every widget in the dock can request a redraw on change so you can see feedback instantly in the canvas.  This might not always be what you want so you can disable it for those cases and use manual apply.

Undo Stack

Live updates come with a risk. What happens if you apply something you didn’t mean. There is no cancel button. Well not to fear we now have a undo/redo stack.  Any style change will now add an entry to the style undo stack so you can rollback and forward any changes. Undo/Redo now allows for fearless style changes, so style away to your hearts content and rollback anything you don’t like.

I will also add that the undo stack is stored on the layer object itself, so closing the dock doesn’t clear the stack nor does changing the active layer. You can also access the stack via the Python bindings if needed.

Style Options

On the side of the dock we have the different style options.  These buttons change the style options in the main panel.

optionsVector Style Options
  • Style
  • Label
  • Saved styles
  • Undo/Redo
optionsrasterRaster Style Options
  • Style
  • Transparency
  • Histogram
  • Saved styles
  • Undo/Redo

The Saved Styles and Undo/Redo will always be the last in the stack regardless of the active layer type.

Style UIs (Note: GIF heavy section)

Almost all the widgets have been tweaked to allow for better dock layout. Widgets are now in a more uniform layout which flows better when moving around in the dock and just generally look better.

layout

When I talked about live updates before this applies to everything, even the data defined buttons.  Any changes in those will be reflected into the canvas without any extra clicks.

dd

Changing renderers is now simple and quick. You go from nothing to seeing instant results in seconds.

change

A excellent side effect of the live updates is workflows that were never exposed before and now possible. Using the graduated renderer histogram for example. As the histogram allows for live edits we can now update the map on the fly from adjusting the histogram.

hiso.gif

Style UIs (Raster)

As soon as I finished vectors it became pretty evident that raster layers were going to be the next main thing to move.   So the style dock fully supports raster styling.

raster

Undo/Redo

For the final trick. Here we have the undo/redo stack in action. Unlimited undo/redo  on all layers when changing styles. Fearless change he we come

undo

Trying to find a picture to sum up my feelings about the style dock and I think this fits

but of course I’m super bias.

Stay tuned for Part 2 where I talk about adding your own style panels to the style dock.


Filed under: Open Source, qgis

by Nathan at June 25, 2016 07:54 AM

June 24, 2016

portailSIG

QGIS: des Ellipses de Déviation Standard (SDE), un plugin, « Standard Deviational Ellipse », des scripts R (processing) et Python et une approche critique...

Niveau Intermédiaire
Logiciels utilisés QGIS
R
Python
QGIS Plugin: Standard Deviational Ellipse
Plateforme Windows | Mac | Linux | FreeBSD

Parmi les commandes d’ArcGIS qui manquaient dans QGIS, figurait l’ Ellipse de Déviation Standard (Standard Deviational Ellipse ou SDE). Ce n’est plus le cas actuellement puisque c’était déjà possible de le faire avec des scripts R dans la Boîte à outils de Traitements (Processing) avec des packages dédiés et le nouveau plugin Standard Deviational Ellipse. Ses premiers résultats ont suscité des réactions de ma part (problem with the rsd values compared with the aspace or phonTools R packages ) qui ont amené Håvard Tveite à améliorer et compléter son plugin. 

Je vais essayer ici d’expliquer le pourquoi des choses, de manière visuelle et sans trop de statistiques, car ce concept a sérieusement été remis en cause récemment par Gong, J (2002), Clarifying the standard deviational ellipse. Geographical Analysis 34, 155–167.(pdf) et Wang B, Shi W, Miao Z (2015) Confidence Analysis of Standard Deviational Ellipse and Its Extension into Higher Dimensional Euclidean Space. PLoS ONE 10(3): e0118537. doi:10.1371/journal.pone.0118537,

C’est quoi ?

Si la dispersion d’une variable en une dimension est facile à calculer et à visualiser (histogrammes, etc.), c’est moins le cas pour des distributions bivariées (ou multivariées). La solution classique est de calculer séparément les écarts types de chaque variable et de représenter leur distribution par des ellipses (ou des ellipsoïdes) dont les axes sont ces écarts types. La méthode permet aussi de mesurer une tendance directionnelle (angle de l’ellipse).

Dans la réalité ce sont en fait des isocontours d’une surface, similaires à des courbes de niveau.

Et le graphique réalisé avec le package R psych  qui illustre le fait que cette démarche n'est pas limitée au domaine géospatial, loin de là.

Cette ellipse est donc théoriquement déterminée par trois mesures :

  1. calcul du point « moyen » du nuage des points (cela peut être le centroïde, le barycentre ...)
  2. calcul de l’angle de rotation de l’ellipse (orientation)
  3. calcul de la dispersion par les écarts-types des coordonnées x et y à partir du  point « moyen ». Ceux-ci vont définir les axes de l’ellipse (c’est pourquoi ESRI nomme aussi l’ellipse  « ellipse de l’écart type ».

Toutes les combinaisons sont possibles: affecter une masse (valeur) à chaque point, utiliser des moyennes pondérées, des médianes ou la covariance des données (pondérée ou non). Le calcul peut aussi varier en fonction de la répartition des points et il est possible d’utiliser soit la distance euclidienne soit d'autres distances ( comme la Distance de Mahalanobis ou la Distance de Manhattan).        

Je n’illustrerai ici que le cas de valeurs non pondérées (le reste n'est qu'un facteur d'échelle et de rotation).

Statistisquement parlant, l'objectif recherché est d'obtenir les valeurs de  la classique Règle 68-95-99.7 (3 sigma) empirique ( graphique réalisé avec Python et le module matplotlib) dans le cas d'une distribution univariée, et pas bivariée (Wang et al. (2015) contestent ces valeurs et en proposent des nouvelles pour les distributions multivariées, voir plus bas)

Un peu d’histoire ou comment une ellipse n’est pas une ellipse, mais...

Proposée dès 1926 par Lefever (Measuring Geographic Concentration by Means of the Standard Deviational Ellipse. American Journal of Sociology. 1926; 32(1):88–94), il a vite été démontré que le résultat n’était pas une ellipse (Furfey PH. A Note on Lefever’s "Standard Deviational Ellipse". American Journal of Sociology. 1927; 33(1):94–8), mais à ce qui est nommé actuellement une « Courbe de Déviation Standard ».  Depuis lors, bien évidemment, de nombreuses corrections ont été apportées pour tenter de résoudre le problème avec des résultats variables, mais la controverse continue... 

Il faut noter que le concept est né sous l’hypothèse que les variables observées suivaient la loi normale, mais que cette condition n’est plus indispensable avec les algorithmes utilisés actuellement. Elle est théoriquement dérivée de la distribution bivariée (ou bidimensionnelle)

A l’heure actuelle, dans le monde geospatial, ne subsistent que deux grands algorithmes et des solutions intermédiaires:

  • celui proposé par Yuill, R. S.(1971) dans The Standard Deviational Ellipse: An Updated Tool for Spatial Description, Geografiska Annaler 53B(1),28-39) qui est une énième adaptation réussie de la solution de Lefever, avec de nombreuses variantes postérieures;
  • celui implanté  dans le  logiciel CrimeStat III (Ned Levine, 2010, A Spatial Statistics Program for the Analysis of Crime Incident Locations (version 3.3).  Ned Levine & Associates, Houston, TX.; National Institute of Justice, Washington, DC.), spécialement dans la note 4 de Part II: Spatial Description (pdf).

Wang et al. (2015) ont récemment proposé un nouvel algorithme basé sur la décomposition spectrale de la covariance, plus exact selon eux.

Pourtant les géomaticiens continuent à utiliser cette méthode dans de nombreux domaines, sans se préoccuper ni de l’algorithme utilisé, ni de la signification statistique réelle du résultat.

Préambules statistiques: l’éllipse de covariance

Au départ, pour toute distribution bivariée, il est possible de calculer l’ellipse de covariance (ou ellipse de dispersion, ou ellipse des erreurs, ou...). Une matrice de covariance peut en effet être décomposée en (voir A geometric interpretation of the covariance matrix, par example):

  • vecteurs propres qui permettent de calculer les 2 angles de l’ellipse. Le premier vecteur (violet) est la direction dans laquelle les données varient le plus, le second (bleu) est orthogonal au premier.
  • valeurs propres qui sont les 2 diamètres de l’ellipse. Les rayons sont les racines carrées des valeurs propres et correspondent aux écarts types modifiés (translation + rotation) de x et y, σx' et σy’

La courbe limite de l’ellipse (Δχ2) correspond à un contour de probabilité de 1 écart type avec une probabilité de ± 39,35 % (c'est le genre de phrase qui nécessiterait de très nombreuses explications qu’il n’est pas possible de développer ici et je vous renvoie à vos manuels de statistiques).

 

Un script Python qui permet de le faire est disponible à par_covar.py. Le même résultat peut être obtenu avec les packages R ellipse:ellipse, siar: standard.ellipse , PhonTools: sdellipse, mvdalab: ellipse.mvdalab et autres.

Résultats:

Centre.x Centre.y σx σx Angle (en degrés par rapport au N) Aire Excentricité
320,66 215.66 45,67 112.86 77.12 16194.14 0,9144

En multipliant les valeurs obtenues par des facteurs d’échelle appropriés (loi normale, voir How to draw a covariance error ellipse?), il est donc possible de calculer des ellipses d’équiprobabilités. Ceci sera fait avec le package R car: dataEllipse() qui permet de superposer les contours d'une distribution bivariée normale de deux variables sur un semis de points. Un script R pour tracer ces ellipses dans la Boîte à Outils est disponible à car_ellipses.rsx.

Et il est possible de constater que l’ellipse de covariance correspond bien à une probabilité de ± 39,35 %.


Ces ellipses vont nous servir de repère pour superposer les différentes ellipses calculées dans la suite. Elles ne sont en effet que des adaptions et c'est pourquoi les coordonnées du point « moyen »,  les angles et l’excentricité restent les mêmes pour toutes les solutions.

L'interface du plugin

L’ellipse de Yuill

Les calculs d’estimation des rayons/écarts types (standard deviation) sont:

Elle est calculée avec l'option Yull du plugin.

Résultats (pour rappel, les valeurs des angles et de l’excentricité sont les mêmes que celles obtenues pour l’ellipse de covariance): 

σx σy Aire
44,12 109,03 15114,53

 C’est aussi l’ellipse calculée par: 

L’ellipse de CrimeStats III

Ned Levine, dans le cas de CrimeStats III, démontre dans la note 4 (voir référence plus haut) qu’avec les traitements précédents, l’ellipse résultante est trop petite (d’un facteur racine carrée de 2) pour deux raisons statistiques, le calcul des axes et le fait que les autres solutions ne sont pas correctes au niveau des degrés de liberté (n-2 au lieu de n). Les résultats sont beaucoup plus grands qu’avec l’algorithme de Yull.

Elle peut être calculée avec le package R aspace: calc_sde()  (un script R pour la Boîte à Outils de Traitement (Processing) est disponible à aspace_SDE.rsx ) ou avec l'option CrimeStat du plugin.

Résultats: 

σx σy Aire
67,03 165,63 34879.69

 

La solution d’ArcGIS  10.x

Entre la version 9.x et la version 10.x, ArcGIS a modifié son algorithme en utilisant une des corrections de CrimeStats (racine carrée de 2) sans autre explication ni justification (ArcMap 10.x: Fonctionnement de Directional Distribution (Standard Deviational Ellipse))

Elle est calculée avec les options Yuill + sqrt(2) correction  du plugin et avec divers packages R (ellipse pour 1 écart type ici)

 

Résultats:

σx σy Aire
62,40 154,196 30229.06

Le plugin offre aussi la possibilité d’utiliser la deuxième correction de CrimeStats seule avec l’option Yull + DF correction.
 

L'ellispse de Wang et al. (2015)

Le  nouvel algorithme proposé par Wang et al (2015) se base aussi sur la matrice de covariance, mais en modifiant le cacul  (1/n au lieu de 1/n-1 pour les connaisseurs). Ensuite le traitement est le même, voir le script ellipse_wang.py.

Résultats (c'est le même que celui de Yuill): 

σx σy Aire
44,12 109,03 15114,53

L'important est qu'ils calculent les valeurs de  la classique règle empirique des 3 sigmas pour des distributions multivariées. Ce sont les valeurs approximatives de 39,35%, 84,47% et 98,89% et non 68,27%, 95,45% et 99.73% comme le stipule ESRI.

Conclusions

Que d’ellipses, me direz-vous, mais elles ne se différencient que par les résultats du calcul des axes de l’ellipse et donc de l’aire. Du  fait de la signification statistique des résultats, c’est là où naissent les problèmes et les controverses.

  • dans le cas d’ESRI, il est stipulé que « un polygone d’ellipse d’un écart type recouvre approximativement 68 pour cent des entités» (que ce soit avec les résultats de la version 9.x ou ceux la version 10.x) , en supposant que variables concernées suivent une distribution spatiale normale;
  • Cette conclusion est remise en question par Wang et all (2015) qui opinent que les conclusions d’ESRI correspondent à la classique Règle 68-95-99.7 (3 sigma) des distributions univariées normales, mais pas pour des  distributions bivariées (ou multivariées). Ils proposent donc des nouvelles valeurs: "Obviously, such confusing interpretation may mislead the GIS users to believe the univariate 3-sigma rule remains valid in two-dimensional Euclidean space, or even higher dimensions". Ils calculent des valeurs correctes selon eux;
  • la solution de CrimeStat s'éloigne des précédentes;
  • les ellipses basées sur la seule matrice de covariance sont théoriquement les plus correctes.

Alors quelle est la bonne ellipse ? Le nouveau plugin permet de toutes les figurer (hormis les eclipses de covariance et les axes) et à vous choisir la bonne...

Pour ceux qui ne s’intéressent qu’aux orientations (angles et excentricité), comme moi, elles sont toutes bonnes, mais pour ceux qui traitent les surfaces et leurs interprétations statistiques, c’est autre chose... Il serait nécessaire en tout cas de toujours spécifier la solution retenue comme dans la majorités des articles scientifiques.

Et oui, il n'y a donc pas une seule Elipse de Deviation Standard comme pourraient le penser les utisateurs d'ArcGIS avec leur commande standardisée. Je remercie aussi Håvard Tveite d'avoir tenu compte de mes remarques (j'utilise depuis longtemps ce genre d'ellipse dans un contexte non spatial).

En route pour les ellipses de covariance 3D et les ellipses de Deviation Standard bayesiennes.

Annexe:

Sommaire des résultats obtenus avec les points utilisés

Pour rappel, les coordonnées du point « moyen », les angles et l'excentricité sont les mêmes pour toutes les solutions (77,12° par rapport au N et 0,9144).

solution σx σy Aire 3σ: σ1 spécifié
Plugin: Yuill 44,13 109,03 15114,53 variable
Arcview 3.3 (ArcMap 9.x) 44,13 109,03 15114,53 68,23%
Wang et al (2015) 44,13 109,03 15114,53 39,35%
R avec le package siar 45,67 112,86 16194.14  
Covariance 45,67 112,86 16194.14 39,35%
Plugin:Yuill avec l'option DF 47,40 117,12 17439.85  
ArcMap 10.x 62,40 154,20 30229.06 68,23%
Plugin:Yuill avec l'option sqrt(2) 62,40 154,20 30229.06  
R avec le package aspace 67,03 165,63 34879.69  
Plugin avec l'option "CrimeStat" 67,03 165,63 34879.69  

 

Tous les traitements présentés ont été effectués sur Mac OS X ou Linux avec QGIS 2.14.x, R version 3.x et Python 2.7.x. ArcGIS 10.1 sur Windows a été utilisé pour obtenir des ellipses pour comparer les résultats. LaTeX a été utilisé pour les équations.

Site officiel : Calculating and visualizing standard deviations in two dimensions


Creative Commons License
licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France

by Martin Laloux at June 24, 2016 01:40 PM

Fernando Quadro

Livro: QGIS Design Map

Criar mapas pode não ser uma tarefa tão árdua pra você, mas deixar o mapa com uma aparência agradável e harmoniosa provavelmente sim, isso porque a maioria de nós (analistas de sistemas, geógrafos, cartógrafos, entre outros) não temos muitas noções de design.

Afim de nos ajudar nesse quesito Anita Graser e Gretchen N. Peterson escreveram um livro intitulado “QGIS Design Map” com o objetivo de nos ensinar a utilizando o QGIS elevar nossos produtos cartográficos ao mais alto nível.

qgis-map-design

Com instruções passo-a-passo para criar os mais modernos designs de mapa este livro cobre tudo, desde um estilo básico a técnicas de rotulagem avançadas como contornos iluminados e mascaramento dinâmico.

Se você está querendo aprofundar seus conhecimentos e melhorar a aparência dos seus mapas, vale a pena a leitura.

by Fernando Quadro at June 24, 2016 10:30 AM

June 23, 2016

Jackie Ng

Let's introduce the other major player

My plans for the VSCode map extension now extend beyond just OpenLayers



At this point there are some small oddities:

  • The timeline button SVG has broken hrefs. You can see it from the missing play/pause/rewind graphics.
  • The Cesium InfoBox doesn't work.
This is probably due to a combination of:
  • Running cesium from the local file system
  • The VSCode/Electron webview or Cesium itself imposing sandboxing restrictions that breaks the InfoBox
Still, for the purposes of being able to quick and easily preview CZML content, this is a very nice starting point.

by Jackie Ng (noreply@blogger.com) at June 23, 2016 03:44 PM

Fernando Quadro

Habilitando cache no QGIS para camadas WMS

Quando se está trabalhando no QGIS com camadas através de conexões WMS em alguns momentos pode-se perceber que as camadas estão tendo algum delay, por motivos da rede ou até mesmo do servidor em que estão hospedadas as camadas.

Curiosamente o cache para camadas WMS não está habilitado por padrão no QGIS. Para aproveitar melhor as conexões WMS, WMS-C ou WMTS – e se você tem algum espaço em disco para dedicar – é uma boa idéia habilitar o cache nestes poucos passos a seguir:

Vá até a opção de menu Configurações (Settings) >> Opções (Options):

qgis_wms_cache1

Ao abrir a tela de Opções vá até a aba ” Rede (Network)”. Nessa tela, em “Configurações de cache (Cache settings)”, selecione uma pasta e escolha uma pasta para armazenar os arquivos de cache. Certifique-se de que há espaço livre na pasta para armazenadar os arquivos ao longo do tempo.

Aqui eu escolhi a pasta “/tmp” e criei dentro dela uma nova pasta chamada “qgis_wms_cache”:

qgis_wms_cache2-768x498

Eventualmente podemos mudar o período de expiração padrão das tiles WMS-C/WMTS (horas) para mais de 24 horas.

Aqui eu vou mudar para 24 * 30 = 720 horas, e o tamanho do cache vou aumentar para 250MB (escrito como 250000, uma vez que a unidade utilizada aqui é o kilobytes):

qgis_wms_cache3-768x498

Agora basta pressionar o botão “OK” e fechar a janela e o seu QGIS já estará com a geração de cache habilitada para conexões WMS.

Fonte: GFOSS Blog

by Fernando Quadro at June 23, 2016 10:30 AM

June 22, 2016

Fernando Quadro

Apresentações do 3º QGIS Portuguese User Meeting

O 3º Encontro de Utilizadores QGIS Portugal, foi um encontro informal que teve como tema central o uso do software Open Source QGIS e aconteceu entre os dias 17 e 18 de Junho de 2016, na cidade do Porto (Portugal).

O evento contou com 11 apresentações com duração aproximada de 15 minutos, dois workshops demonstrativos com a duração aproximada de 4 horas cada um e um Hackfest com o objetivo de apresentar o modelo de desenvolvimento colaborativo do QGIS e contribuir efetivamente para o projeto através da realização de traduções, elaboração de documentação, e do reporte e correção de bugs (bug reporting e bug fixing).

As palestras e workshops já estão disponíveis e podem ser baixadas (no formato PDF):

Utilização de ferramentas open source para a caracterização de uma paisagem. O módulo LecoS do QGIS.
O uso combinado de LiDAR, QGIS e LAStools aplicado ao estudo de paisagens arqueológicas
Desenvolvimento de aplicações em QGIS para modelos de gestão de risco
Aplicação SIG open source – MicMac
Urban Traffic Emission Modelling in QGIS – Qtraffic
Expansion of Alien Invasive Plants Along the Roads: a Remote Sensing Approach
Mapeamentos com QGIS de uma Colecção de Pinturas de Adriano de Sousa Lopes do Acervo da Faculdade de Belas Artes da Universidade de Lisboa
“QGIS na Administração Publica Intermunicipal” e “QGIS/QGIS Server – Plano Operacional Municipal – Acesso a dados geográficos em modo OFFLINE”
O uso de software open source na investigação e desenvolvimento florestal
Processo de implementação de QGIS como ferramenta de trabalho na Câmara Municipal de Oeiras
O que há de novo no QGIS 2.12-2.16
Iniciação ao QGIS (Workshop)
Análise Espacial com QGIS + dataset (Workshop)

by Fernando Quadro at June 22, 2016 10:30 AM

gvSIG Team

Towards gvSIG 2.3: Bing Maps, Google Maps and Google Street View

Let’s have a look to a couple of new features that will be included in next release gvSIG 2.3.

Users will have access to data from Bing Maps and Google Maps, being able to select between different geographic information types they offer.

Although it can be assumed that everyone knows, Google Maps is a map service created by Google while Bing Maps is the equivalent one created by Microsoft.

Bing Maps allows data access in several modalities: street (road), satellite imagery (aerial) and labeled images. On the other hand, Google offers street (road), satellite, terrain and hybrid options.

Google Street View provides panoramic street-level (360-degree horizontal and 290-degrees vertical), allowing users to see sectors of the city according to selected coordinates.

You can have a look to this video that illustrate these new tools that will be shortly available in gvSIG:


Filed under: english, gvSIG Desktop Tagged: Bing Maps, Google Maps, google street view, gvSIG 2.3, web maps

by Giuliano Ramat at June 22, 2016 06:52 AM

June 21, 2016

gvSIG Team

Servicios de formación en la Asociación gvSIG

Desde la Asociación gvSIG ofrecemos diversos cursos para usuarios y desarrolladores, tanto de la aplicación gvSIG como de geomática libre, y cuyos beneficios revierten en el proyecto gvSIG, con desarrollo de nuevas funcionalidades, corrección de errores…

Servicios_de_formacion

Dentro de las modalidades disponibles, aparte de la presencial (con desplazamiento de profesor) y online (a través de la plataforma gvsig-training.com), que se están llevando a cabo durante los últimos años, una novedad importante es que ahora se ha incluido la modalidad webinar, donde se imparte el curso en directo a través de una plataforma online de vídeo, y en el que hay interacción entre el tutor y los alumnos. De esa forma se evitan los costes de desplazamiento y manutención del profesor.

Dentro de los cursos de gvSIG disponibles existe por un lado uno genérico para usuarios, y por otro lado diversos cursos aplicados a distintas temáticas como Medio Ambiente, Fauna, Espacios Naturales Protegidos, Gestión de Pavimentos y Vialidad, y también sobre Gestión Municipal. Todos ellos de matrícula abierta, por lo que el alumno puede matricularse cuando desee.

Con el curso de usuario genérico, así como con los de Medio Ambiente, Fauna y Espacios Naturales, se obtiene el Certificado gvSIG Usuario Básico. Con los otros dos cursos el alumno obtiene créditos que le permiten obtener el Certificado gvSIG Usuario Experto (completando un total de 100 créditos de los cursos que convalidan para dicho certificado).

Otro tipo de cursos ofrecidos por la Asociación gvSIG son los relativos a Geoprocesamiento y Análisis Espacial. Dentro de estos se encuentra el curso “Geoprocesamiento Avanzado sobre gvSIG”, con una temática diversa sobre análisis ráster y vectorial, modelos digitales de terreno, perfiles, visibilidad…, y aparte cursos más pequeños sobre algunos de los temas del curso anterior en caso de que el usuario esté interesado en una temática concreta (Análisis del Terreno e Hidrológico, Análisis de Visibilidad e iluminación, Análisis de Perfiles y Secciones transversales, o Análisis de Costes y Rutas óptimas.

Todos estos cursos tienen edición en español y en portugués, y dan una serie de créditos para obtener el Certificado gvSIG Usuario Experto.

Dentro de las extensiones de gvSIG, existen varios cursos como son el de Análisis de Redes con gvSIG Desktop, Navtable y Normalización de Tablas, Publicación de Servicios OGC, Análisis Geoestadístico con gvSIG y Sextante, Uso, creación y gestión de metadatos de información geográfica, y gvSIG 3D y animación. Todos ellos convalidan para el Certificado gvSIG Usuario Experto.

Respecto a los cursos relativos a geomática libre, se ofrece uno sobre ”Bases de Datos Geoespaciales: PostgreSQL – PostGIS”, el cual tiene dos niveles disponibles (básico y avanzado).

Finalmente, se ofrecen cursos personalizados conforme a las necesidades de los solicitantes. Por ejemplo, se han llevado a cabo cursos sobre gvSIG aplicado a Oceanografía, a Protección Civil, a Topografía…, o incluso cursos más cortos sobre unas funcionalidades concretas como puede ser el cambio de sistemas de referencia y conversión de ficheros a KML para cargar en Google Earth, incluyendo descarga de datos de servidores públicos de cartografía.

Para la modalidad online de los cursos, puedes hacer directamente el pedido en el portal gvsig-training.com. Entrando en el curso deseado verás un enlace para hacer el pedido, donde te indicará las instrucciones a seguir para realizar el pago. Así mismo, la mayoría de cursos disponen de ciertos descuentos, así como de subvenciones del 100%. Puedes ver dicha información dentro de cada curso.

Si deseas formación presencial o en modalidad webinar, o para cualquier otra duda relacionada con formación, puedes contactar con nosotros directamente escribiéndonos a info@gvsig.com.

Realizando estos cursos a través de la Asociación gvSIG estarías contribuyendo al crecimiento de este proyecto.


Filed under: community, gvSIG Desktop, portuguese, spanish, training Tagged: formación

by Mario at June 21, 2016 08:56 AM

June 20, 2016

Free and Open Source GIS Ramblings

QGIS workshops at FOSSGIS

We are looking forward to a hot geo summer here in Central Europe with both the German FOSSGIS (this year in conjunction with the annual AGIT conference) and the international FOSS4G just a few weeks away. It’s going to be exciting, and I still have a lot of talks (and a keynote) to prep for both events ;-)

If you speak German and want to enhance your geo skills, the FOSSGIS program offers some great opportunities and there is still the chance to sign up for a couple of great FOSSGIS workshops:

Of course the program also features many non-QGIS workshops. If I’d have to pick one of them, it would most certainly be Marc Jansen’s and Andreas Hocevar’s OpenLayers 3 workshop because it’s always great to get the latest information first hand, directly from the developers.

Online registration closes on June 25th.


by underdark at June 20, 2016 08:25 PM

gvSIG Team

Towards gvSIG 2.3: LiDAR data

In gvSIG 2.3 users will be able to access a new source of data that has been using more and more, the LiDAR data. gvSIG 2.3 drivers provide to read and write LiDAR in gvSIG according to LAS specification. A cropping tool will be also provided to export a subset of LIDAR data.

Drivers

User will have two options for working with LAS files, based on gvSIG implementation of two different libraries, each one with its advantages:

  • JGrasstools based provider that is read / write.

  • Whitebox based that is read-only provider, but currently offers better performance than the one based on Jgrasstools.

Clarified/simplification

Both drivers include two parameters “clarified” (simplification), which let you read a subset of the total points available in the LAS file. Simplification allows quickly draw huge files at small scales (where a level of detail as high as that provides the file is not required):

  • ThinningDivisor: reads 1 point out of n items (1 / n), for example when thinningDivisor = 10 it loads 10% of the total available points

  • ThinningResolution: load approximately n dots per square unit of the layer; for example, if thinningResolution = 0.0001 means that it loads 0.0001 points / m2 (assuming that in this case layer projection units are meters), or that is the same, 100 points / km²

Attributes

LAS files have a set of mandatory fields (fixed) and other optional depending on point data format as specified in the LAS file header.

Mandatory fields are:

  • CLASSIFICATION (land cover) 
  • POINTX (x coordinate of the point)
  • POINTY (coordinate of the point)
  • POINTZ (z coordinate of the point, useful to symbolize elevations)
  • INTENSITY (intensity)
  • RETURNNUM (point return number)
  • NUMBEROFRETURNS (number of returns for this laser pulse) 

Optional fields are:

  • COLOR (color point, expressed as a whole “long” Java containing the RGB value)
  • TIME (absolute time capture, expressed as generated by Data.getTime ())
  • WEEKTIME (relative time capture, expressed as a weekly GPS time) 

Export tool

Cropping tool allows you to choose a data subset to be exported to a new LAS file.

The tool lets you choose a geographic extension to filter the data (only points that fall within the selected geographic extension will be exported). The possible options are:

  • No filter by geometric extension

  • Filter data using extension visible in the active view.

  • Filter using a geometric extension specified by the user.

It is important to note that if users load the layer in the view using data options “clarified” (simplification), the export tool will act according to these options, exporting only the simplified version of the data.

To make this topic easier to understand, you can watch a couple of videos related to the LiDAR data management in gvSIG.


Filed under: english, gvSIG Desktop Tagged: gvSIG 2.3, LAS, LiDAR

by Giuliano Ramat at June 20, 2016 05:43 PM

gvSIG Team

Camino a gvSIG 2.3: Soporte vectorial en Vistas 3D y extrusión

gvSIG es uno de los pocos SIG en software libre que puede presumir de disponer de Vistas 3D, gracias a la integración de gvSIG con el software NASA World Wind. En gvSIG 2.3 vamos a tener una serie de mejoras que van a dar a los usuarios nuevas herramientas para trabajar con información geográfica en 3D.

Entre estas mejoras se encuentra la extrusión y para ello era necesario desarrollar el soporte de datos vectoriales en 3D (hasta ahora las capas vectoriales se mostraban rasterizadas en Vistas 3D). Veamos en detalle estas mejoras…

Datos vectoriales

En gvSIG 2.3 podremos seleccionar el modo de visualización de los datos vectoriales en Vistas 3D. Se mostrarán tres modos diferentes de cargar una capa vectorial:

  • Rasterizado: la capa vectorial de la Vista 2D será rasterizada como una imagen que se mostrará en la Vista 3D (como ocurría en gvSIG 2.2).
  • Vector: los elementos de las capas vectoriales de la Vista 2D serán transformados en vectores 3D y cargados en la Vista 3D.
  • Extrusión: los elementos de la capa vectorial de la Vista 2D serán transformados en vectores 3D y cargados en la Vista 3D, aplicando una extrusión para obtener un efecto de volumen.

Modo Vector

En el modo vector podremos seleccionar la altitud de los elementos por dos factores (o la suma de ambos): La tercera dimensión de la geometría, en caso de que sea una capa 3D (por ejemplo un shapefile 3D) o un parámetro o constante de altura.

Se podrán aplicar 3 modos de elevación, cada uno de los cuales aplicará la altitud de un modo diferente:

  • Clamp to ground (Fijado al terreno): los elementos se superpondrán al modelo digital del terreno existente en la Vista 3D.
  • Absolute (Absoluto): la elevación de los elementos vectoriales estará dada por la altitud, definida como la altura sobre el nivel del mar.
  • Relative to ground (Relativo al terreno): la altitud de los elementos vectoriales estará dada por la altura, definida como la altura relativa sobre el terreno.

3D_vector_gvsig_02Un ejemplo de como se muestra la opción clamp to ground:

3D_vector_gvsig_03En este caso se puede observar que en varias partes el modelo digital del terreno recubre a la capa vectorial, debido a la diferencia de alturas. Cuando ocurra esto podríamos poner el modo relative to ground y aplicar una altura constante para visualizar los datos sin solapes:

3D_vector_gvsig_04

Extrusión

Se denomina extrusión al proceso de expansión vertical de un elemento 2D para generar un objeto 3D. Permite generar una representación tridimensional a partir de entidades bidimensionales. Un ejemplo típico de extrusión es su aplicación a polígonos de edificios a partir de un atributo de altura, obteniendo formas realistas de edificios. Los tres tipos de geometría básicos -puntos, líneas y polígonos- admiten extrusión.

La interfaz que encontrará el usuario es similar a la siguiente:

xxxLa altitud de los elementos podrá ser definida por cuatro factores: La tercera dimensión o coordenada Z de la geometría. Un campo altura seleccionado de la tabla de atributos. Un parámetro de altura constante. O, por último, un factor de exageración vectorial, el cual es una multiplicación de un determinado factor multiplicado por la altura.

Habrá disponibles 2 modos de elevación, los cuales considerarán la altitud de manera diferente:

  • Absolute: la elevación de los elementos vectoriales estará dada por la altitud, definida como la altura sobre el nivel del mar.
  • Relative to ground: la altitud de los elementos vectoriales estará dada por la altura, definida como la altura relativa sobre el terreno.

Por ejemplo, aplicando la modalidad relative to ground option y seleccionando un campo de la tabla de atributos que se correspondiera a la altura de los edificios, obtendríamos algo así:

3D_vector_gvsig_06

Otros ejemplos

Capa de lineas de curvas de nivel con geometrías 3D, utilizando el modo de extrusión y aplicado una altura adicional de 50 metros:

3D_vector_gvsig_08La misma capa sin extrusión se mostraría del siguiente modo:

3D_vector_gvsig_09Capa de puntos:

3D_vector_gvsig_10Y para acabar un pequeño vídeo:


Filed under: gvSIG Desktop, spanish Tagged: 3D, Extrusión, gvSIG 2.3, gvSIG 3D, World Wind

by Alvaro at June 20, 2016 11:34 AM

Fernando Quadro

Vídeos da QGISConf 2016

A QGISConf quer ser uma conferência de referência, e um ponto de encontro para os usuários e desenvolvedores que vivem em torno do QGIS, a fim de trocar experiências e compartilhar conhecimentos.

Se você não pôde ir a Girona (Itália) para a conferência (QGISConf) deste ano, aqui está sua chance de recuperar o atraso e assistir as muitas apresentações e oficinas que fizeram parte do programa desta conferência que ocorreu entre os dias 25 e 26 de maio:

2nd International QGIS User and Developer Conference Opening Session
Let me tell you about QGIS
Migrating Public Sector Organizations to QGIS
Think you know QGIS? Expert tips to revolutionise your workflow!
Develope without developing
Using QGIS in an Advanced GIS course: Instructor and Student Perspectives
qWAT : a QGIS-based project for water network management
QGIS improvements: from LT 2.8 to LT 2.14
QGIS Processing Framework overview
Processing is not an analysis framework
QGIS’s New Authentication System and Plugins
Contributing to QGIS 101
Visualizing Flood Risk Model Results in QGIS
QGIS Virtual Layers: mix them all data!
Lizmap Feature Frenzy
The State of OGC interoperability with QGIS (client and server)
Teaching and using QGIS for Geomatics Apprentices
GIS at use in municipality of Frederikssund
THREDDS Explorer plug-in, bringing meteoceanographic operational data into QGIS

Fonte: GIS Ramblings

by Fernando Quadro at June 20, 2016 10:30 AM

gvSIG Team

Towards gvSIG 2.3: Reproject 2D View into a 3D View

In the next coming release of gvSIG 2.3, several improvements (and very striking) related to 3D views will be provided. One of the most important one will be the possibility to reproject a 2D view 3D view.

In gvSIG 2.2 3D Views can be applied only to 2D Views in EPSG: 4326. This constraint will disappear in the next version, and user can work on any projection without limitation in the use of 3D Views.

Here it is the video where this new function is shown:


Filed under: english, gvSIG Desktop, testing Tagged: EPSG, gvSIG 2.3, Reprojection

by Giuliano Ramat at June 20, 2016 09:34 AM

GIS for Thought

Glasgow Regions Mapped – Progress Update 1

You can map your response HERE.

You can read the initial post at: Mapping Glasgow Districts

We have had some great progress on the mapping so far. There have been 367 regions mapped to date. However, as mentioned in the original post, there are a huge number of regions in Glasgow so even with over 300 responses many regions have only one response and others are still unmapped. But in the hopes of encouraging some more responses I felt it would be nice to show what progress has been made to date.

Statistics so far:
Unique region names so far: 241

Most mapped regions:
City Centre – 10
Finnieston – 9
Merchant City – 9
Dennistoun – 8
Partick – 7
West End – 7
Garnethill – 6
Hyndland – 6
Woodlands – 5
Hillhead – 5
Mount Florida – 5

Regions so far. Click for PDF version.
map_so_far

We can see that there are still quite a few regions that have had the same number of responses with multiple region names.

We can look at what these responses have been, in an interactive map:


Full Screen.

We can see that the West End in general has been the target of a large number of responses, so we can drill in a little further:

west_end1

Extent of the west end:

West End

Individual regions:

Anderston

Anniesland

Blairdardie

Broomhill

Charing Cross

Dowanhill

Drumchapel

Finnieston

Firhill

Garrioch

Hillhead

Hyndland

Jordanhill

Kelvingrove Park

Knightswood

Maryhill

Not Partick

Park Circus

Partick

Partickhill

Scotstoun

Thornwood

West Maryhill

Whiteinch

Woodlands

Yoker

Yorkhill

A final note, there have been some creative responses as well, as expected. But the flagging system on the mapping page has worked incredibly well.

A huge thanks if you have responded already. I would be grateful if you could share this on either Facebook, Twitter, or anywhere else. The more responses that are submitted, the better the end result.

Happy to take on suggestions as well.

Map a region!

by Heikki Vesanto at June 20, 2016 09:00 AM

June 19, 2016

GIScussions

The Invincibles – adventures with QGIS2Web

Invincibles wall
This is a maps and Arsenal post with a tiny bit of geekery added in. In the 2003-4 season Arsenal won the Premier League title while going the whole season unbeaten (actually including a couple of games in the preceding season and several in the following season they went 49 games unbeaten) a record that is unlikely to be equalled.

My favourite Arsenal blogger is a guy called Andrew Managan who blogs at Arseblog, he just ‘gets it’ as far as I am concerned and has been one of my daily reads for a heck of a long time. In 2014 Andrew Mangan teamed up with Andrew Allen to write Together, a book celebrating the 10th anniversary of that amazing season. Brilliant book, every Arsenal fan should read it and if you aren’t an Arsenal fan don’t worry the rest of this post is about maps and geekery so don’t give up yet.

I had been playing around trying to come up with an idea of how to map the Invincibles season and had produced some basic QGIS maps with the results etc. Then I had an idea and I approached Andrew M to ask whether I could use some of the content from Together as part of a web map and hey amazingly he said go for it, then I asked Ken Field for some help to produce an ESRI Story Map using the content and he being a pal and a football nutter also said go for it. So I went for it and by the beginning of 2015 I had a lot of the data pulled together and Ken had a Story Map template for me to drop it into, then life and work intervened and the project went onto the back burner.

Last week I was at FOSS4GUK and one of the hot topics was QGIS2Web a plugin developed by Tom Chadwin that makes it ridiculously easy to publish a web map. Unfortunately, as Ken Field has pointed out on numerous occasions, being able to make a web map does not mean that you will make a good map. The results below are a starting point, they certainly don’t get anywhere near to being a good map. The map shows the locations of the Premier League grounds, the dates and results of the matches and some highlights from Together (and also from Andrew’s blog and links to video and images – more to complete on these).

You can use the search box to find the away grounds if you put in a town name. There are some problems with the info popups (too big) so to read the full content you will need to pan from outside of the pop up to see the rest of the content, far from ideal I know.

What follows is a short summary of the wrestling with data and QGIS and QGIS2Web that got me this far. I have learnt a fair bit on the way and have a mountain more to learn but that’s the fun of teaching yourself.

Data to desktop map

Finding the data was pretty easy thanks to Google. I got the season’s results from Wikipedia where I also found the locations of Premier League Stadiums on Wiki. Joining the 2 together in a spreadsheet was easy enough and then I had each match in a table with coordinates of the ground except that I then had the home games showing at the away grounds but a little sort, copy and paste solved that.

Getting text out of the Kindle edition of Together was a struggle to say the least but eventually I found a helpful suggestion on an Amazon forum. I loaded the book into the Kindle app (which disables copy functionality) and highlighted the paragraphs that I wanted to use (your highlights get saved to your account). Then from the Kindle web client I was able to load my highlights and copy and paste them into the spreadsheet with the match details. Not something you are really meant to do but I had Andrew’s permission to use excerpts from the book so I thought that would be ok.

Finally I could pull the whole thing into QGIS and map using the coordinates. Sounds simple when you read this but there was more trial and error than I would have liked. I then worked out how to use an SVG icon as a marker and set the marker to be a football (red of course, but more of that later). Then I realised that I had 19 markers centred on the Highbury ground (our home matches) so I did some shifting to space them out around the pitch which was fiddly and not necessarily the most elegant way to present the data. I added an OSM base map and that was about it for the early 2015 version.

Desktop to web map

This afternoon I thought I would have a try at publishing my QGIS project through QGIS2Web. It’s pretty damn simple but I still needed a fair number of iterations to get it right or even close to right. A few things I learnt that may help others:

  • QGIS2Web offers 2 output options, Leaflet and OpenLayers. I don’t why but it seems that the Leaflet option is more tolerant of the quirks of exporting QGIS projects, it also has a few more neat features like clustering markers which is why I chose it.
  • Complex labels based on expressions don’t seem to come through to the web projects and I also couldn’t get label styling and placement to work so I reverted to just labelling with the opposition team name. On the other hand, label visibility thresholds did come through. If I could solve the labelling I would have used labels to show more info and styled them up elegantly.
  • I coloured the markers in red in the QGIS project but they come through as black in the web project, another thing to research.
  • I experimented with the min and max zoom levels and eventually got them about right (5-20). The preview works very well and allows you to tweak settings before you export your project.
  • Popups were a nightmare and I still haven’t got them right. That was because I have got some very long text strings for the excerpts from Together. When you click on a marker the pop up can be very very long and pans the map a long way from the marker. I discovered that there are Leaflet options to set the Max height of the pop up window which would create a scroll bar in the popup rather than the map zooming off into space but I couldn’t find an example of how to insert this option. I’d also like to make the pop up wider to be easier to read. After several fruitless hours of searching I posted a question on GIS StackExchange so hopefully I will be able to solve this one soon.
  • Combined with the popup problem I discovered that the popup on hover option prompted some bizarre behaviour so I switched that off (it works fine if the popups are small)
  • I set a title for the map which will show up in your browser tab by putting <title>The Invincibles, Arsenal 2003-4</title> into the html file. It would be nice to have that floating over the map, something else to learn how to do.

So that’s about it for today, the map is here feel free to link to it. Hopefully it will improve when I solve the popup problem, red markers and the labelling. To be honest I don’t think this will ever be a work of great cartographic merit but I am learning a lot about QGIS2Web and maybe the next map will be better.

by steven at June 19, 2016 06:20 PM

June 18, 2016

Markus Neteler

Gaining more WMS speed through enabling the QGIS cache directory

Interestingly the WMS caching is not enabled by default in QGIS. To better enjoy WMS/WMS-C/WMTS connections – if you have some disk space to dedicate – it is a good idea to enable the cache in these few steps:

Go to the menu entry Settings >> Options:

Enabling the QGIS WMS cache - step 1

Enabling the QGIS WMS cache – step 1

Go to tab “Network“. Therein, in “Cache settings“, select the “Directory” and choose a folder for the cache files. Be sure that there is free space for lots of megabytes can be stored there over time. And this directory should ideally be located on a fast disk (if you have several).

Here I choose the existing “tmp/” folder in my HOME directory and create inside a new folder “qgis_wms_cache”:

Enabling the QGIS WMS cache - step 2

Enabling the QGIS WMS cache – step 2: create new “qgis_wms_cache” cache folder

Eventually we change the “Default expiration period for WMS-C/WMTS tiles (hours)” to more than 24 hours (as it would be rather useless…). Here I change to 24*30 = 720 hours. And the cache size we increase as well, here to 250MB (written as 250000 since it is to be given in kilobytes):

Enabling the QGIS WMS cache - step 3

Enabling the QGIS WMS cache – step 3: increase expiration period for tiles and cache size

Now we press “OK” and close the dialog. Time to try out a WMS service, zoom back and forth… and:
Enjoy!

The post Gaining more WMS speed through enabling the QGIS cache directory appeared first on GFOSS Blog | GRASS GIS Courses.

by neteler at June 18, 2016 09:44 PM

GeoTools Team

GeoTools 14.4 released

The GeoTools team is pleased to announce the release of  GeoTools 14.4:

This release was made by Andrea Aime (GeoSolutions) and Alessandro Parma (GeoSolutions) in conjunction with GeoServer 2.8.4.

GeoTools 14.4 is the latest stable release of the 14.x series and is recommended for all new projects.


New features available in this release:
  • [GEOT-5375] - Add a group by visitor (backport 14.x)


For more details on the improvements and fixes, please refer to the release notes for GeoTools 14.4


About GeoTools 14

GeoTools 14 highlights:
For more information see the  14-M014-M114-beta14-RC1, 14.014.1, 14.2 and 14.3 release notes.

by Alessandro Parma (noreply@blogger.com) at June 18, 2016 01:49 PM

GeoServer Team

GeoServer 2.8.4 released

The GeoServer team is pleased to announce the release of GeoServer 2.8.4. Download bundles are provided (binwardmg and exe) along with documentation and extensions.

GeoServer 2.8.4 is the latest stable release of GeoServer and is recommended for production deployment. This release is made in conjunction with GeoTools 14.4. Thanks to all contributors. Fixes and new functionality include:

  • Security fix for a reflected XSS vulnerability
  • Fix for potential out of memory state when rendering lots of very small tiles
  • Fix for an embedded GeoFence issue that caused user settings to be lost after a restart
  • Improved ImageMosaic creation and update speed for databases with many tables
  • Monitoring extension fixes for RemoteUser logging and monitoring hibernate extension causing startup issues to GeoServer
  • CSS styling extension related fix: A bug in CSS to SLD conversion led in some cases to performance issues with the generated SLD
  • PDF printing related fixes to properly render SLD “shape://horline” symbol, prevent invalid polygon generation and avoid potential out of memory state or very large files when handling large outputs with dense hatch fills
  • And much more, see all the 24 tickets resolved in the release notes

Thanks to Alessandro Parma (GeoSolutions) and Andrea Aime (GeoSolutions) for this release.

About GeoServer 2.8

Articles, blog posts and presentations:

by Alessandro Parma at June 18, 2016 01:42 PM

June 17, 2016

GIScussions

May the FOSS be with you

FOSS4GUK

I travelled home from FOSS4GUK in Southampton yesterday afternoon on something of a high, we had had a great 3 days and at the end England had scraped a sneaky win against Wales in the 92nd minute (seeing Gareth Bale cry can’t be bad, can it?). Then I saw the awful news about Jo Cox and I was flattened, what the fuck is wrong with our world? This morning I realised that whilst our little conference is pretty trivial when a family (and a nation) are grieving, there were a lot of wonderful people doing something pretty damn good over the last three days and that was worth celebrating. Apologies for the overly mawkish start.

FOSS4G UK was a great example of what makes the Free and Open Source Software community such a remarkable phenomenon. It is largely down to the people involved – the organisers, the sponsors, the speakers and teachers, the participants and anyone else I may have missed off the list.

A small group of volunteers somehow managed to organise a big event, 3 days of maps and open source, 170+ delegates, 35 talks, 13 workshops, an unconference, a hack, a codesprint and (of course) a blitzer party. Everyone who attended should say thank you to Abi Page, Aileen Heal, Andrew Bailey, Antony Scott, Barry Rowlingson, Ian Turton, Jeremy Morley, Liz Scott, Matt Travis, Matt Walker, Ross McDonald, Simon Miles and William Allbrook.

There is one person who I left off that list because she deserves more than thanks, Jo Cook deserves our admiration and colossal appreciation for her hard work, calmness and focus to steer the event to such a success.

FOSS4GUK

Jo has been contributing to OSGeo for over a decade, evangelising, writing code and encouraging others to participate, she has been an OSGeo board member, the founder and chair (twice) of OSGeo:UK and was the vice chair of FOSS4G 2013 and created and maintains Portable GIS. That’s some record of service to our community! I can almost hear my modest friend Jo tutting as she reads this, well it needed to be said (and publicly).

Thanks also has to go to all of the sponsors without whom the event could not have been staged as well or at such reasonable prices. Their generosity also meant that we could subsidise those who could not afford the full ticket price and we were able to offer free places to 8 students. Particular thanks go to those sponsors who don’t have an obvious business benefit from exposure to the audience but who wanted to support us because they think FOSS4G is a “good thing”. Thanks to the OS who donated their fabulous Business Centre because they appreciate the benefits that their business gets from Open Source and want to put something back. I had a fascinating conversation with Charles Kennelly, the CTO of ESRI UK, who told me that he was keen to recognise the dependencies within ESRI’s software on a range of Open Source libraries and also stressed how the competition between proprietary and open helped both to “up their games” (I have paraphrased slightly, so apologies to Charles). And thanks to all of the sponsoring companies who are part of the community, competitors and friends. The full list of sponsors is here.

Thanks to all of the people who presented talks and workshops, no one could hear them all (4/5 strands for most of the time) but it appeared that all were well attended and highly regarded. I attended Jo Cook’s workshop on getting started with GitHub, it’s astonishing how much you can learn in a couple of hours from someone who knows their stuff, now if only I can remember to init, clone or was it fork?, commit and make a pull request! I think the person who called me an Old Git was a little unfair but basically correct. What was apparent was that the combination of talks and workshops worked well and enabled some people to justify their attendance on the basis of skills refresh/development. One lesson that I learnt from observing those of the team running the workshops is that

However much you publish the pre-requisites for a workshop, people will turn up without having read them, without having downloaded the software/data or created the account and even without the right type of machine (at least one workshop relied on a Windows OS to run ‘Portable GIS’)

If you don’t RTFM before attending a workshop, don’t expect everyone else to wait for you to try and download software packages on flaky conference wifi or complain that you can’t participate because you don’t have a DVD drive!

You can look at the programme of talks and workshops here and here, we will try to get the slides and workshop notes linked from the site in the next week.

On Tuesday evening we had a great beer/cider and food party at the Dancing Man Brewery with a #FOSS4GeoTune disco run by Simon Chapman. Throughout the build up to the event we were promoting the party as a great way to let your hair down (if you have any left) and meet people, tickets were slow selling for some reason and as we got near to the deadline for catering we took a gamble and booked 75 places even though we hadn’t sold that many. Of course come the day and loads of people are coming up to me saying “I forgot to book are there any places left?” but by then we were sold out. Lesson for everyone, make the organisers lives easier and book early (conference, party and anything else that needs booking and preplanning) and RTFM i.e. when it said there was limited parking at OS, that was because there really was limited parking at OS!

On Thursday we hosted a code sprint lead by the team from Lutra and Tom Chadwin the driving force behind the wonderful QGIS2Web. Loads of good stuff got done. At the same time there was a hack lead by Ant Scott on HXL (pronounced hexel) which stands for Humanitarian Exchange Language. I sat in on this even though I can’t script, code or wrangle XML, I learnt a lot, wrestled with the complexities of humanitarian data while struggling to make a half decent map and discovered a bug in QGIS. Ian Turton and I report the bug and today it had been fixed, how f’ing awesome is that?

I did subsequently manage to use the QGIS2Web plugin to share the crap map that I had wrangled out of the humanitarian data, the maps not great but being able to get from QGIS to the web in 10 minutes is stunning! If the map doesn’t appear below then you can play with it here

 

And then to finish off the final day there was this

Gareth Bale’s misery after England’s winner goes in with thanks to www.arseblog.com

Who isn’t going to enjoy that?

So what’s my take away from three days of FOSS4G UK?

A lot of people are contributing to FOSS4G, writing code, writing docs, fixing bugs, organising events, helping each other and helping others. Some of us contribute because it’s our job, some of us contribute because we just plain love it, most of us do both. FOSS4G is a passionate community of incredibly talented people who have created awesome software that helps to deliver some important and worthwhile solutions to the public sector, industry and to humanitarian and other NGO’s.

Did I mention that it is also a lot of fun?

Jeremy Morley in ‘that’ t-shirt

In her welcome on the first day Jo said that part of the organising team had been on the organising team for FOSS4G 2013 and that it had taken us 3 years to recharge the batteries and get back into gear to run FOSS4G UK. I hope that it won’t be that long before the next FOSS4G UK.

May the FOSS be with you

FOSS4GUK

There are a some more pics from FOSS4GUK here

by steven at June 17, 2016 04:21 PM

Jackie Ng

Announcing: vscode-map-preview 0.4.0

Today I pushed out a new version (0.4.0) of the vscode-map-preview extension. You might have already gotten a prompt from Visual Studio Code to auto-update to this version.

Here's some new features in this version.

Configuration Options

This version adds a bucket-load of configuration options around:
  • Controlling the style of vector features in your preview layer
  • Controlling the style of selected features in your preview layer
  • Controlling the display of the mouse coordinate tracker
  • Controlling the default base layer to use
Once saved to your user settings, these updated settings take effect on the next preview



Preview (with specific projection)

When previewing a file format, the source project can generally be inferred. For example, KML will always be EPSG:4326, for GeoJSON it should figure it out if you have a crs property on there.

But then you have formats like Well-Known Text (WKT), which we can render a preview of, but without proper contextual information such as projection, the data may not be placed where you expect it to be.

For example if we preview WKT as-is:


Because there is no projection context in the data itself, the coordinates are assumed to already be in EPSG:3857, and means the point lies just off the shores of Null Island, which in actuality, the above coordinates are actually supposed to be EPSG:4326 and is supposed to be the central business district of Melbourne, Australia.

To fix this, we need a way to declare that the data we're previewing is actually of a specific projection, which is what the new Map Preview (with projection) command gives us. It's just like the regular Map Preview command, but provides an input prompt for entering the proper EPSG code for this data.


Which will then be used as the projection of the data about to be previewed, ensuring the data is placed at the right location.


As an aside, you can put away that SQL Server Management Studio. VSCode with this extension is way more quicker and lightweight way for easy WKT visualization.

One caveat is that for this new command the only supported projections are:

  • EPSG:4326
  • EPSG:3857
I'll need to add custom projection support in order to be able to add support for more projections beyond the above two projections.


Other Changes

This version includes fixes to allow for subsequent map previews to work better and fixes various CSS issue with the map preview.

If you haven't already, check out and install the extension on the Visual Studio marketplace.

by Jackie Ng (noreply@blogger.com) at June 17, 2016 01:57 PM

gvSIG Team

Counter for identical registers in a field, using Scripting in gvSIG

If we have an attribute table in gvSIG we can obtain the number of registers for each different value of a field, how many times they are repeated.

For that we will have to create a new script in gvSIG, from the Tools->Scripting->Scripting Composer menu.

Once it is created, naming it as we want, we copy this source code on it:

from gvsig import *
import commonsdialog
from org.gvsig.andami import Utilities
import os, time

from gvsig import *

from org.gvsig.app.project.documents.table import TableManager

def loadTable(format, **parameters): 

    try:
        application = ApplicationLocator.getManager()
        datamanager =  application.getDataManager()
       
        # Loding the data store
        store_parameters = datamanager.createStoreParameters(format)
        copyToDynObject(parameters, store_parameters)
        store = datamanager.openStore(format, store_parameters)       

        # Creating a Table document and initialize with the data store
        project = currentProject()
        table = project().createDocument(TableManager.TYPENAME)
        table.setStore(store)
        table.setName(store.getName())

        # Add the Table document to the project
        project().addDocument(table)
       
    except Throwable, ex:
        raise RuntimeException("Can't load table, "+ str(ex)) 
 
    return table

def loadDBF(dbffile):
  table = loadTable(format="DBF",DbfFile=dbffile)
  return table

      
def getTempFile(name, ext):
    tempdir = Utilities.TEMPDIRECTORYPATH
    if not os.path.isdir(tempdir):
      os.makedirs(tempdir)
    t = time.time()
    f = os.path.join(
      tempdir,
      "%s-%x%x%s" % (name,t,(t-int(t)) * 10000,ext)
    )
    return f
    
def main(*args):
    print "Count values"
    table = currentTable()
    field = str(commonsdialog.inputbox("Name of the field"))
    try:
        features = table.features()
    except:
        commonsdialog.msgbox("Table not opened")
    count = dict()
    for f in features:
        ff = str(f.get(field))
        if ff in count.keys():
            count[ff] += 1
        else:
            count[ff] = 1
    print count
    sch = createSchema()
    sch.append('ID','STRING',15)
    sch.append('COUNT','INTEGER',20)
    dbf = createDBF(sch, getTempFile("count"+field,".dbf"))
    print type(dbf())
    print "full name: ", dbf.getFullName()
    #Insert table data

    dbf.edit()
    for k,v in count.iteritems():
      f = dbf.createNewFeature()
      f.set('ID',k)
      f.set('COUNT',v)
      dbf.insert(f)

    dbf.commit()

    d = loadDBF( dbf.getFullName())
    print dbf.getFullName()
    return

Finally we save the script.

Then from the View in gvSIG we put the layer that we want to use for the calculation active, and we open its attribute table. After that, we open the Scripting Launcher (Tools->Scripting->Scripting Launcher menu).

Double-clicking on the script that we had created, a new window will be opened, where we have to write the name of the field over which we can apply the counter. After accepting a new table will be created with the results. We will open the Project Manager (from Show menu), and we will have the new table at the “Table” document.

Counter_eng

That table is a temporary element, so we will have to export it to a dbf file in order to have it on disk (Table->Export to menu).

 

 


Filed under: development, english, gvSIG Desktop, scripting

by Mario at June 17, 2016 11:13 AM

gvSIG Team

Contar registros iguales en un campo con Scripting en gvSIG

Si disponemos de una tabla en gvSIG podemos obtener el número de registros que hay por cada uno de los distintos valores de un campo, la cantidad de veces que se repite cada valor.

Para ello tendremos que crear un nuevo script en gvSIG, desde el menú Herramientas->Scripting->Editor de Scripts (este menú se llama “Scripting Composer” hasta la versión 2.2).

Una vez creado, con el nombre que deseemos, copiamos el siguiente código en él:

from gvsig import *
import commonsdialog
from org.gvsig.andami import Utilities
import os, time

from gvsig import *

from org.gvsig.app.project.documents.table import TableManager

def loadTable(format, **parameters): 

    try:
        application = ApplicationLocator.getManager()
        datamanager =  application.getDataManager()
       
        # Loding the data store
        store_parameters = datamanager.createStoreParameters(format)
        copyToDynObject(parameters, store_parameters)
        store = datamanager.openStore(format, store_parameters)       

        # Creating a Table document and initialize with the data store
        project = currentProject()
        table = project().createDocument(TableManager.TYPENAME)
        table.setStore(store)
        table.setName(store.getName())

        # Add the Table document to the project
        project().addDocument(table)
       
    except Throwable, ex:
        raise RuntimeException("Can't load table, "+ str(ex)) 
 
    return table

def loadDBF(dbffile):
  table = loadTable(format="DBF",DbfFile=dbffile)
  return table

      
def getTempFile(name, ext):
    tempdir = Utilities.TEMPDIRECTORYPATH
    if not os.path.isdir(tempdir):
      os.makedirs(tempdir)
    t = time.time()
    f = os.path.join(
      tempdir,
      "%s-%x%x%s" % (name,t,(t-int(t)) * 10000,ext)
    )
    return f
    
def main(*args):
    print "Count values"
    table = currentTable()
    field = str(commonsdialog.inputbox("Name of the field"))
    try:
        features = table.features()
    except:
        commonsdialog.msgbox("Table not opened")
    count = dict()
    for f in features:
        ff = str(f.get(field))
        if ff in count.keys():
            count[ff] += 1
        else:
            count[ff] = 1
    print count
    sch = createSchema()
    sch.append('ID','STRING',15)
    sch.append('COUNT','INTEGER',20)
    dbf = createDBF(sch, getTempFile("count"+field,".dbf"))
    print type(dbf())
    print "full name: ", dbf.getFullName()
    #Insert table data

    dbf.edit()
    for k,v in count.iteritems():
      f = dbf.createNewFeature()
      f.set('ID',k)
      f.set('COUNT',v)
      dbf.insert(f)

    dbf.commit()

    d = loadDBF( dbf.getFullName())
    print dbf.getFullName()
    return

Después guardamos dicho script.

Ahora ya sobre la Vista de gvSIG, ponemos la capa sobre la que queramos realizar el cálculo activa y abrimos su tabla de atributos. Después abrimos el lanzador de scripts (menú Herramientas->Scripting->Lanzador de Scripts; este menú se llama “Scripting Launcher” hasta la versión 2.2).

Con doble-click sobre el Script que habíamos creado se abrirá una ventana donde podremos escribir el nombre del campo sobre el que queramos realizar el cálculo. Tras aceptar se habrá creado una nueva tabla con los resultados. Iremos al Gestor de proyectos (en el menú Mostrar), y en el documento “Tabla” tendremos la nueva tabla creada.

Counter_esp

Dicha tabla es temporal, por lo que si la queremos mantener podremos exportarla a una tabla dbf en disco (menú Tabla->Exportar a).

 


Filed under: development, gvSIG Desktop, scripting, spanish

by Mario at June 17, 2016 08:37 AM

June 16, 2016

GeoServer Team

Talks about GeoServer in FOSS4G Bonn

Guest post by Fernando Quadro: FOSS4G is the annual global event of the Open Source Geospatial Foundation (OSGeo). Although widely recognized as the largest technical open source geospatial conference we call FOSS4G an “event” because it is far more than “just” a conference. A typical FOSS4G will include regular presentations and talks, but also code sprints, birds of a feather sessions, workshops, topic talks and of course social events spanning all nine days.

The list of talks that will be presented are already published, here are the talks about GeoServer:

The workshops are include great GeoServer content:

FOSS4G 2016 takes place between August 24th and 27th in Bonn Germany. For more information see the video below:

by jgarnett at June 16, 2016 10:35 PM

Fernando Quadro

Configurar o GeoServer na AWS

A cada dia está mais comum os sistemas rodarem na nuvem, e as aplicações geoespaciais não ficam fora dessa onda. É comum os usuário se perguntarem como configurar o GeoServer em um ambiente de cluster na Amazon Web Services (AWS).

Hoje, existem alguns métodos para configurar o GeoServer em uma arquitetura de alta disponibilidade baseada na nuvem. Há duas extensões de clustering com suporte ao Geoserver – uma é baseado em Hazelcast e a outra no JMS.

A abordagem básica ambas as extensões utilizam que é ter a configuração compartilhada entre todos os nós do cluster. Isto pode ser conseguido pela utilização de um sistema de arquivos compartilhado (GlusterFS, NFS, EFS, etc.) ou usando uma combinação de armazenar a maior parte da configuração em uma base de dados (Postgres), e as partes da configuração que não são persistidas no banco de dados através de um sistema de arquivos compartilhado.

08bits-amazon-tmagArticle

Ambas as extensões têm seus próprios benefícios e limitações. Como exemplo, Hazelcast utiliza uma topologia multi-mestre, mas (pelo menos no momento) cria uma interface inutilizável. Isto significa que todas as alterações de configuração deve ser feita através da API REST, enquanto a implementação JMS é melhor quando usada em uma topologia master-slave em vez de tentar usá-lo em uma topologia multi-master.

Dependendo da situação, não sugere-se a utilização de qualquer uma dessas extensões e, ao invés disso sincronizar a configuração entre todos os nós com Chef/Puppet ou por outros meios.

Você pode visualizar a documentação completa do Hazelcast no link abaixo:

http://suite.opengeo.org/docs/latest/sysadmin/clustering/setup.html

E a documentação JMS também:

http://docs.geoserver.org/stable/en/user/community/jms-cluster/index.html
http://geoserver.geo-solutions.it/educational/en/clustering/index.html

Fonte: Blog da Boundless

by Fernando Quadro at June 16, 2016 10:30 AM

gvSIG Team

Camino a gvSIG 2.3: Datos LiDAR

En gvSIG 2.3 tendremos acceso a una nueva fuente de datos que cada vez es más utilizada, los datos LiDAR. gvSIG 2.3 proporciona drivers para leer y escribir LiDAR en gvSIG siguiendo la especificación de LAS. También se proporciona una herramienta de recorte de datos para exportar un subconjunto de datos LIDAR.

Drivers

El usuario tendrá 2 opciones para trabajar con ficheros LAS, basadas en la implementación en gvSIG de 2 librerías diferentes, cada una de ellas con sus ventajas:

  • El proveedor basado en JGrasstools que es de lectura/escritura.

  • El proveedor basado en Whitebox que es de sólo lectura, pero actualmente ofrece mejor rendimiento que el basado en Jgrasstools.

Lidar_gvSIG_01

Aclarado/simplificación

Ambos drivers incluyen dos parámetros de “aclarado” (simplificación), que permiten leer un subconjunto del total de puntos disponibles en el fichero LAS. El aclarado permite dibujar rápidamente ficheros enormes a pequeñas escalas (en las que no se requiere un nivel de detalle tan elevado como el que provee el fichero):

  • ThinningDivisor: lee 1 de cada n puntos (1/n), por ejemplo thinningDivisor=10 carga el 10% del total de puntos disponibles

  • ThinningResolution: Carga aproximadamente n puntos por unidad cuadrada de la capa; por ejemplo, thinningResolution=0.0001 carga 0.0001 puntos/m2 (asumiendo que las unidades de la proyección de la capa de ejemplo son metros), o lo que es lo mismo, 100 puntos/km²

Atributos

Los ficheros LAS poseen un conjunto de campos obligatorios (fijos) y otros opcionales que dependen de formato de datos de punto que se especifique en la cabecera del fichero LAS.

Los campos obligatorios son:

  • CLASSIFICATION (clasificación de coberturas del suelo)
  • POINTX (coordenada x del punto)
  • POINTY (coordenada y del punto)
  • POINTZ (coordenada z del punto, útil para simbolizar elevaciones del terreno)
  • INTENSITY (intensidad)
  • RETURNNUM (número de retorno del punto)
  • NUMBEROFRETURNS (número de retornos para este pulso láser)

Los campos opcionales son:

  • COLOR (color del punto, expresado como un entero “long” de Java que contiene el valor RGB)
  • TIME (tiempo absoluto de captura, expresado tal como genera Data.getTime())
  • WEEKTIME (tiempo relativo de captura, expresado como tiempo GPS semanal)

Lidar_gvSIG_02

Herramienta de exportación

La herramienta de recorte permite elegir un subconjunto de los datos para exportarlo a un nuevo fichero LAS.

Lidar_gvSIG_03

La herramienta permite elegir una extensión geométrica para filtrar los datos (sólo se exportarán los puntos que estén comprendidos en la extensión geométrica seleccionada). Las opciones posibles son:

  • No realizar un filtrado por extensión geométrica.

  • Filtrar los datos usando la extensión visible en la vista activa.

  • Filtrar usando una extensión geométrica especificada por el usuario.

LiDAR_gvSIG_04

Es importante remarcar que si hemos cargado la capa en la vista usando las opciones de “aclarado” (simplificación) de datos, la herramienta de exportación respetará estas opciones, con lo cual se exportará la versión simplificada de los datos.

Y para acabar os dejamos con un par de vídeos relacionados con la carga de datos LiDAR en gvSIG:


Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.3, LAS, LiDAR

by Alvaro at June 16, 2016 09:44 AM

GIS Professionals in Iran

آیکون های موجود در نرم افزار QGIS

add vector layer    برای معرفی shapefile از نوع vector از این آیکون استفاده می شود. add raster layer    برای معرفی shapefile از نوع raster از این آیکون استفاده می شود . add postgis layer add spatialite layer add wms layer    web map service : Wms new shapefile layer برای ساختن shapefile جدید از این ...

نوشته آیکون های موجود در نرم افزار QGIS اولین بار در سایت تخصصی جی.آی.اس پدیدار شد.

by ادمین at June 16, 2016 03:30 AM

June 15, 2016

Fernando Quadro

Talks sobre GeoServer no FOSS4G Bonn

O FOSS4G Global é o evento anual da Open Source Geospatial Foundation (OSGeo). Embora amplamente reconhecido como a maior conferência Open Source GIS do mundo o FOSS4G é denominado um “evento”, porque é muito mais que “apenas” uma conferência, pois ele inclui apresentações regulares, palestras, sprints de código, workshops, e claro, eventos sociais.

Foi liberada a lista dos talks que serão apresentados no evento este ano, e eu elenquei abaixo as palestras relacionadas com o GeoServer:

Creating Stunning Maps in GeoServer: mastering SLD and CSS styles
GeoServer Styling Hints and Tips for Prettier Maps
Enterprise Single Sign-On in GeoServer: where do we stand?
GeoServer in Production: we do it, here is how!
Mastering Security with GeoServer and GeoFence
Serving earth observation data with GeoServer: addressing real world requirements
Crunching Data In GeoServer: Mastering Rendering Transformations, WPS Processes And SQL Views
State of GeoServer
Vector Tiles with GeoServer and OpenLayers

Quem quiser mais informações sobre a edição deste ano do FOSS4G que será realizado entre os dias 24 e 27 de agosto na cidade de Bonn na Alemanha, pode acessar o site ou ver o vídeo abaixo:

by Fernando Quadro at June 15, 2016 10:30 AM

OSGeo News

OSGeo and the University Consortium for Geographic Information Science (UCGIS) sign Memorandum of Understanding

by jsanz at June 15, 2016 08:06 AM

June 14, 2016

GeoSpatial Camptocamp

GeoMapFish et QGIS : un écosystème SIG

Cet article présente quelques astuces pour connecter QGIS aux services de données et de recherche de GeoMapFish.

Cet article GeoMapFish et QGIS : un écosystème SIG est apparu en premier sur Camptocamp.

by Yves Jacolin at June 14, 2016 02:22 PM

Fernando Quadro

Criando um aplicativo de rotas com pgRouting – Parte 5

Para interagir com o nosso algoritmo de roteamento vamos precisar de um cliente que possa realizar solicitações no padrão OGR para nossas camadas nearest_vertex e shortest_path no GeoServer.

Iremos implementar um cliente muito simples com este tutorial que vai deixar o usuário arrastar os marcadores para início e destino da rota e, em seguida, atualizar o mapa com uma linha indicando a rota mais curta entre os dois pontos. O cliente será escrito em OpenLayers 3 com JQuery.

route2

Nós estaremos usando o SDK Suíte para criar um modelo para a construção de nossa aplicação. Na linha de comando vamos executar o seguinte.

suite-sdk create routing ol3view

Agora nós teremos um diretório com a aplicação básica para visualizar as camadas. Existem vários arquivos neste diretório, mas só vamos nos preocupar com index.html e src/app/app.js.

Vamos primeiro precisar editar o arquivo index.html que carrega as bibliotecas OpenLayers e jQuery, para adicionar um componente onde possamos exibir informações sobre a rota. Encontre a linha que tem <div id = “map”> e adicione a seguinte linha antes: <div id = “info”></div>. Esta parte do arquivo agora deve ter a seguinte aparência:

  </div><!--/.navbar-collapse -->
</div>
<div id="info"></div>
<div id="map">
  <div id="popup" class="ol-popup">
  </div>
</div>

Agora, vamos construir nossa aplicação javascript passo-a-passo, mas ao contrário do que fizemos com o arquivo index.html vamos remover os arquivos app.js e escrever um novo a partir do zero. Não esqueça de colocar seus novos arquivos na pasta src/app.

Vamos começar declarando algumas variáveis, que incluirão o ponto inicial (center point) e o nível de zoom para o nosso mapa.

var geoserverUrl = '/geoserver';
var center = ol.proj.transform([-70.26, 43.67], 'EPSG:4326', 'EPSG:3857');
var zoom = 12;
var pointerDown = false;
var currentMarker = null;
var changed = false;
var routeLayer;
var routeSource;
var travelTime;
var travelDist;

Vamos precisar atualizar o texto em dois elementos no documento index.html como nossas mudanças de rota.

// elements in HTML document
var info = document.getElementById('info');
var popup = document.getElementById('popup');

Quando apresentarmos as informações sobre a nossa rota, teremos de formatar os dados para exibição. Por exemplo, o tempo que leva para viajar ao longo de uma rota é medido em horas, por isso vamos ter o número de 0,25 e formatá-lo para exibir 15 minutos. Faça alguma formatação de distâncias, nomes das estradas e cruzamentos.

Nosso mapa terá dois marcadores para que o usuário possa arrastá-los para novas posições e indicar o início e fim da rota.

markers

Nós vamos adicionar uma função para as camadas de sobreposição chamada changeHandler que será acionada sempre que um dos marcadores for movido.

// create a point with a colour and change handler
function createMarker(point, colour) {
  var marker = new ol.Feature({
    geometry: new ol.geom.Point(ol.proj.transform(point, 'EPSG:4326', 'EPSG:3857'))
  });
  marker.setStyle(
    [new ol.style.Style({
      image: new ol.style.Circle({
        radius: 6,
        fill: new ol.style.Fill({
          color: 'rgba(' + colour.join(',') + ', 1)'
        })
      })
    })]
  );
  marker.on('change', changeHandler);
  return marker;
}
var sourceMarker = createMarker([-70.26013, 43.66515], [0, 255, 0]);
var targetMarker = createMarker([-70.24667, 43.66996], [255, 0, 0]);
// create overlay to display the markers
var markerOverlay = new ol.FeatureOverlay({
  features: [sourceMarker, targetMarker],
});

A função para o movimento do marcador é muito simples: vamos manter um registro do marcador que quando se move indica que a rota foi alterada.

// record when we move one of the source/target markers on the map
function changeHandler(e) {
  if (pointerDown) {
    changed = true;
    currentMarker = e.target;
  }
}

Agora que os marcadores foram criados, podemos dizer ao OpenLayers que eles podem ser modificados pela interação do usuário:

var moveMarker = new ol.interaction.Modify({
  features: markerOverlay.getFeatures(),
  tolerance: 20
});

Vamos criar uma segunda camada, que será usada para exibir um pop-up quando o usuário clicar em segmentos da rota, e vamos destacar os segmentos selecionados com um estilo diferente.

// create overlay to show the popup box
var popupOverlay = new ol.Overlay({
  element: popup
});

// style routes differently when clicked
var selectSegment = new ol.interaction.Select({
  condition: ol.events.condition.click,
  style: new ol.style.Style({
      stroke: new ol.style.Stroke({
        color: 'rgba(255, 0, 128, 1)',
        width: 8
    })
  })
});

A camada base para a nossa aplicação será do OpenStreetMap, que é suportada pelo Openlayers 3. O mapa será criado com suporte para os marcadores e as diferentes interações que criamos sobre ele.

// set the starting view
var view = new ol.View({
  center: center,
  zoom: zoom
});
// create the map with OSM data
var map = new ol.Map({
  target: 'map',
  layers: [
    new ol.layer.Tile({
      source: new ol.source.OSM()
    })
  ],
  view: view,
  overlays: [popupOverlay, markerOverlay]
});
map.addInteraction(moveMarker);
map.addInteraction(selectSegment);
});

Vamos apresentar o pop-up quando o usuário clicar em um segmento de rota, mostrando o nome da estrada, a distância e o tempo necessário para atravessá-la.

// show pop up box when clicking on part of route
var getFeatureInfo = function(coordinate) {
  var pixel = map.getPixelFromCoordinate(coordinate);
  var feature = map.forEachFeatureAtPixel(pixel, function(feature, layer) {
    if (layer == routeLayer) {
      return feature;
    }
  });
  var text = null;
  if (feature) {
    text = '<strong>' + feature.get('name') + '</strong><br/>';
    text += '<p>Distance: <code>' + feature.get('distance') + '</code></p>';
    text += '<p>Estimated travel time: <code>' + feature.get('time') + '</code></p>';
    text = text.replace(/ /g, ' ');
  }
  return text;
};
// display the popup when user clicks on a route segment
map.on('click', function(evt) {
  var coordinate = evt.coordinate;
  var text = getFeatureInfo(coordinate);
  if (text) {
    popupOverlay.setPosition(coordinate);
    popup.innerHTML = text;
    popup.style.display = 'block';
  }
});

Precisamos registrar quando o usuário inicia ou para de arrastar um marcador para que possamos saber quando recalcular a rota. Faremos isso registrando o evento do clique do mouse.

// record start of click
map.on('pointerdown', function(evt) {
  pointerDown = true;
  popup.style.display = 'none';
});
// record end of click
map.on('pointerup', function(evt) {
  pointerDown = false;
  // if we were dragging a marker, recalculate the route
  if (currentMarker) {
    getVertex(currentMarker);
    getRoute();
    currentMarker = null;
 }
});

O último passo antes de trabalhar com a comunicação do cliente com o GeoServer é criar um temporizador que irá acionar a cada quarto de segundo, o que nos permite atualizar a rota periodicamente ao mover um marcador para uma nova localização.

// timer to update the route when dragging
window.setInterval(function(){
  if (currentMarker && changed) {
    getVertex(currentMarker);
    getRoute();
    changed = false;
  }
}, 250);

No código acima, podemos ver as chamadas para duas funções principais: getVertex e getRoute. Estes dois métodos realizam requisições WFS ao GeoServer para obter informações do recurso. getVertex recupera o vértice mais próximo na rede para a posição do marcador atual, enquanto getRoute calcula o caminho mais curto entre os dois marcadores.

O método getVertex utiliza as coordenadas atuais de um marcador e os passa como parâmetros x e y para o nearest_vertex (SQL View) que criamos no GeoServer. O requisição GetFeature do WFS será capturada como JSON e passada para a função loadVertex para o processamento.

// WFS to get the closest vertex to a point on the map
function getVertex(marker) {
  var coordinates = marker.getGeometry().getCoordinates();
  var url = geoserverUrl + '/wfs?service=WFS&version=1.0.0&' +
      'request=GetFeature&typeName=tutorial:nearest_vertex&' +
      'outputformat=application/json&' +
      'viewparams=x:' + coordinates[0] + ';y:' + coordinates[1];
  $.ajax({
     url: url,
     async: false,
     dataType: 'json',
     success: function(json) {
       loadVertex(json, marker == sourceMarker);
     }
  });
}

O loadVertex analisa a resposta do GeoServer e armazena o vértice mais próximo como o ponto de início ou o fim do nosso percurso. Vamos precisar do id do vértice mais tarde para solicitar a rota ao pgRouting.

// load the response to the nearest_vertex layer
function loadVertex(response, isSource) {
  var geojson = new ol.format.GeoJSON();
  var features = geojson.readFeatures(response);
  if (isSource) {
    if (features.length == 0) {
      map.removeLayer(routeLayer);
      source = null;
      return;
    }
    source = features[0];
  } else {
    if (features.length == 0) {
      map.removeLayer(routeLayer);
      target = null;
      return;
    }
    target = features[0];
  }
}

Tudo o que fizemos até agora foi construir a requisição final (WFS GetFeature) que vai realmente solicitar e exibir a rota. O shortest_path (SQL View) tem três parâmetros, o vértice de origem, o vértice destino e o custo (distância ou tempo).

function getRoute() {
  // set up the source and target vertex numbers to pass as parameters
  var viewParams = [
    'source:' + source.getId().split('.')[1],
    'target:' + target.getId().split('.')[1],
    'cost:time'
  ];
  var url = geoserverUrl + '/wfs?service=WFS&version=1.0.0&' +
      'request=GetFeature&typeName=tutorial:shortest_path&' +
      'outputformat=application/json&' +
      '&viewparams=' + viewParams.join(';');
  // create a new source for our layer
  routeSource = new ol.source.ServerVector({
    format: new ol.format.GeoJSON(),
    strategy: ol.loadingstrategy.all,
    loader: function(extent, resolution) {
      $.ajax({
        url: url,
        dataType: 'json',
        success: loadRoute,
        async: false
      });
    },
  });
  // remove the previous layer and create a new one
  map.removeLayer(routeLayer);
  routeLayer = new ol.layer.Vector({
    source: routeSource,
    style: new ol.style.Style({
      stroke: new ol.style.Stroke({
        color: 'rgba(0, 0, 255, 0.5)',
        width: 8
      })
    })
  });
  // add the new layer to the map
  map.addLayer(routeLayer);
}

A rota gerada será usado para criar uma nova camada e atualizar as informações da pop-up com os detalhes da rota, incluindo os locais de início e fim, a distância e o tempo de viagem.

// handle the response to shortest_path
var loadRoute = function(response) {
  selectSegment.getFeatures().clear();
  routeSource.clear();
  var features = routeSource.readFeatures(response)
  if (features.length == 0) {
    info.innerHTML = '';
    return;
  }
  routeSource.addFeatures(features);
  var time = 0;
  var dist = 0;
  features.forEach(function(feature) {
    time += feature.get('time');
    dist += feature.get('distance');
  });
  if (!pointerDown) {
    // set the route text
    var text = 'Travelling from ' + formatPlaces(source.get('name')) + ' to ' + formatPlaces(target.get('name')) + '. ';
    text += 'Total distance ' + formatDist(dist) + '. ';
    text += 'Estimated travel time: ' + formatTime(time) + '.';
    info.innerHTML = text;
    // snap the markers to the exact route source/target
    markerOverlay.getFeatures().clear();
    sourceMarker.setGeometry(source.getGeometry());
    targetMarker.setGeometry(target.getGeometry());
    markerOverlay.getFeatures().push(sourceMarker);
    markerOverlay.getFeatures().push(targetMarker);
  }
}

Nossa aplicação agora está completa! Você pode testá-lo, executando o SDK no modo de depuração:

suite-sdk debug routing

Veja como ficou o nosso mapa:

application

Este tutorial é uma tradução e adaptação livre do artigo “Building a Routing Application” publicado no site da Boundless.

Fonte: Boundless

by Fernando Quadro at June 14, 2016 10:30 AM

June 13, 2016

Tom Kralidis

GeoHealthCheck support on Gitter

It’s been almost two years since GeoHealthCheck was initially developed (en route to FOSS4G in PDX).  Since then, GHC has been deployed in numerous environments in support of monitoring of (primarily) OGC services (canonical demo at http://geohealthcheck.osgeo.org). Project communications have been relatively low key, with GitHub issues being the main discussion.  The project has setup […]

by tomkralidis at June 13, 2016 09:47 PM

Free and Open Source GIS Ramblings

Slides & workshop material from #QGISConf2016

If you could not make it to Girona for this year’s QGIS user conference, here’s your chance to catch up with the many exciting presentations and workshops that made up the conference program on May 25-26th:

(Some resources are still missing but they’ll hopefully be added in the coming days.)

Update: Now you can also watch the talks online or even download them.

Thanks to everyone who was involved in making this second QGIS user conference a great experience for all participants!


by underdark at June 13, 2016 09:11 PM

GeoSpatial Camptocamp

FOSS4G 2016: workshops and presentations

Loyal to its commitment to Open Source GIS solutions, Camptocamp will attend and sponsor the 2016 FOSS4G conference, taking place this year in the beautiful city of Bonn!

Cet article FOSS4G 2016: workshops and presentations est apparu en premier sur Camptocamp.

by Stéphanie Debayle at June 13, 2016 12:34 PM

GeoSolutions

Meet GeoSolutions at INSPIRE Conference 2016

INSPIRE Conference 2016

Dear All, we are proud to announce that GeoSolutions is exhibiting at the INSPIRE Conference 2016 which will be held in Barcelona from 26h to 30th of September 2016..

GeoSolutions will be present with its own booth (check this page for the layout) therefore we'll be happy to talk to you about our open source products, like GeoServer and Mapstore, as well as about our Enterprise Support Services. We have also submitted a proposal for a 3H workshop on GeoServer, we will update this page as the program will become definitive.

If you are interested in learning about how we can help you achieving your goals with our Open Source products and professional services, make sure to visit us at our booth

The GeoSolutions team,

by simone giannecchini at June 13, 2016 10:43 AM

Fernando Quadro

Criando um aplicativo de rotas com pgRouting – Parte 4

O nosso trabalho de banco de dados foi concluído no último post e agora já podemos publicar o nosso roteamento como camadas dinâmicas no GeoServer. Primeiro crie um novo workspace chamado tutorial e uma nova store PostGIS que se conecte ao banco de dados.

stores

Nós estaremos criando duas camadas em GeoServer: shortest_path, que encontra a rota entre dois vértices em nossa rede de roteamento e retorna uma lista de características que representam esse caminho; e nearest_vertex, que encontra o vértice mais próximo de qualquer ponto do nosso conjunto de dados. Nossa aplicação irá permitir que o usuário selecione um ponto no mapa traduzindo-o em um vértice, que pode ser usado como origem ou destino na nossa camada de geração de rota.

Vamos configurar um novo modo de exibição SQL chamado shortest_path com a seguinte consulta SQL:

SELECT
  min(r.seq) AS seq,
  e.old_id AS id,
  e.name,
  e.type,
  e.oneway,
  sum(e.time) AS time,
  sum(e.distance) AS distance,
  ST_Collect(e.the_geom) AS geom
FROM
  pgr_dijkstra(
   'SELECT
    id,
    source::INT4,
    target::INT4,
    %cost% AS cost,
    CASE oneway
      WHEN ''yes'' THEN -1
      ELSE %cost%
    END AS reverse_cost
  FROM edges_noded', %source%, %target%, true, true) AS r,
  edges_noded AS e
WHERE
  r.id2 = e.id
GROUP BY
  e.old_id, e.name, e.type, e.oneway

A camada tem três parâmetros: source, target and cost. Os dois primeiros são o número de identificação do vértice e o custo a qualquer distância ou tempo, dependendo de qual métrica utilizada para calcular a rota.

Note-se também a função ST_Collect irá combinar os segmentos de linha em uma única geometria MultiLineString.

Por razões de segurança, quando estamos criando uma SQL View, devemos mudar a validação de expressão regular dos campos source e target para que somente dígitos sejam permitidos (^ [\ d] + $) e para o campo coast de tal forma que as palavras “time” e “distance”sejam permitidas (^ [\ w] + $).

route_view_params

Por último, certifique-se de que especificar qual atributo irá identificar cada recurso na rota, o tipo de geometria (MultiLineString) e o SRID (3857).

route_view_attributes

Isto é tudo o que precisamos configurar no GeoServer para fornecer rotas entre dois vértices, mas o nosso cliente precisa saber os números de identificação dos vértices, por isso vamos publicar a tabela edges_noded_vertices_pgr que foi criada automaticamente. Isso nos leva a nossa segunda SQL View, que vai encontrar o vértice mais próximo a um ponto no mapa como uma forma de selecionar o início ou o fim do nosso percurso.

Usaremos nearest_vertex como nome da camada para publicar a seguinte consulta SQL:

SELECT
  v.id,
  v.the_geom,
  string_agg(distinct(e.name),',') AS name
FROM
  edges_noded_vertices_pgr AS v,
  edges_noded AS e
WHERE
  v.id = (SELECT
            id
          FROM edges_noded_vertices_pgr
          ORDER BY the_geom <-> ST_SetSRID(ST_MakePoint(%x%, %y%), 3857) LIMIT 1)
  AND (e.source = v.id OR e.target = v.id)
GROUP BY v.id, v.the_geom

Devido o fato de que coordenadas podem conter números negativos ou positivos, certifique-se de mudar as expressões regulares de validação para incluir apenas dígitos e ambos os símbolos necessários: ^ [\ d .-] + $.

vertex_view

A subconsulta usa um truque para encontrar rapidamente o ponto mais próximo aos parâmetros x e y. Além de retornar a geometria deste ponto, irá criar uma lista de todas as estradas que se encontram no vértice. Como exemplo, veja a imagem abaixo:

intersection

Finalmente, se publicamos as tabelas edges_noded_vertices_pgr e edges_noded, podemos visualizar nossa rede de roteamento no GeoServer. Isso não é necessário para a nossa aplicação, mas ajuda a visualizar os dados que se está trabalhando.

network

by Fernando Quadro at June 13, 2016 10:42 AM

Andrea Antonello

Extrusion for the 3D vector view in gvSIG

As some of you might know already, some time ago we started to migrate all our tools (JGrasstools and Geopaparazzi, as well as the Nettools) to gvSIG. We are quite young in this community and we joined as an official member the gvSIG Association only at the begin of this year.

In the meanwhile we brought geopaparazzi support, the JGrasstools based Spatial Toolbox and the Epanet part of the Nettools into gvSIG.

Recently we were involved by one of the other association members, the Spanish Company DISIS, to develop with them the extrusion part for the 3D vector viewer integrated in gvSIG.

I am really thrilled by this cooperation, which brings us one more step towards the core of the community and also shows that there is movement in the gvSIG related Open Source Market.

A few notes about the extrusion plugin

From the version 2.3 of gvSIG on (well, right now the official release is not yet out), a 3d is available which allows the user to visualize layers in a Nasa World Wind 3d view. The user can select several loading modes for the layers.

The 3d properties of a vector layer can be accessed by right clicking on the layer and accessing the Properties entry in the context menu. By default the 3D tab will show up like this:




At the current time there are 3 different loading modes for vector layers:
  1. Rasterized vector: the gvSIG vector layer will be rasterized as an image over the 3d view
  2. Vector: the features from the gvSIG vector layer will be transformed into 3d vectors and loaded in the 3d view
  3. Extruded Vector: the features from the gvSIG vector layer will be transformed into 3d vectors and loaded in the 3d view, with an applied extrusion, in order to obtain an effect of volume.
Since I have been working on the last two modes, I will give a quick insight on those.

Vector

The Vector loading mode presents the following user interface:



The altitude of the features can be defined by two factors (and also be the sum of both):

  1. the 3rd dimension of the geometry, if available (3d shapefiles for example)
  2. the Constant Height parameter

There are 3 available elevation modes, which will consider the altitude differently:
  • clamp to ground: in this case the features are clamped to the elevation model currently used in the 3d view. In this case the altitude definition will not be considered.
  • absolute: in this case the elevation of the vector is given by the altitude, defined as absolute elevation over the sea level.
  • relative to ground: in this case the elevation of the vector is given by the altitude, defined as relative elevation over the terrain.

For example this is how the clamp to ground option would look like:
 


We can see that the very coarse default terrain model in many parts covers the vectors. In this case it is possible to set the mode to relative to ground and apply a constant height to solve it:





Extruded Vector

The extruded vector loading mode adds a couple of parameters to the user interface:
 

In this case the altitude of the features can be defined by four factors:
  1. the 3rd dimension of the geometry, if available (3d shapefiles for example)
  2. a Height Field from the attributes table
  3. the Constant Height parameter
  4. the Vertical Exaggeration, which is a multiplication factor applied to the height

There are 2 available elevation modes, which will consider the altitude differently:
  • absolute: in this case the elevation of the vector is given by the altitude, defined as absolute elevation over the sea level.
  • relative to ground: in this case the elevation of the vector is given by the altitude, defined as relative elevation over the terrain.
For example, if we select the relative to ground option and apply an height field that contains the building heights, this will look like:


Again we can apply a constant height to elevate the features over the terrain. Let's also try to use the number of the floors of the buildings instead of the altitude. In this cas we can apply a vertical exaggeration of 3 meters to simulate the correct building altitude:




Other examples

Example of a lines layer of isolines that have 3d coordinates. Here the extruded mode was selected and the absolute elevation mode was picked adding also a constant height of 50 additional meters:





The same layer and parameters, but without extrusion:





An example of points layer that do not have 3rd coordinates, but an absolute elevation in the attributes table. In this case the extrusion was picked and the absolute height taken from the elevation field in the attributes table:



Since the elevation is the one of the terrain, it is not possible to appreciate the extrusion effect. By adding a constant height to add as an offset, this is solved:






There is also a short video that shows 3D extrusion in gvSIG live here.

Acknowledgements



It has been great fun to implement this and also helped me know a new piece of the gvSIG internals, which is quite important right now.

So thanks to DISID for this, since our involvement in gvSIG they have always been very supportive to involve us and teach us to get up and running as fast as possible.


by andrea antonello (noreply@blogger.com) at June 13, 2016 06:00 AM

June 12, 2016

Paul Ramsey

Politics Amid Plenty

“Political leadership is a subtle art in times of plenty. When there are no great crises, there is no public demand for heroic acts. Politics becomes a parlor game, ignored by all but the most devoted citizens, a game practiced most assiduously by those interests–the business associations, trade unions, and single-issue groups–who have a direct stake in the outcome. The game turns on tactics and gestures, on the ability to placate factions, rather than to inspire the masses.”
- Joe Kein, The Natural

June 12, 2016 11:00 AM

June 10, 2016

GeoTools Team

GeoTools Header Policy Updated

GeoTools Developers Guide on source code conventions has been updated with a new policy on file headers (exciting I know).

GeoTools will now focus on filling in headers with the current year on initial file creation ... and that is it.
/**    GeoTools - The Open Source Java GIS Toolkit*    http://geotools.org**    (C) 2016, Open Source Geospatial Foundation (OSGeo)**    This library is free software; you can redistribute it and/or*    modify it under the terms of the GNU Lesser General Public*    License as published by the Free Software Foundation;*    version 2.1 of the License.**    This library is distributed in the hope that it will be useful,*    but WITHOUT ANY WARRANTY; without even the implied warranty of*    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU*    Lesser General Public License for more details.*/
Previously we asked contributors to update the headers each time they modified a file resulting in a date range at the top of each file. While not technically difficult this was constant chore for committers. More importantly this caused friction reviewing incoming pull requests (as shown by a github search).



We have approached the OSGeo Board and gotten approval to bounce this change off legal council. It is hoped that other OSGeo projects can benefit from being more relaxed.

Thanks to Justin for writing up the change proposal and steering this conversation on the mailing list.

by Jody Garnett (noreply@blogger.com) at June 10, 2016 06:21 PM