OSGeo Planet

gvSIG Team: Conferencia en la Space Apps Challenge de la NASA, sobre gvSIG y 3D

OSGeo Planet - Wed, 2017-05-03 13:22

El pasado 29 de Abril se realizó en Las Naves de Valencia la Space Apps Challenge como sede entre otras muchas en un evento mundial simultaneo. En esta hackaton se reúnen todo tipo de desarrolladores, ingenieros, científicos, diseñadores.. para resolver unos retos propuestos por la NASA a problemas relacionadas con la exploración del espacio y de la tierra.

Fuimos invitados a este evento con el motivo de haber ganado dos años diversos premios en el Nasa Worldwind Europa Challenge 2015 y 2016 sobre la integración del globo virtual 3D WorldWind en gvSIG para la visualización de datos en tres dimensiones, tanto en gvSIG Desktop como en gvSIG Online. Tuvimos la oportunidad de hablar sobre la importancia de lo geo, del software libre y de las visualizaciones 3D.

Fue muy satisfactorio ver como algún equipo vio la oportunidad de utilizar gvSIG como base en sus desarrollos.

Aquí os dejo las diapositivas y algunas fotos del momento. Para más información sobre el evento podéis visitar directamente la cuenta de Twitter de la organización @spaceapps_vlc

Gracias por la invitación, a Las Naves por apostar por estos eventos y felicitaros por el éxito de la hackaton.

Hoy estamos en la hackaton @spaceapps_vlc especial conferencia sobre la integración de #gvSIG con el 3D de WorldWind pic.twitter.com/kYbVcZ3QFy

— más que SIG (@masquesig) April 29, 2017

Hoy en @spaceapps_vlc tenemos a @gvsig Premio europeo al mejor proyecto #opensource 2017. Iniciativas que nos gustan en @lasnaves pic.twitter.com/A9zx1NTYZI

— Rafa Monterde (@rafa_monty) April 29, 2017

GvSig on Jython (python + java), Groovy, Renjin, Scala y Java.#spaceappsVLC #spaceapps "sinergias tecnología valenciana gvSIG y la NASA" pic.twitter.com/TbxavV8Z2s

— Space Apps Valencia (@spaceapps_vlc) April 29, 2017


Filed under: events, gvSIG Desktop, software libre, spanish
Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.4: Biblioteca de símbolos ISO-7010, pictogramas de seguridad

OSGeo Planet - Wed, 2017-05-03 01:22

La ISO-7010 define una serie de pictogramas o símbolos de seguridad. Esta norma ISO pretende armonizar a nivel internacional los símbolos gráficos y los colores de las señales de seguridad. Una armonización global que permite más coherencia y un reconocimiento universal de las señales.

Son diversos los sectores relacionados con la seguridad que utilizan sistemas de información geográfica y, por tanto, el disponer de una biblioteca de símbolos de la ISO-7010 puede serles de mucha utilidad. Sin ir más lejos, en la Asociación gvSIG estamos realizando diversos proyectos cuyos usuarios finales están directamente relacionados con temas de seguridad.

Así que hemos elaborado una nueva biblioteca de símbolos que formará parte de las novedades de la próxima versión de gvSIG…pero que desde ya podéis descargar e instalar en vuestro gvSIG Desktop.

Para ello simplemente debéis bajaros este fichero: https://mega.nz/#!ks4mQAYR!dAl1ZPLFwDYrvoktE4xHv04iTp0h2YyyFWZk7zRpHX0

…y a continuación instalarlo mediante el “Administrador de complementos” de gvSIG Desktop. Por si tenéis alguna duda, en este vídeo podéis ver cómo hacerlo:


Filed under: gvSIG Desktop, spanish Tagged: bibliotecas de símbolos, ISO-7010, seguridad, simbología
Categories: OSGeo Planet

Marco Bernasocchi: QGIS Expressions Engine: Performance boost

OSGeo Planet - Tue, 2017-05-02 20:43
Expressions in QGIS are more and more widely used for all kinds of purposes. For example the recently introduced geometry generators allow drawing awesome effects with modified feature geometries on the fly. The last days at the QGIS developer meeting… See more ›
Categories: OSGeo Planet

Jackie Ng: It's like the early days of the internet!

OSGeo Planet - Tue, 2017-05-02 00:07
Been going back on the MapGuide dev train.

One of the features I'm experimenting with is UTFGrid rendering.

I've mentioned in previous posts, how in the process of fleshing out an idea that you don't know whether it will work or not, that there comes a flash point. A moment where your idea tips from uncertainty to "yes it can be done, so let's get it done!"

I have just reached that moment again.


It's like the early days of dial-up internet. ASCII art galore!

So off the bat, 2 things I can see:

  • The Y-axis is flipped, oops.
  • I misread the UTFGrid spec. I'm not meant to do a pixel-by-pixel replacement here.
Once these 2 things are sorted, it's just a case of mapping each character to the feature attributes (that the renderer is also tracking) and we have enough data to assemble the final UTFGrid tile
Categories: OSGeo Planet

gvSIG Team: Talleres de la Jornada en Ourense sobre gvSIG: Scripting y R

OSGeo Planet - Mon, 2017-05-01 23:00

El pasado 21 de Abril se realizó un día de jornadas en el Campus de Ourense de la Universidad de Vigo para dar a conocer gvSIG. Además se realizaron 4 talleres: 2 para usuarios y 2 de desarrollo.

En este post adjunto la información perteneciente a los talleres de Scripting. Es un paquete de gvSIG que se instala desde el Administrador de Complementos. Después de instalar el complemento, al abrir el Editor de Scripts, aparecerán estos ejercicios en la carpeta de Addons. Los ejemplos están preparados sobre la capa de MANZANAS_POB y sobre las imágenes Landsat y Sentinel que aparecen en la carpeta de datos.

Cualquier duda sobre los talleres podéis comentarla en este mismo post o en las Listas de Desarrollo.

Descargar Talleres


Filed under: development, gvSIG Desktop, scripting, spanish Tagged: r
Categories: OSGeo Planet

gvSIG Team: IDE La Pobla de Vallbona, un ejemplo de Infraestructura de Datos Espaciales municipal

OSGeo Planet - Mon, 2017-05-01 22:54

Día a día son más las organizaciones que apuestan por gvSIG Suite para poner en marcha su Infraestructura de Datos Espaciales, su SIG Corporativo. Las razones varias y ya sabidas: independencia tecnológica, pago por servicios y no por licencias (y sus correspondientes “hipotecas” anuales), facilidad de uso, sumarse y crecer en Comunidad, apoyo de industria local,…

En este caso queremos comentaros la puesta en marcha de la IDE de La Pobla de Vallbona, un municipio de unos 24.000 habitantes, que requería por un lado de una plataforma como gvSIG Online para implantar la Infraestructura de Datos Espaciales y poder generar con (extrema) facilidad y sin limitaciones tantos geoportales (públicos y/o privados) como fuera necesario; por otro lado requería de una aplicación móvil, como el nuevo gvSIG Mobile 2.0 para Android, para la toma de datos en campo…con el objetivo de realizar todo el inventario municipal.

Viendo los resultados del proyecto creemos que es un proyecto ejemplar para muchos municipios que todavía no tienen resuelta la gestión de su información geográfica…y menos aún el cumplir (en la Unión Europea) con INSPIRE en fechas (en este enlace podéis encontrar un informe sobre alcance, fechas y penalizaciones de incumplimiento).

Normativas al margen, la utilidad de esta solución es indiscutible. Modernizar la gestión municipal pasa por disponer de una plataforma que permita gestionar eficientemente la información geográfica. En pocas administraciones la realidad se manifiesta en mayor grado en el territorio como en los municipios.

Y en La Pobla, en pocos meses, están sacando un rendimiento enorme a la suite gvSIG, ya han realizado todo el inventario municipal georreferenciado (farolas, fuentes, …) capturando no sólo posición y características (atributos) de cada elemento del inventario, sino acompañandolo de contenido multimedia que permita una mejor catalogación. Y, más allá del inventario, disponen de multitud de Geoportales temáticos públicos…por no hablar de los constantes geoportales privados que se generan cada vez que es necesario compartir información entre los distintos departamentos del municipio.

El portal de la IDE de La Pobla de Vallbona lo tenéis aquí:

https://sigpobla.gvsigonline.com/

Las IDE muchas veces “se venden” como poco más que un Geoportal y, sinceramente, poca utilidad tiene esa propuesta. Frente a eso, ejemplos como el ofrecido por La Pobla de Vallbona nos permiten mostrar cuál debería ser el enfoque inicial de una IDE. Y, a partir de ahí, su integración con otras tecnologías de la información como gestores documentales, portales de transparencia, etc.

Y si después de leer todo esto piensas que esta apuesta por plataformas libres podría ser lo que andas buscando, ponte en contacto con la Asociación gvSIG: info@gvsig.com

Os dejamos con un pequeño vídeo sobre la parte pública de la IDE:


Filed under: geoportal, gvSIG Desktop, gvSIG Mobile, gvSIG Online, gvSIG Suite, IDE, software libre, spanish Tagged: Infraestructura de Datos Espaciales, INSPIRE, inventario municipal, LISIGE
Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.4: Biblioteca de símbolos de Emojis

OSGeo Planet - Mon, 2017-05-01 20:49

Emoji es un término japonés para los ideogramas o caracteres usados en mensajes electrónicos y sitios web que, precisamente por su amplio uso, se han popularizado como uno de los conjuntos de símbolos más conocidos.

Más allá de su popularidad, son símbolos que pueden ser realmente útiles para representar determinados elementos en un Sistema de Información Geográfica. Por esto mismo hemos elaborado una nueva biblioteca de símbolos que formará parte de las novedades de la próxima versión de gvSIG…pero que desde ya podéis descargar e instalar en vuestro gvSIG Desktop.

Para ello simplemente debéis bajaros este fichero: https://mega.nz/#!Fh4wGZwL!U6sQKBoN3m3OU2mlBhKM4rD6Lh0vDWb1va9M4Y0RzYY

…y a continuación instalarlo mediante el “Administrador de complementos” de gvSIG Desktop. Por si tenéis alguna duda, en este vídeo podéis ver cómo hacerlo:


Filed under: gvSIG Desktop, spanish Tagged: bibliotecas de símbolos, emojis, simbología
Categories: OSGeo Planet

QGIS Blog: Call for presentations and workshop proposals: QGIS Conference 2017

OSGeo Planet - Mon, 2017-05-01 11:26

NOTE: Deadline for proposals is May 15 2017

We are going back to Nødebo! Each year we combine one of our QGIS Developer Meetings with a User Conference. The User Conference is a great opportunity for QGIS users to meet developers and share their experiences – both with developers and with other users. Our first ever User Conference was held in Nødebo, Denmark in 2015 and we are thrilled to be going back to the beautiful venue at the University of Denmark’s Forest and Landscape College.

1k0a4924

The user conference will be combined with the QGIS Developer Meeting and a summer school event, with the first week being focussed on the User Conference, the intermediate weekend on the QGIS Hackfest and the second week on the Summer School. The event will run from the 2nd of August through to the 11th of August 2017.

We would like to invite those who are interested in presenting a talk to apply now (NOTE: Deadline for proposals is May 15 2017). There are four kinds of contributions you can make (see the conference website for full details):

  • 20 minute ‘lightning’ talks
  • 1-2 hour short workshops
  • half and full day workshops
  • posters (which should be presented in the form of a map)

We have identified a number of themes for the User Conference:

  • QGIS Software Development
  • New Technology
  • Business
  • Government/Municipality
  • Science
  • Education

Presenters of full day workshops are eligible for a EUR 1000 reimbursement to offset their costs. You can find out more details at the conference web page (as well as registering your talk / presentation):

https://qgis2017.wordpress.com/presentations/

We are looking forward to seeing a great programme come together for the conference!

 

 

 


Categories: OSGeo Planet

QGIS Blog: QGIS Grant Programme #2 Results

OSGeo Planet - Sun, 2017-04-30 13:10

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

Our intent with the QGIS.ORG Grant Programme is to support work from community that would typically not be funded by client/contractor agreements, and that contributes to the broadest possible swathe of our community by providing cross-cutting, foundational improvements to the QGIS Project.

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

Screen Shot 2017-04-30 at 3.23.08 PM

A couple of extra notes about the voting process:

  • The PSC has an ongoing program to fund documentation so elected to fund the processing documentation work separately from the grant programme (note *1).
  • Voting was carried out based on the technical merits of the proposals and the competency of the applicants to execute on these proposals.
  • No restrictions were in place in terms of how many proposals could be submitted per person / organization, or how many proposals could be awarded to each proposing person / organization.
  • Because of the importance of having good packaging systems on each of the three major platforms, the PSC elected to additionally fund the work on MacOS bundling scripts (note *2).
  • Although the budget for the grant programme was €20,000.00, the total amount for the four winning proposals is €19,800.00, with an additional €5, 800.00 being made available to support the processing work and and MacOS packaging work.
  • Voting was ‘blind’ (voters could not see the existing votes that had been placed).

We had great participation in the voting process. Of the 27 voting members, 23 registered their votes.

Screen Shot 2017-04-20 at 4.11.45 PM
On behalf of the QGIS.ORG project, I would really like to thank everyone who submitted proposals for this call. There were many interesting proposals that I believe would be of great benefit to QGIS and I hope others perusing the proposals list will use their initiative and funding interesting proposals independently if they can.

Below you can find the detailed proposals of the successful applications – we look forward to seeing the results of their work land in the code base soon!

Details of the approved grant proposals 9 ADD CONSISTENCY TO UI CONTROLS

Proposer: Nyall Dawson

Amount: €1800

Details: Across the QGIS UI, numerous inconsistencies exist in the way different properties like opacity and rotation are exposed to users. These inconsistencies make QGIS harder to use, as behavior from one dialog differs to the behavior in another dialog. Some examples of this include:

  • Rotation of labels is done in the opposite direction in labeling to symbology. Accordingly, an equal rotation value will result in different rotation between labels and symbols.
  • Scales are inconsistently presented, with use of both the scale numerator and denominator in different dialogs. “Minimum” and “Maximum” scales also vary between dialogs, with some dialogs using “minimum” scale as the largest scale and some using “minimum” as the smallest scale. The labeling scale based visibility controls are the biggest offenders here.
  • Controls vary between specifying “opacity”, “transparency” and “alpha”. While these all have similar results, users must adopt values to map “opacity” to “transparency” in different dialogs. This is further compounded by different ranges used for each (eg 0-100%, or 0-255).

Due to the usual API freeze, it has not been possible to fix these discrepancies. The current API break introduced with version 3.0 allow a window for addressing these issues and standardizing behavior and API.

Despite the benefits in providing a consistent UI, the work involved in standardizing is fiddly (careful attention must be paid to not breaking existing projects) and repetitive, and unlikely to be undertaken by developers on a volunteer basis.  Furthermore it is highly unlikely that a commercial organisation could justify sponsoring UI standardisation efforts. Without grant funding it is unlikely that these issues will be addressed during the 3.0 development cycle, and the inconsistencies would remain for the lifetime of QGIS 3.x.

In this proposal I will:

  • convert all “transparency” controls to “opacity” controls, and consult with the community to determine the ideal value range presented (0-100% or 0-255) before making all opacity controls use the same range.
  • Ensure that rotation always operates in the same direction.
  • Fix the labeling scale ranges to use the same scale range definitions as layer visibility
  • As much as possible, automatically upgrade existing projects so that they open in QGIS 3.0 without any loss of transparency/rotation/scale settings
  • (As much as possible without large refactoring), adapt the PyQGIS API so for consistent naming and use of opacity/rotation and scale setting/getting methods. Making the API consistent makes scripting QGIS and writing plugins easier.

This proposal relates to the issues described at:

History: No work has currently been undertaken in this regard.

Qualifications: I am currently one of the most active QGIS developers, with a long history of quality contributions to the project. I’m passionate about seeing QGIS 3.0 address these kinds of long standing UI issues which detract from QGIS’ otherwise professional image and ease of use.

Implementation Plan:  The work will be undertaken prior to the QGIS 3.0 feature freeze period.

Proposal Link:

3 EXTEND UNIT TEST COVERAGE FOR GEOMETRY CLASSES

Proposer: Nyall Dawson

Amount: €2000

Details: Since QGIS 2.8, there has been an increased focused on creation of quality automated regression (“unit”) tests designed to flag issues in code before the code is introduced to the QGIS codebase. The increase in stability of recent QGIS versions can be directly attributed to this growth in unit testing. Despite this, many areas of the QGIS codebase remain with little or no unit test coverage.

One critical area which has insufficient unit tests is the geometry classes. The geometry classes form the basis of all geometry interpretation, algorithms, and rendering within QGIS. In order to provide stable QGIS releases, it is crucial that these fundamental classes are rock-solid, efficient, and do not suffer regressions between releases.

Some years ago (shortly after the introduction of the new geometry engine, in which support for Z/M values and curved geometries was added) I added full test coverage for the Point and Linestring classes, and partial coverage for the Polygon class. Unfortunately, writing geometry tests is tricky and time consuming. There’s many corner cases with unusual or invalid geometries which need to be tested. The time commitment required prevented me from writing additional tests, and to date the remaining classes (including multi geometries and all curved geometry types) have little or no test coverage.

This proposal covers writing additional unit tests to cover all the remaining geometry classes.

It is important to note that unit tests do NOT ensure bug free software. Unit tests only protect existing logic and avoid regressions when the covered parts of the code base are changed in future releases. Despite this disclaimer, the process of creating unit tests usually stress-tests existing code and in itself CAN reveal existing bugs. This was certainly the case when the existing tests for Point and Linestring classes were added – creation of the tests alone resulted in many fixed bugs and stabler Point and Linestring geometry handling.

History: This work would continue on from work I begun a number of years ago to provide 100% unit test coverage for the base geometry classes.

Qualifications: I have a long history of quality contributions to the QGIS project, and am currently one of the most prolific committers to the QGIS codebase. I have a long history with adding unit tests to QGIS and advocating for their increased usage amongst developers.

Implementation Plan: This work would be targeted to the QGIS 3.0 release, and would be committed to the codebase prior to the feature freeze/bug fixing period leading up to the 3.0 release.

Proposal Link:

8 QGIS 3D

Proposer: Martin Dobias

Amount: €10000

Details: I would like to propose a project that introduces 3D rendering capabilities in QGIS.
To summarize the planned work, the following features can be expected:

  • 2D view of map canvas rendered on the graphics hardware (GPU) allowing smooth zooming and panning of map view
  • 3D perspective view of the map
  • generation of 3D terrain model from DEM (digital elevation model) layers
  • map layers rendered as a texture on top of the 3D terrain
  • support for true 3D rendering of vector layers rather than having just flat appearance
  • map view widget that is dockable in the main window and synchronized with the main map canvas
  • support for picking (identification) of objects in 3D view and X/Y/Z coordinate display
  • support for 3D map view in map composer

The overall target is to introduce an extensible framework for 3D map view within QGIS, so that in the future developers can add various 3D rendering techniques for map data, using custom geometries and materials (which may involve writing own vertex/fragment shaders), possibly even allowing multi-pass rendering for advanced effects (e.g. to render shadows cast by buildings with a particular sun position).
3D support in QGIS is not only about adding the extra dimension to the rendering: it is also about making it possible to use graphics hardware for rendering of map in 2D – making map browsing even more pleasant and faster at the same time. Rendering 2D maps with OpenGL also opens the door to various new graphical effects that would be otherwise very expensive

to achieve by using just CPU for map rendering.
This proposal does not assume addition of new geometry types like polyhedral surface (with read support for those) into QGIS – the aim of the work is to get 3D rendering engine running and new geometry types may be added at some point later.

State of the art

QGIS features very good 2D rendering capabilities, however its 3D support has been very limited. Prior work on 3D in QGIS includes:

  • Globe plugin – a C++ plugin developed by Matthias Kuhn and Sourcepole based on OpenSceneGraph and osgEarth libraries. OpenSceneGraph is a generic toolkit that provides higher-level abstraction on top of OpenGL, making it easier to develop 3D applications than directly using low-level OpenGL interfaces.OsgEarth project then builds on top of OpenSceneGraph and provides a toolkit for working with geographical data: it has a terrain engine that combines elevation layers into a terrain, applies textures from “image” layers and adds feature layers with true 3D objects.The plugin acts as a bridge from QGIS environment and feeds scene data into osgEarth to do the 3D rendering.
  • Qgis2threejs plugin – a Python plugin developed by Minoru Akagi. It is able to export QGIS project (with various configuration options) into a HTML page that uses three.js library to render map in 3D within web browser using WebGL.
  • Horao – developed by Oslandia. It is a standalone 3D viewer based on OpenSceneGraph that may be controlled by a QGIS plugin to display map from QGIS in 3D environment. It has explicit support for true 3D geometries in PostGIS.

While these projects solve some use cases for 3D rendering of map data, each of them have their own limitations. For example, osgEarth library used by Globe plugin has its own data access and rendering of vector features implementation, duplicating QGIS code and not having parity in their capabilities. Moreover it has been difficult over time to keep the build working on all platforms supported by QGIS. The main limitation of Qgis2threejs plugin is the fact that the 3D view is exported to web browser, so the user cannot use benefits of having 3D view tightly integrated with the rest of QGIS. The fact that Horao has a standalone viewer

application results in similar limitations as when using Qgis2threejs (although it has some degree of integration with QGIS application).

Proposed approach
Now that QGIS 3.0 is based on Qt5, we can use some of the great new functionality added recent releases of Qt5. In version 5.5, a new framework for working 3D graphics has been introduced and every major Qt5 release since has been adding more functionality, improving performance, compatibility and stability. The 3D support nicely integrates with the rest of the Qt framework, providing a familiar API and at the same time staying very generic and highly efficient.
The 3D framework provides high level abstractions just like other libraries (e.g. OpenSceneGraph, three.js). 3D scene is built with nodes (called entities) with various components (e.g. transformation, mesh, material).
The idea is to build 3D support in QGIS on top of the Qt 3D framework. From my initial tests of the framework this looks feasible and it will allow us to stick with Qt APIs without requiring extra dependencies.
The work can be divided into the following chunks of work:

  1. Rendering engine core: develop a framework that will do rendering of the map scene in 3D. The engine will have the responsibility of processing raster layers with elevation into a mesh geometry and texturing the mesh with map images rendered by the existing QGIS 2D rendering engine. The engine will support levels of detail (LOD) and tiling in order to be able to display high-resolution data in real time without having to load all the data into memory at the time of scene creation (which may be prohibitively expensive with more complex layers). 3D scene will be dynamically updated as user browses the map, keeping the amount of rendered triangles low while appropriate quality of the terrain for given zoom level.

All of the processing needs to be done in the background, so the user may freely browse the map and the scene will be continuously updated with data (changing between higher/lower detail when zooming, loading more data when moving map).

  1. Handling of user input: controller for camera that will make the camera fly on top of the map. Support for picking will be added to allow identification of objects in the map and display of coordinates at the mouse position.
  1. Integration with QGIS environment: dockable 3D map widget for the main window, synchronization with 2D map canvas, support for printing of 3D views in map compositions.
  1. Advanced 3D rendering techniques: interface that will allow adding new methods for data visualization in 3D and exploration of methods for rendering. By default map layers will be rendered into map image with the existing 2D map renderer – this interface will allow map layers to instead have 3D renderer associated which will provide entities with custom meshes and materials. As a result we will be able to achieve true 3D appearance of objects (e.g. point clouds, trees as 3D models, tesselation of polygons, buildings with extruded geometry and custom texture). Implementation of the advanced techniques is a task with nearly unlimited scope, so the idea is to develop a suitable interface and as the time will allow, implement some techniques.

History: For this proposal I have studied various sources:

  • looked into existing 3D viewer projects related to QGIS
  • explored Qt 3D framework
  • researched some academic papers regarding terrain generation and vector data display

As a proof of concept, I have created a simple prototype in C++ using Qt 3D framework. It displays aerial imagery on top of a terrain model created from a raster layer (DEM) and allows simple camera control. The code is available here: https://github.com/wonder-sk/qgis3d

Qualifications: I have been a core QGIS developer for more than 10 years and I have a very good knowledge of QGIS codebase, especially the existing 2D map rendering pipeline.
Previously when working at the university, on a project for stereo matching (creation of point cloud out of a pair of images) I worked on visualization of 3D data using OpenGL.
Implementation Plan: The plan is to work on the project between May and July 2017. As of now, the plan for QGIS releases (according to the mail from Paolo) is that QGIS 3.0 will have feature freeze in July 2017 and final release in September 2017. If nothing changes in the QGIS release schedule in meanwhile, the 3D support could be integrated into QGIS master branch before the feature freeze and thus released in QGIS 3.0.
If the project would be accepted, the first step will be to develop a prototype of the 3D rendering engine, then prepare a more detailed architecture proposal as a QEP and continue the implementation once the QEP gets accepted by the community. The work progress should be available on a branch in GitHub for anyone interested.
Proposal Link: https://github.com/wonder-sk/qgis3d

6 PROCESSING ALGORITHM DOCUMENTATION

Proposers: Matteo Ghetta, Alexander Bruy

Amount: €4000

Details: This proposal aims to improve the existing Processing algorithms documentation. With the pull request https://github.com/qgis/QGIS/pull/3911 it is possible to add external links for the documentation (both local and remotes). However the effective use of the pull request is not yet included in Processing.

With this proposal the existing code will be incorporated in Processing, allowing to have a Short Help tab (the existing one on the right of the Processing algorithm window) and a Long Help tab (next to the Log tab).

The Short Help tab will be collapsible in order to have a bigger window for the algorithm parameters, while the Long Help tab will point to the on-line existing documentation of Processing for each algorithm (http://docs.qgis.org/testing/en/docs/user_manual/processing_algs/index.html).

The default link of the on-line documentation will be added in the QGIS Settings (thanks to the pull request already merged) in order to have the standard documentation visible but to let the user the choice to overwrite it and load custom paths.

In addition to the code part, this proposal aims also to document the GDAL/OGR provider and the QGIS core algorithms. Existing documentation will be reviewed and pictures will be added when useful, while for algorithm not yet documented, the help will be written from scratch with description and additional pictures.

Currently there are:

  • 49 GDAL/OGR total algorithms, 35 to enhance with pictures, 14 to write from scratch
  • 154 QGIS algorithms, 38 to enhance, 116 to write from scratch

This means a total of 73 algorithm to enhance and 130 to write from scratch.

History: The pull request https://github.com/qgis/QGIS/pull/3911 is already merged and it is worth to make it effective to have nice, rich and translatable documentation for the Processing algorithms.

Qualifications: Matteo Ghetta: working since the release 2.0 on the documentation and made several improvements and pull request to both documentation and Processing code.

Alexander Bruy: core developer since 2010, co-maintainer of the QGIS Processing framework.

Implementation Plan: The code and the documentation will be ready for the QGIS 3 release.

Proposal Link:

5 IMPROVE DEEP RELATIONS WITH POSTGRES EDITING

Proposer: Régis Haubourg

Amount: €6000

Details: QGIS has reached a mature level and offers now a very good framework to create professional applications. One of the main reasons is that QGIS is a very strong client for spatial databases, and in particular with PostgreSQL and postGIS for which it was initially created.

Since version 2.14, QGIS offers the not-so-well-known ability to handle transaction groups, which means it can instantly evaluate triggers on database side, and refresh all layers in the same transaction. This is a big win for usability, but some drawbacks glitches remain, such as the lack of the undo/redo edit buffer, a very raw way of saving (ie quitting edition session) or having the legend cluttered by so many edit symbols (a pen symbol). Current proposal is to go a step beyond to make QGIS even better for PostgreSQL by achieving the following targets:

1 Restore an undo /redo feature by taking advantage of PostgreSQL. If possible we will try to take advantage of PostgreSQL named Savepoints.

2 Allow to have some layers not switching to edit mode in QGIS,  even if they belong to the same connection. These layers will still benefit from the instant refresh, but won’t clutter the legend with the edit pen symbol everywhere, nor risk to load QGIS snapping cache for nothing. A UI for those settings could be an evolution of the current “identify layer” list in the project properties.

3 We would like to submit a mechanism to allow converting error messages raised by the provider, like a RAISE from postgres, into custom user oriented message. Say for instance, instead of a “provider error – duplicate key for… “, QGIS project could be tuned to display first “You tried to insert a feature using the same identifier as another one”.

The error message list and regexp rules would be optionally stored in qgis project or read from a datasource table (for instance when error messages rewrites are shared by other applications). The original error message would be still avaiblable by expanding the details of the messageBar and in the general message log.

4 Cherry on cake point, we wish to have QGIS take advantage of PostgreSQL NOTIFY signals to trigger behavior in QGIS when something changes in the database (see https://www.postgresql.org/docs/9.5/static/sql-notify.html) . A first implementation proposal is to allow a map canvas refresh, but we can imagine really dynamic applications driven by the database events by converting NOTIFY messages into QGIS signals (oh yeah!).

History: In our team, we already use transaction groups for production tools and that is much appreciated. We already use some python logic to catch error message and convert them to more user oriented ones. We frequently develop applications where QGIS is linked with heavy database containing most of the intelligence. Having a really interactive edition process, speaking the same langage as average users, and being able to be triggered from database process will unleashed many possible applications.

Qualifications: Oslandia has three QGIS developers, two of them being core comiters and high  skills with Postgres and Postgis (core comiter too). We believe that developing using thick databases is a major strength of QGIS, and we have great fun getting involved in that area of the code

Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Straight and curved arrows with QGIS

OSGeo Planet - Sat, 2017-04-29 19:42

After my previous posts on flow maps, many people asked me how to create the curved arrows that you see in these maps.

Arrow symbol layers were introduced in QGIS 2.16.

The following quick screencast shows how it is done. Note how additional nodes are added to make the curved arrows:


Categories: OSGeo Planet

QGIS Blog: Logo Evolution – Call to User Groups

OSGeo Planet - Sat, 2017-04-29 11:44

With QGIS 3.0 moving closer, it is also time to get the new QGIS logo out there.

QGIS logo evolution

We are therefore asking all our user groups to join the project redesign efforts. Please have a look at your user group logo and bring it in line with the QGIS 3.0 design.

We have compiled a Visual Style Guide which provides all logo materials, including fonts that you can use for your own user group logo. Here is an example of how the Italian user group has updated their logo:

Italian user group redesigned

We are looking forward to seeing all your creative efforts!


Categories: OSGeo Planet

OSGeo.nl: Bestuursverfrissingen (en een vacature)

OSGeo Planet - Fri, 2017-04-28 14:45
Tijd om terug te treden

Zoals bij velen wellicht al bekend verlaten Marc Vloemans en Gert-Jan van der Weijden per 1 juli het OSGeo.nl bestuur. Marc heeft 1 termijn de PR-trom geroerd, Gert-Jan is dan 2 termijnen voorzitter geweest. Dat biedt ruimte voor vers bloed (ideeën, inzichten en werkwijzen) en het leidt tot wat verschuivingen in het stichtingsbestuur!

Om met dat eerste te beginnen: we zijn blij dat Paulo van Breugel zich als bestuurslid heeft aangemeld.

Paulo van Breugel stelt zich voor

Ik ben een freelance onderzoeker / consultant op het gebied van bos en landschapsecologie, natuurbehoud en duurzaam landgebruik. Een terugkerend thema in mijn werk is daarbij het in kaart brengen en analyseren van ruimtelijke patronen en processen, van populatie tot landschapsniveau. Eerder heb ik gewerkt in Syrië, Brazilië en in Kenia voor onder meer Bioversity International, het World Agroforestry Centre en het International Livestock Research Institute.

Ik ben sterke voorstander van het gebruik van open data en open source software omdat dit, in mijn ervaring, leidt tot meer transparant onderzoek en betere toegang tot relevante informatie en data voor alle belanghebbenden. Voor mijn eigen werk leunt ik om die reden dan ook met name sterk op open source tools zoals GRASS GIS, R en QGIS.

Als open source gebruiker wil ik graag een bijdrage leveren aan de open source community, en hoop dat nu ook via osgeo.nl te doen. Een van de aandachtspunten waar ik me daarbij op wil richten is het gebruik van open source software voor geo-informatie in de academische wereld en het onderwijs.

Omdat een stichting geen officiële leden kent kiest het oude bestuur zelf de nieuwe bestuursleden. We hebben Paulo met algemene stemmen in ons bestuur gekozen!

Per 1 juli neemt Paulo de rol van secretaris over van Just van den Broecke. Just volgt Gert-Jan op als voorzitter en wordt daarmee naar buiten het belangrijkste gezicht van de Stichting OSGeo.nl. Barend blijft als penningmeester de centjes onder zijn hoede houden.

Nog een plekje vrij

One’s a company, two’s a crowd, three’s a party (sprak Andy Warhol ooit). Maar zelfs met 3 bestuursposten ingevuld vinden we dat er nog ruimte is in het OSGeo.nl bestuur voor iemand die zich met name wil bezighouden met het bespelen van (sociale) media. Denk daarbij aan het via deze website, Meetup, Twitter etc. verspreiden van nieuws over aankomende events, zorgen dat er verslagen in woord en beeld van komen, en dat ook de schrijvende pers enthousiast over open source voor geo blijft berichten. Interesse? Meer weten? Laat het weten via info@osgeo.nl.

 

 

Categories: OSGeo Planet

Nyall Dawson: About label halos

OSGeo Planet - Fri, 2017-04-28 10:46

A lot of cartographers have a love/hate relationship with label halos. On one hand they can be an essential technique for improving label readability, especially against complex background layers. On the other hand they tend to dominate maps and draw unwanted attention to the map labels.

In this post I’m going to share my preferred techniques for using label halos. I personally find this technique is a good approach which minimises the negative effects of halos, while still providing a good boost to label readability. (I’m also going to share some related QGIS 3.0 news at the end of this post!)

Let’s start with some simple white labels over an aerial image:

These labels aren’t very effective. The complex background makes them hard to read, especially the “Winton Shire” label at the bottom of the image. A quick and nasty way to improve readability is to add a black halo around the labels:

Sure, it’s easy to read the labels now, but they stand out way too much and it’s difficult to see anything here except the labels!

We can improve this somewhat through a better choice of halo colour:

This is much better. We’ve got readable labels which aren’t too domineering. Unfortunately the halo effect is still very prominent, especially where the background image varies a lot. In this case it works well for the labels toward the middle of the map, but not so well for the labels at the top and bottom.

A good way to improve this is to take advantage of blending (or “composition”) modes (which QGIS has native support for). The white labels will be most readable when there’s a good contrast with the background map, i.e. when the background map is dark. That’s why we choose a halo colour which is darker than the text colour (or vice versa if you’ve got dark coloured labels). Unfortunately, by choosing the mid-toned brown colour to make the halos blend in more, we are actually lightening up parts of this background layer and both reducing the contrast with the label and also making the halo more visible. By using the “darken” blend mode, the brown halo will only be drawn for pixels were the brown is darker then the existing background. It will darken light areas of the image, but avoid lightening pixels which are already dark and providing good contrast. Here’s what this looks like:

The most noticeable differences are the labels shown above darker areas – the “Winton Shire” label at the bottom and the “Etheridge Shire” at the top. For both these labels the halo is almost imperceptible whilst still subtly doing it’s part to make the label readable. (If you had dark label text with a lighter halo color, you can use the “lighten” blend mode for the same result).

The only issue with this map is that the halo is still very obvious around “Shire” in “Richmond Shire” and “McKinlay” on the left of the map. This can be reduced by applying a light blur to the halo:

There’s almost no loss of readability by applying this blur, but it’s made those last prominent halos disappear into the map. At first glance you probably wouldn’t even notice that there’s any halos being used here. But if we compare back against the original map (which used no halos) we can see the huge difference in readability:

Compare especially the Winton Shire label at the bottom, and the Richmond Shire label in the middle. These are much clearer on our tweaked map versus the above image.

Now for the good news… when QGIS 3.0 is released you’ll no longer have to rely on an external illustration/editing application to get this effect with your maps. In fact, QGIS 3.0 is bringing native support for applying many types of live layer effects to label buffers and background shapes, including blur. This means it will be possible to reproduce this technique directly inside your GIS, no external editing or tweaking required!

Categories: OSGeo Planet

From GIS to Remote Sensing: SCP Questions of This Month: April

OSGeo Planet - Fri, 2017-04-28 09:00
This post is a collection of questions and answers about the Semi-Automatic Classification Plugin (SCP) and remote sensing which were discussed in the Facebook group and the Google+ Community this month.
These questions vary from supervised classification technique to software issues, and can be useful to the readers of this blog for solving issues about the use of SCP.

Categories: OSGeo Planet

GeoServer Team: GeoServer monthly bug stomp

OSGeo Planet - Thu, 2017-04-27 05:12

Our monthly GeoServer bug stomps are moving to the last Friday of each month.

bug_stomp

Previously these events were scheduled when people were available, making planning difficult. By choosing a set date each month it is easier to schedule a time to participate for all involved.

Tips for Participating

Thanks to Matt Kruszewski for the following notes on how to take part.

Before you start

Get ready:

  1. Join the gitter.im channel geoserver/geoserver, you can sign in with your github id.
  2. Sign up for Jira, so you can review and add to bugs.
  3. Join the geoserver-devel@lists.sourceforge.net and introduce yourself!  In your email, you can be asked to be added to the Jira development team (so you can volunteer to work on a bug during the sprint).
  4. Double check the contributing guidelines (you may need to sign a code license agreement prior to starting work.)

Git ready:

# GeoServer uses Fork & Branch GitFlow
# Fork the geoserver/geoserver project on github, then clone it locally and add the main
# project as an upstream.

git clone https://github.com/{you}/geotools.git

git remote add upstream https://github.com/geoserver/geoserver.git

git pull –rebase upstream

git checkout -b myBugfixBranch

# Before making a pull request, make sure you are up-to-date with upstream.

git pull –rebase upstream master

# (or, rebase)

For the bug stomp you should work on a branch from master.

Eclipse or InteliJ recommended:

  • If you are setting up GeoServer for the first time as developer Quickstart in the developers guide.

Stomping

If you get stuck or are unsure of how to proceed, ask on gitter!

To find an issue to work on:

  1. Ask on Gitter, and use the Jira triage list of good candidates (triage=sprint).
  2. At the start of the sprint we review new bugs.

Style:

  1. Make sure to follow the contribution guidelines
  2. Format your code using the eclipse formatter profile here. The same formatter is used for GeoTools and GeoServer.
  3. Make sure to add the license boilerplate
  4. Consult the GeoTools code conventions for common habits
  5. Documentation is required for a UI fix, javadocs for public classes appreciated.

Testing:

  1. Test your fix!
  2. See Testing in the GeoServer Developers Guide
  3. Since this is a bug stomp, look at how the code around yours is tested and build on that.

Pull Request

  1. Make a pull request from your branch on your fork to geoserver/geoserver master.
  2. Ask for a review on gitter
  3. Make revisions based on feedback and comments. Additional commits to the branch in your fork are automatically reflected in the PR.

Tips and Tricks

  • We work closely with the GeoTools library for data access, rendering and processing – you may need a checkout of the GeoTools library to be effective.
  • For the bug stomp, pick a bug you can fix, not one you need to fix.
    • Many older issues are already fixed, start by trying to reproduce the problem.
    • Many worth while bugs cannot be fixed in a day
  • Don’t get stuck. Timebox yourself and don’t be afraid to discuss the problem on gitter.
  • Use the code formatter!
  • Don’t worry about making mistakes!  You can run findbugs, or ask for a shared screen code review before submitting your pull request (or “relax and realize the internet is full of fail”.)

Follow-up

  • After the bug stomp, reply to the geoserver-devel email thread with a summary of your progress

Most of all welcome to GeoServer and thanks for taking part.

Categories: OSGeo Planet

gvSIG Team: gvSIG (de nuevo) en prensa generalista

OSGeo Planet - Wed, 2017-04-26 09:26

De nuevo la prensa se hace eco del premio recibido de mano de la Comisión Europea al mejor proyecto europeo de software libre.

En este caso el periódico Las Provincias ha dedicado un espacio a hablar de los logros del proyecto gvSIG. Particularmente me ha gustado que se destaque, más allá de la parte técnica, la componente económica que juega el proyecto y que aporta a un nuevo modelo de producción del software: “La Comisión ha premiado a gvSIG porque permite el desarrollo económico mediante la especialización tecnológica en un sector emergente como el de la Geolocalización.”

La noticia en digital la podéis consultar aquí.


Filed under: premios, software libre, spanish Tagged: prensa
Categories: OSGeo Planet

Paulo van Breugel: Plotting GRASS data in Python

OSGeo Planet - Mon, 2017-04-24 12:13
GRASS GIS offers some useful but basic plotting options for raster data. However, for plotting of data in attribute tables and for more advanced graphs, we need to use other software tools. In this tutorial I explore some of the possibilities offered by Pandas plot() and how we can further tune plots using matplotlib / …

Continue reading Plotting GRASS data in Python

Categories: OSGeo Planet

GeoServer Team: GeoServer 2.10.3 Released

OSGeo Planet - Mon, 2017-04-24 08:37

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

This is the release of GeoServer of the 2.10 branch is now going into maintenance and is no longer recommended for new production system. This release is made in conjunction with GeoTools 16.3.

This release is made by Ian Turton from the Astun Technology team. We would like to thank these volunteers  and everyone who contributed features, fixes and time during the release process.

New Features and Improvements
  • [GEOS-7684] – Add rest endpoint for geofence admin rules
  • [GEOS-7763] – Add REST endpoint for a user to change their password
  • [GEOS-7957] – GeoFence: REST Rule DTO does not handle addressrange
  • [GEOS-8022] – Allow disabling usage of SLD and SLD_BODY in WMS requests (also for virtual services)
Bug Fixes

A large number of bugs were fixed for this release including several that affected JMS clustering, WFS with 3D data and using the Style Editor with non-SLD styles. See the release notes for more details of all the fixes.

Categories: OSGeo Planet

Equipo Geotux: Funcionalidad de Exportar/Importar para el plugin AutoFields

OSGeo Planet - Fri, 2017-04-21 14:06

Una de las funcionalidades más solicitadas para el plugin de QGIS 'AutoFields' ha sido implementada: la manera de exportar e importar AutoFields previamente configurados.

 

Si no conoces qué son los AutoFields, lee primero Plugin AutoFields para QGIS.

 

Piensa por ejemplo en entregar a tus clientes AutoFields configurados junto a datos geográficos; piensa en compartir AutoFields con tus compañeros de trabajo; o quizá solo trabajar en dos ambientes y mantener sincronizados tus datos y sus configuraciones. Todos esos escenarios son ahora posibles con AutoFields v0.5.0. En este post te muestro cómo.

 

Exportando AutoFields

Una vez que hayas configurado tus AutoFields en QGIS, puedes exportarlos a un archivo JSON. Para ello, dale click al botón "Export to JSON file" para abrir el siguiente diálogo:


Selecciona los AutoFields que te gustaría exportar, elige si quieres remover los AutoFields exportados de tu QGIS, define la ruta al archivo JSON, y has click en el botón OK.

Importando AutoFields

Para importar AutoFields deberías contar con un archivo JSON. Has click sobre el botón "Import AutoFields from a JSON file" y selecciona dicho archivo JSON. Si el archivo es válido (esto es, si contiene AutoFields), se abrirá este diálogo:

 

 

Como puedes observar, se listan todos los AutoFields que contiene el archivo JSON. Puedes asignar cada AutoField a una capa (y campo) ya cargada en QGIS. Para facilitar la importación, el plugin intenta emparejar AutoFields con capas/campos por ti.

 


Las flechas indican la manera en que los AutoFields son asignados a las capas/campos:

Gris Indica que el AutoField no será importado y será ignorado en el proceso de importación.
Naranja
Indica que el AutoField será importado, pero sobreescribirá un AutoField existente en la capa y…
Read more...
Categories: OSGeo Planet

GeoTools Team: GeoTools 16.3 Released

OSGeo Planet - Thu, 2017-04-20 10:33
The GeoTools team is pleased to announce the release of GeoTools 16.3:This release is also available from our maven repository.

This release is made in conjunction with GeoServer 2.10.3.

GeoTools 16.3 is the first maintenance release of the 16.x series and 17.0 is now recommended for all new projects. In future this branch will only receive bug fixes but no new features will be added.


The GeoTools team is grateful for Astun Technology for sponsoring this release.Features and ImprovementsFeatures & Improvements
  • gs:PointStacker now has an attribute that holds the bounding box of the clustered features 
  • TransparencyFill process has been added to the unsupported/process-raster module 
  • GeoTools now uses Java 7 Base64 Encoder / Decoders throughout. 
Bug
  • Shapefile attribute (DBF) DbaseFileReader reads numeric empty values as zero 
  • Mollweide projection misses parameter
  • PostGIS sql dialect fails to encode 3D bbox filters
  • GridCoveargeRenderer.renderImage may throw a NPE
  • ProjectionHandler.getQueryEnvelopes can return invalid envelopes for transverse mercator
  • Geometries not created when using WFS data store 2.0.0
  • Band selection via request param and RBG expansion are incompatible
  • ImageWorker should invalidate statistics after a Crop
  • Shapefile dumper throws a NPE on NULL geometry values
  • Crop and rescale to bytes fail to propagate nodata values
  • Incorrect validation when parsing XML schema element declaration with ref attribute
And more! For more information please see the release notes (16.316.2 | 16.1 | 16.0 | 16-RC1 | M0 | beta).
Categories: OSGeo Planet
Syndicate content