OSGeo Planet

Free and Open Source GIS Ramblings: Stand-alone PyQGIS scripts with OSGeo4W

OSGeo Planet - Sun, 2019-03-03 20:03

PyQGIS scripts are great to automate spatial processing workflows. It’s easy to run these scripts inside QGIS but it can be even more convenient to run PyQGIS scripts without even having to launch QGIS. To create a so-called “stand-alone” PyQGIS script, there are a few things that need to be taken care of. The following steps show how to set up PyCharm for stand-alone PyQGIS development on Windows10 with OSGeo4W.

An essential first step is to ensure that all environment variables are set correctly. The most reliable approach is to go to C:\OSGeo4W64\bin (or wherever OSGeo4W is installed on your machine), make a copy of qgis-dev-g7.bat (or any other QGIS version that you have installed) and rename it to pycharm.bat:

Instead of launching QGIS, we want that pycharm.bat launches PyCharm. Therefore, we edit the final line in the .bat file to start pycharm64.exe:

In PyCharm itself, the main task to finish our setup is configuring the project interpreter:

First, we add a new “system interpreter” for Python 3.7 using the corresponding OSGeo4W Python installation.

To finish the interpreter config, we need to add two additional paths pointing to QGIS\python and QGIS\python\plugins:

That’s it! Now we can start developing our stand-alone PyQGIS script.

The following example shows the necessary steps, particularly:

  1. Initializing QGIS
  2. Initializing Processing
  3. Running a Processing algorithm
import sys from qgis.core import QgsApplication, QgsProcessingFeedback from qgis.analysis import QgsNativeAlgorithms QgsApplication.setPrefixPath(r'C:\OSGeo4W64\apps\qgis-dev', True) qgs = QgsApplication([], False) qgs.initQgis() # Add the path to processing so we can import it next sys.path.append(r'C:\OSGeo4W64\apps\qgis-dev\python\plugins') # Imports usually should be at the top of a script but this unconventional # order is necessary here because QGIS has to be initialized first import processing from processing.core.Processing import Processing Processing.initialize() QgsApplication.processingRegistry().addProvider(QgsNativeAlgorithms()) feedback = QgsProcessingFeedback() rivers = r'D:\Documents\Geodata\NaturalEarthData\Natural_Earth_quick_start\10m_physical\ne_10m_rivers_lake_centerlines.shp' output = r'D:\Documents\Geodata\temp\danube3.shp' expression = "name LIKE '%Danube%'" danube = processing.run( 'native:extractbyexpression', {'INPUT': rivers, 'EXPRESSION': expression, 'OUTPUT': output}, feedback=feedback )['OUTPUT'] print(danube)

Categories: OSGeo Planet

GeoTools Team: GeoTools 21.0 Released

OSGeo Planet - Sun, 2019-03-03 17:29
The GeoTools is pleased to announce the release of GeoTools 21.0 our first release with both Java 11 and Java 8 compatibility: geotools-21.0-bin.zip geotools-21.0-doc.zip geotools-21.0-userguide.zip geotools-21.0-project.zip maven repository This is a stable release of GeoTools made in conjunction with GeoServer 2.15 and GeoWebCache 1.15. Release highlights: Works with both Java 11 and Java
Categories: OSGeo Planet

Cameron Shorter: Starting build cycle for OSGeoLive 13.0

OSGeo Planet - Sun, 2019-03-03 00:04
Are you interested in joining our Open Source GIS experience? The build cycle for the next OSGeoLive release 13.0, is going to start. The final version is planned to be ready on 30th July 2019 in time for FOSS4G 2019 in Bucharest. Have a look at our schedule for the detailed steps.
Till then we have many challenges - from simple to challenging, to help describe and train people in the value of Open Source GIS.
For this release, we hope to help OSGeo Community projects join OSGeoLive, and work out how we can keep within our size constraints.
We'd love to build a cloud version of OSGeoLive for this release. It would make OSGeoLive, and OSGeo software much more accessible. It seems elusively achievable, but we haven't worked it out yet. If you think you could help, we'd love to hear from you.
Get involvedAre you a programmer or packager with experience in one of the Open Source GIS applications. Are you a technical writer interested in making FOSS4G accessible to all? Are you interested in helping update translations to latest documents on Transifex.
Contact usIf you would like to add a new project, help us to get in the cloud or have another goal you would like to work on and get involved you are very welcome.

Please join the OSGeoLive mailing list or meet us on IRC at our weekly meeting.
About OSGeoLiveOSGeoLive is a ​Lubuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. You can use OSGeoLive to try a wide variety of open source geospatial software without installing anything.

Categories: OSGeo Planet

Free and Open Source GIS Ramblings: Easy Processing scripts comeback in QGIS 3.6

OSGeo Planet - Sat, 2019-03-02 13:22

When QGIS 3.0 was release, I published a Processing script template for QGIS3. While the script template is nicely pythonic, it’s also pretty long and daunting for non-programmers. This fact didn’t go unnoticed and Nathan Woodrow in particular started to work on a QGIS enhancement proposal to improve the situation and make writing Processing scripts easier, while – at the same time – keeping in line with common Python styles.

While the previous template had 57 lines of code, the new template only has 26 lines – 50% less code, same functionality! (Actually, this template provides more functionality since it also tracks progress and ensures that the algorithm can be cancelled.)

from qgis.processing import alg from qgis.core import QgsFeature, QgsFeatureSink @alg(name="split_lines_new_style", label=alg.tr("Alg name"), group="examplescripts", group_label=alg.tr("Example Scripts")) @alg.input(type=alg.SOURCE, name="INPUT", label="Input layer") @alg.input(type=alg.SINK, name="OUTPUT", label="Output layer") def testalg(instance, parameters, context, feedback, inputs): """ Description goes here. (Don't delete this! Removing this comment will cause errors.) """ source = instance.parameterAsSource(parameters, "INPUT", context) (sink, dest_id) = instance.parameterAsSink( parameters, "OUTPUT", context, source.fields(), source.wkbType(), source.sourceCrs()) total = 100.0 / source.featureCount() if source.featureCount() else 0 features = source.getFeatures() for current, feature in enumerate(features): if feedback.isCanceled(): break out_feature = QgsFeature(feature) sink.addFeature(out_feature, QgsFeatureSink.FastInsert) feedback.setProgress(int(current * total)) return {"OUTPUT": dest_id}

The key improvement are the new decorators that turn an ordinary function (such as testalg in the template) into a Processing algorithm. Decorators start with @ and are written above a function definition. The @alg decorator declares that the following function is a Processing algorithm, defines its name and assigns it to an algorithm group. The @alg.input decorator creates an input parameter for the algorithm. Similarly, there is a @alg.output decorator for output parameters.

For a longer example script, check out the original QGIS enhancement proposal thread!

For now, this new way of writing Processing scripts is only supported by QGIS 3.6 but there are plans to back-port this improvement to 3.4 once it is more mature. So give it a try and report back!

Categories: OSGeo Planet

GeoServer Team: GeoServer 2.15.0 Released

OSGeo Planet - Sat, 2019-03-02 10:16

The GeoServer team is happy to announce the GeoServer 2.15.0 release with downloads (zip|war|exe), documentation (html|pdf) and extensions.

This release is production ready and is ready to work with your Java 8 or Java 11 operational environment. This release is made in conjunction with GeoWebCache 1.15.0 and GeoTools 21.0.

The ability to work with Java 11 is the result a dedicated code sprint. Thanks to organizations participating in the code sprint (Boundless, GeoSolutions, GeoCatAstun TechnologyCCRi) along with sprint sponsors (Gaia3Datol, osgeo:uk, Astun Technology).

Layer Service Settings

To start things off an often requested capability, the ability to control which services are enabled on a layer-by layer basis.

To try it our yourself see Service Settings in our user manual.

GeoFence Internal Server Extension

Originally a standalone service offering fine grain control over GeoServer security this functionality has been packaged up and embedded into a GeoServer extension for easier deployment.

  • GeoFence rules provided greater control over security allowing layer by layer service restrictions
  • GeoFence rules can provide access to data overriding layer details including CQL filter to limit contents returned and default style used for rendering
  • GeoFence rules can limit access to a geographic extent

For more details see GeoFence Internal Server in our user manual.

Style Editor SLD Auto-Complete

To help make editing easier the Style Editor can provide auto-complete suggestions for SLD 1.0. To try it out yourself use control-space for context aware suggestions.

Generate Classified Thematics maps

SLDService is now an official extension, with a number of improvements. SLDService can now be used for the

  • classification of raster data too
  • equal area classification
  • standard deviation filtering

The SLD REST Service extension is used to generate thematic styles based on attribute data:

curl -v -u admin:geoserver -XGET http://localhost:8080/geoserver/rest/sldservice/states/classify.xml ?attribute=PERSONS &ramp=CUSTOM &method=quantile &intervals=3 &startColor=0xFF0000 &endColor=0x0000FF &open=true

For more information see SLD Rest Service in our user manual.

WPS GetExecutionStatus and Dismiss Operations

WPS “GetExecutions” vendor operation allows each user to get the list of running processes:

  • Users can review all their running processes
  • Administrators can see all processes

The Dismiss vendor operation can be used to cancel the execution of one of the listed processes.

For more information see Dismiss in our user guide.

Java 11 Support

The provided binary download works with either Java 8 or Java 11. Tomcat 9 or newer is required for the WAR install. The user guide compatibility list will continue to be updated based on your feedback.

The java ecosystem is now being led by the open source OpenJDK project, with long term support available from a range of organizations notably RedHat OpenJDK  and Adopt OpenJDK. The GeoTools user guide provides an overview of Java 8 and Java 11 distributions.

The net effect of these changes:

  • If you have been using Oracle JDK please review your options
  • Java 8 will continue to be available
  • The Java ecosystem is now led by the open-source Open JDK project

Java 11 no longer supports the Java 2 extension mechanism used for native JAI and native ImageIO libraries.  We recommend the use of the pure Java JAI-EXT operations which have been made the default (see the next section).

JAI-EXT operations on by default

The use of the JAI-EXT operations have long been a recommendation, with this release we are making them the default for GeoServer.  The JAI-EXT library offers a pure java implementation enhanced for geospatial functionality supporting NODATA pixels and support for vector footprints.

GeoServer Codebase

In addition to Java 11 support this release includes:

  • Add JSON as a Legend Output format (GISP 173)
  • Printing plugin upgrade version of JTS
  • Upgrade NetCDF dependencies
  • Improvements for vector tile production, both in terms of output correctness and production performance

Thanks to Andrea Aime for steady work on the codebase quality:

  • PMD source code analysis, high priority checks, will fail the build in case of issues
  • Error Prone byte code analysis, same as above
  • Many small bugs fixed

For more details developers are invited to review Automated Quality Assurance checks in our developers manual. Also, work in ongoing on the master (dev) branch to extend the reach of static code checks using SpotBugs and CheckStyle too.

About GeoServer 2.15 Series

Additional information on the GeoServer 2.15 series:

Categories: OSGeo Planet

Martin Davis: Better/Faster ST_PointOnSurface for PostGIS

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

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

   select ST_PointOnSurface(geom) from ebc.voting_area;

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

Data sizeTimeTime
ST_Centroid5,658 polygons
(2,171,676 vertices)341 ms4,613 msx 13369 ms
As expected, there is a dramatic improvement in performance.  The improved ST_PointOnSurface runs 13 times faster than the old code.  And it's now as fast as ST_Centroid.  It's also more robust and tolerant of invalid input (although this test doesn't show it).

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

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

Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.5: Enumeración de capas en la Tabla de Contenidos

OSGeo Planet - Thu, 2019-02-28 16:06

Una de las componentes más utilizadas en un SIG es su Tabla de Contenidos, también conocida como TOC por sus siglas en inglés.

En la Tabla de Contenidos se enumeran todas las capas de una Vista y se muestra la leyenda con la que se representan las entidades de cada capa. También ayuda a administrar el orden de visualización de las capas en la Vista, a definir las capas que son visibles, las que están seleccionadas, permite el acceso rápido a distintas herramientas, etc.

Ya en gvSIG Desktop 2.4 iniciamos las mejoras en el TOC con la existencia de un catálogo, que permite la carga rápida de capas y la gestión de favoritos. En la nueva versión, gvSIG 2.5, encontraréis un nuevo plugin “Tabbed TOC” con el que continuamos estas mejoras.

Mediante este nuevo plugin añadimos a la Tabla de Contenidos una serie de nuevas opciones para enumerar o agrupar las capas de nuestra Vista.

Además de la enumeración principal podremos listar las capas según la fuente, si son o no visibles y si tienen o no elementos seleccionados. El procedimiento es muy sencillo, hacer clic en el icono de la parte superior del TOC que permite acceder a alguno de los métodos de agrupación.

Para ver cómo instalar este nuevo plugin y su funcionamiento, os dejamos con este vídeo:

Categories: OSGeo Planet

gvSIG Team: Towards gvSIG 2.5: Listing layers at the Table of Contents

OSGeo Planet - Thu, 2019-02-28 15:57

One of the most used components in a GIS is the Table of Contents, also known as TOC.

All the layers of a View are listed at the Table of Contents, and the legend with which the entities of each layer are represented is shown too. It also helps to manage the display order of the layers in the View, to define the layers that are visible, which layers are selected, it allows quick access to different tools, etc.

In gvSIG Desktop 2.4, we started improvements in the TOC with a catalog, which allows to load layers quickly and manage the favourite ones. In the new version, gvSIG 2.5, you will find a new plugin called “Tabbed TOC” with which we are continuing these improvements.

Through this new plugin we add a series of new options to the Table of Contents to list or group the layers of our View.

Besides the main list, now we can list the layers according to the source, if they are visible or not, and if they have selected elements or not. The procedure is very simple, you have to click on the icon on the top of the TOC and it allows to access to any of the grouping methods.

Here you have a video about how to install this new plugin and how it works:


Categories: OSGeo Planet

Fernando Quadro: Introdução ao Leaflet – Trilhas com GeoJSON

OSGeo Planet - Thu, 2019-02-28 12:25

Para adicionar uma trilha ao nosso mapa, vamos convertê-lo de um shapefile para GeoJSON. Há mais de uma maneira de fazer isso – você poderia usar ogr2ogr, mas optamos por usar o QGIS, pois ele não apenas o converteria, mas também transformaria o sistema de coordenadas ao mesmo tempo.

1. Convertendo para GeoJSON

Com o shapefile carregado no QGIS, podemos clicar com o botão direito na camada e escolher a opção “Export -> Save Features As…

Escolhemos o sistema de coordenadas apropriado ( EPSG:4326 – WGS 84) para uso com o Leaflet e o QGIS faz a conversão enquanto salva no GeoJSON. Isso torna nossa trilha pronta para uso no Leaflet.

2. Adicionando o arquivo

O arquivo GeoJSON precisa ser adicionado ao nosso arquivo HTML como um script, mas primeiro precisamos modificá-lo adicionando um nome de variável:

var trail = { "type": "FeatureCollection", "name": "rails", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3857" } }, "features": [ ...

Adicionando o var trail ao início do arquivo nos permitirá fazer referência a ele no Leaflet.

Em seguida, adicionamos o script e agora podemos adicioná-lo ao mapa:

var trail = L.geoJSON(trail); trail.addTo(map);

3. Estilizando a trilha

Podemos mudar a aparência da trilha adicionando opções à declaração L.geoJSON:

  var thetrail = L.geoJSON(trail, {       color: '#800000',       weight: 3,       dashArray: '12 8 12',   });

Isso transforma a trilha em vermelho escuro, aumentando sua largura para 3 pixels e criando uma linha tracejada.

4. Adicionando rótulo

Ao adicionar este rótulo quando se passa o mouse sobre a trilha o mesmo é apresentado na tela:

thetrail.bindTooltip('Trilha de Brumadinho')

5. Resultado

Após nossas mudanças o resultado do nosso mapa agora é esse:

6. Código

Após as alterações realizadas acima, o nosso código ficou da seguinte forma:

<!DOCTYPE html> <head>   <link rel="stylesheet" href="https://unpkg.com/leaflet@1.4.0/dist/leaflet.css"   integrity="sha512-puBpdR0798OZvTTbP4A8Ix/l+A4dHDD0DGqYW6RQ+9jxkRFclaxxQb/SJAWZfWAkuyeQUytO7+7N4QKrDh+drA=="   crossorigin=""/>     <script src="https://unpkg.com/leaflet@1.4.0/dist/leaflet.js"   integrity="sha512-QVftwZFqvtRNi0ZyCtsznlKSWOStnDORoefr1enyq5mVL4tmKB3S/EnC3rRJcxCPavG10IcrVGSmPh6Qw5lwrg=="   crossorigin=""></script>   <script src="rails.geojson"></script> <style>     #mapDIV{         height: 700px;         width: 700px;         border: solid 1px black;     } </style> </head> <body>     <div id='mapDIV'></div> <script>     var map = L.map(document.getElementById('mapDIV'), {     center: [-20.1438, -44.1301],     zoom: 15     });     var basemap = L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {         });     basemap.addTo(map);     var earthquakeMarker = L.marker([-20.1438, -44.1301],          {title: 'Janeiro 25, 2019 Desastre de Brumadinho'});       earthquakeMarker.bindPopup(          "Janeiro 25, 2019<br> Desastre de Brumadinho");       earthquakeMarker.addTo(map);       var thetrail = L.geoJSON(trail, {         color: '#800000',         weight: 3,         dashArray: '12 8 12',     });     thetrail.bindTooltip('Trilha de Brumadinho');     thetrail.addTo(map); </script> </body> </html>
Categories: OSGeo Planet

gvSIG Team: Towards gvSIG 2.5: New OSM map servers

OSGeo Planet - Thu, 2019-02-28 09:48

Surely most of you know the OpenStreetMap (OSM) cartography, and almost certainly you have used it in some of your projects with gvSIG Desktop. Now we have added three new servers to the great number of OSM servers that were already available in gvSIG, that we think that will be interesting for certain uses:

  • OSM France. Oriented to show the OSM data with the toponymy in French and the most representative symbols of French culture (for example, bakeries are represented with the symbol of a baguette). Surely it will be useful for the growing French-speaking gvSIG Desktop users community.
  • Hillshading. It shows the relief of the ground through a representation using grey tones.
  • OSM B&W. In this case it shows the OSM cartography, as represented by Mapnik, but without using colours, only using grey tones.

Here you have a video where you can see these three new OSM servers:

And if you don’t want to wait for the new gvSIG Desktop version to use them, you can add them manually filling in these parameters at the “OSM” tab of the “Add layer” window:

Categories: OSGeo Planet

GIScussions: Citymapper – London’s Uber?

OSGeo Planet - Wed, 2019-02-27 17:56
Tube map jigsaw puzzle Travel Puzzle

Last week Citymapper (one of the poster children of the UK’s OpenData movement) announced the launch of their CityMapper PASS card.

Citymapper started out with a travel app based on the early releases of transport open data by UK public providers, they then launched a hopper bus service for a short while and this morphed into their shared taxi service “Ride“. Along the way they raised an enormous amount of funding for a relatively small startup – according to Crunchbase they had a $10m Series A in 2014 and a $40m Series B in 2016 with some pretty serious investors coming on board. Now they have launched their PASS which potentially can save users upwards of £4 per week on the cost of an Oyster Card (London Transport’s contactless card). The Guardian explained the basic finances here

“While the pass will bring in revenue, it will also result in the company losing money, at least in the short term. Technically, it operates as a simple pre-paid debit card, with Citymapper paying TfL for each journey its users take until they hit the standard weekly price cap.
That means that every user who reaches the daily Tube price cap (£7.00 for zones one and two) at least five days in seven will result in Citymapper losing money on them that week. The company’s explicit plan to counter that loss is to expand the pass by bundling in ever more private offerings, where it has more power to negotiate prices, until it offers a bundle that covers everything from dockless bikes, through rental cars, to ridesharing services.”


If PASS is going to reach a critical mass (is that 10,000, 100,000 or more users?) they could be losing £15-20 per user per month at which point they will burn through their cash resources pretty quickly. The last accounts that Citymapper filed are for 2017 they show cash balances of £12.5m after an in year loss of £6.3m. It looks as if Citymapper will need another investment round to support an aggressive launch of PASS and the costs of acquiring users until they find ways to make the service profitable.

Does this matter? Just after the launch was announced JA Early said

It's not ever really been clear how Citymapper was supposed to make money. So, I assume, it's been funded by people who understand the immense value of data derived from sitting at the centre of a large network that tracks the travel times and habits of millions of urbanites.

— J A Earley (@AlbyEarley) February 21, 2019

The only way Citymapper can make serious money is through wielding the political power it will accrue from its dominant position in the marketplace.

It will eventually turn on the consumer, regulators and the public realm to carve out a lucrative niche.

— J A Earley (@AlbyEarley) February 21, 2019

Or as the Guardian concluded

“But the launch of the service has prompted concerns from some that the company’s end goal is to try and burn its funding to establish a large base of users that it can then wield in political battles with city authorities to gain better terms for itself. That model has brought success for companies like Uber and Airbnb, which have reshaped regulations around their needs in cities including San Francisco, New York and Paris.”


Time will tell whether this pivot will work for Citymapper and their backers, I’m doubtful whether there is enough demand for this all inclusive multimodal public transport payment system. Of course Uber have shown how you can disrupt a market by throwing enough investors’ money at undercutting existing players, whether that is good in the long term for users of these services remains to be seen.

Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.5: Nuevos servicios de mapas de OSM

OSGeo Planet - Wed, 2019-02-27 14:42

Seguro que la gran mayoría de vosotros conocéis la cartografía de OpenStreetMap (OSM), y con casi toda seguridad la habréis utilizado en alguno de vuestros proyectos con gvSIG Desktop. Al buen número de servidores de OSM que ya estaban disponibles en gvSIG hemos añadido tres nuevos que consideramos que pueden ser interesantes para determinados usos:

  • OSM France. Orientado a mostrar los datos de OSM con la toponimia en francés y simbología más representativa de la cultura francesa (por ejemplo las panaderías ser representan con el símbolo de una baguette). Seguramente será de utilidad para la cada vez mayor comunidad francófona de usuarios de gvSIG Desktop.
  • Hillshading. Muestra el relieve del terreno mediante una representación del mismo utilizando tonos de gris.
  • OSM B&W. En este caso muestra la cartografía de OSM, tal y como la representa Mapnik, pero sin uso del color, utilizando unicamente tonos de grises.

Podéis ver un vídeo en el que se muestran estos 3 nuevos servicios de OSM:

Y si no queréis esperar a la nueva versión de gvSIG Desktop para utilizarlos, los podéis añadir manualmente introduciendo estos parámetros en la pestaña de OSM de la ventana de “Añadir capa”:

Categories: OSGeo Planet

gvSIG Team: Towards gvSIG 2.5: New geoprocess, Grid by point density

OSGeo Planet - Wed, 2019-02-27 11:24

In the previous post we talked about a series of geoprocesses related to criminology made together with Jaume I University (UJI). These geoprocesses can be used in different fields, not exclusively in criminology.

Now we are going to show the “Grid by point density” geoprocess. The main objective of this geoprocess is to perform a fast and efficient count of points contained in a grid, that also is created by the geoprocess. Here it has been raised for crimes, but it can be applied to many other things. It allows to visualize how events are distributed when there is a layer with a large accumulation of them in the same areas quickly.

Crimes in New York (150.000 features)

The input parameters are a point layer and an expression (optional) that would be a filter to run the geoprocess. For example, we could apply a filter by type of crime.

The options make reference to:

  • Grid distance: At the distance from the side of each square or hexagon. In relation to the measurements of the View.
  • Grid type: It can be squared or hexagonal. And in hexagonal type there are two types: Vertical or horizontal.
  • Add empty grids: It doesn’t add grid in areas where there are no specific elements, that is, where their count is zero.

It’s important to select the grid extension in the Analysis Region tab correctly.

The results of the geoprocess on the starting image layer returns a grid with an attribute table, where we will be able to apply a legend by intervals of values.

Here you can see the results on the complete crime layer with a shorter distance and vertical grid type.

And here applying a filter on a district.

In the attribute table you can see the total count of points within each grid, the total points involved in the initial calculation before filtering, and the percentage of those points in relation to the total.

In addition, we have taken advantage of this during the development of this geoprocess to improve and debug gvSIG to support layers with a larger number of records. One of these tests for this geoprocess was done with a layer with more than 6.7 million records and more than 10 fields.

You can now download and test the new Grid by point density geoprocess in the new distribution candidate to final version. You can download it from Tools -> Add-ons Manager, and search the “Geoprocess: Point density grid” geoprocess. Once installed and after restarting gvSIG, it will appear at the toolbox in the “Scripting – Data Analysis – Grid by density of points” section.

If you find any error or you have any recommendation, we encourage you to write to the gvSIG mailing lists.

Categories: OSGeo Planet

Fernando Quadro: Introdução ao Leaflet – Adicionando Marcador

OSGeo Planet - Wed, 2019-02-27 10:30

Estou começando devagar, então hoje vamos adicionar um marcador com alguns recursos extras. Já que o mapa de ontem já está centralizado no Desastre de Brumadinho, vamos adicionar um marcador lá.

1. Adicionando um Marcador

Para criar um marcador, o Leaflet usa a classe L.marker:

var earthquakeMarker = L.marker([-20.1438, -44.1301]);

Isso cria o marcador, porém precisa ser adicionado ao mapa:


E o nosso mapa fica assim:

Bom até agora, mas olhando para o mapa não nos diz nada sobre o marcador. Vamos mudar isso adicionando um título:

var earthquakeMarker = L.marker([-20.1438, -44.1301],      {title: 'Janeiro 25, 2019 Desastre de Brumadinho'});

Agora, quando passamos o marcador, recebemos um título:

Agora, vamos adicionar um pop-up ao marcador para exibir mais informações no evento do click. Fazemos isso vinculando um pop-up ao nosso marcador existente:

var earthquakeMarker = L.marker([-20.1438, -44.1301], {title: 'Janeiro 25, 2019 Desastre de Brumadinho'}); earthquakeMarker.bindPopup("Janeiro 25, 2019
Desastre de Brumadinho"); earthquakeMarker.addTo(map);

Quando clicamos no marcador, o pop-up é exibido.

Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.5: Nuevo geoproceso, Rejilla por densidad de puntos

OSGeo Planet - Tue, 2019-02-26 17:01

Hablamos en el post anterior sobre una serie de geoprocesos relacionados con la criminología realizados junto a la Universidad Jaume I (UJI). Puedes ver el vídeo de la ponencia aquí. Estos geoprocesos pueden utilizarse en diferentes campos, no ligado en exclusiva a la criminología.

Le toca el turno al geoproceso de Rejilla por densidad de puntos. El objetivo principal de este geoproceso es el de realizar de una forma rápida y eficiente un conteo de puntos contenidos en una rejilla que también crea el geoproceso. En el caso planteado, delitos, pero se puede aplicar a muchas otra cosas. Esto permite visualizar de forma rápida cómo se distribuyen los eventos cuando  hay una capa con una gran acumulación de ellos en unas mismas zonas.

Delitos en Nueva York (150.000 entidades)

Los parámetros de entrada son una capa de puntos y una expresión (opcional) que serviría de filtrado para ejecutar el geoproceso. Por ejemplo, podríamos aplicar un filtro por tipología de delito.

Las opciones hacen referencia a:

  • Distancia de rejilla: A la distancia del lado de cada cuadrado o hexágono. En relación con las medidas de la Vista.
  • Tipo de rejilla: Puede  ser cuadricular o hexagonal. Y en hexagonal dos tipos: Vertical o horizontal.
  • Añadir rejillas vacías: No añadir rejilla en las zonas donde no hay elementos puntuales, o sea, donde su conteo es cero.

Es importante seleccionar correctamente en la pestaña de Región de análisis cual va a ser la extensión de la rejilla.

El resultado del geoproceso sobre la capa de la imagen inicial devuelve una rejilla con una tabla de atributos a la que podemos aplicarle una leyenda por intervalo de valores.

Aquí un resultado sobre toda la capa de delitos con otra distancia más pequeña y de tipo rejilla vertical.

Aquí aplicando un filtro sobre un distrito.

En la tabla de atributos se puede ver el conteo total de puntos dentro de cada rejilla, el total de puntos implicados en el cálculo inicial antes del filtrado, y el porcentaje de esos puntos respecto al total.

Además, hemos aprovechado durante el desarrollo de este geoproceso en hacer mejoras y depurar gvSIG para soportar capas con mayor número de registros. Una de estas pruebas para este geoproceso se realizo con una capa con más de 6.7millones de registros y más de 10 campos.

Ya puedes descargarte y probar el nuevo geoproceso de Rejilla por densidad de puntos en la nueva candidata a versión final . Puedes descargarlos de Herramientas -> Administrador de complementos y buscar por el geoproceso “Geoprocess: Point density grid”. Una vez instalado, aparecerá junto a los geoprocesos dentro del apartado de “Scripting – Análisis de datos – Rejilla por densidad de puntos”.

Si encuentras cualquier fallo o recomendación te animamos a escribirnos a las Listas de correo de gvSIG.

Categories: OSGeo Planet

Fernando Quadro: Introdução ao Leaflet – Parte 1

OSGeo Planet - Tue, 2019-02-26 10:30

Prezados leitores,

Os próximos 13 posts, serão dedicados a uma introdução ao framework Leaflet. Estarei começando do zero e cada postagem no blog será adicionado um pouco mais ao projeto. As postagens provavelmente não serão publicadas todos os dias.

Parte 1 – Configurando um Mapa Simples

Para começar, vamos criar um modelo, copiado diretamente dos documentos do Leaflet:

<!DOCTYPE html> <head>   <link rel="stylesheet" href="https://unpkg.com/leaflet@1.4.0/dist/leaflet.css"   crossorigin=""/>     <script src="https://unpkg.com/leaflet@1.4.0/dist/leaflet.js"   crossorigin=""></script>   <style>       #mapDIV{           height: 700px;           width: 700px;           border: solid 1px black;       } </style> </head> <body>     <div id='mapDIV'>i</div> </body> </html>

Também criamos um div para manter o id do mapa (mapDIV) na seção head, e adicionamos um estilo para definir o tamanho do mapa quando exibido no navegador. Este HTML irá “carregar” o Leaflet, mas você não verá nada. Precisamos adicionar um script que crie o mapa.

<script>       var map = L.map(document.getElementById('mapDIV'), {       center: [-20.1438, -44.1301],       zoom: 15       });       var basemap = L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {           });           basemap.addTo(map); </script>

Este pequeno script, colocado depois da mapDiv, faz o seguinte:

  • Adiciona um objeto de mapa
  • Centraliza em uma latitude/longitude
  • Define o nível de zoom
  • Adiciona o mapa base do OpenStreetMap

Se nós carregarmos o arquivo em nosso navegador, nós veremos isto:

Este mapa é centrado na localização do desastre de Brumadinho que ocorreu no dia 25 de janeiro de 2019. Vamos movê-lo em um post posterior.

Esse é o nosso primeiro post. A atribuição é importante e vamos adicioná-la ao mapa, junto com outras novidades no próximo post.

Aqui está o arquivo HTML completo:

<!DOCTYPE html> <head>   <link rel="stylesheet" href="https://unpkg.com/leaflet@1.4.0/dist/leaflet.css"   crossorigin=""/>     <script src="https://unpkg.com/leaflet@1.4.0/dist/leaflet.js"   crossorigin=""></script>   <style>       #mapDIV{           height: 700px;           width: 700px;           border: solid 1px black;       } </style> </head> <body>     <div id='mapDIV'>i</div> <script>       var map = L.map(document.getElementById('mapDIV'), {       center: [-20.1438, -44.1301],       zoom: 15       });       var basemap = L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {           });           basemap.addTo(map); </script> </body> </html>
Categories: OSGeo Planet

Fernando Quadro: Usando tiles do OpenStreetMap para Machine Learning

OSGeo Planet - Mon, 2019-02-25 16:05

O OpenStreetMap é uma fonte de dados incrível. O esforço coletivo de milhares de voluntários criou um rico conjunto de informações que abrange quase todos os locais do planeta.

Há um grande número de problemas em que as informações do mapa podem ser úteis:

  • Urbanismo
  • Infraestrutura de transporte público
  • Campanhas de marketing
  • Pontos críticos de crimes e tráfego

No entanto, para cada problema individual, há uma quantidade significativa de pensamento que precisa ser decidida sobre como transformar os dados usados ​​para criar o mapa em recursos úteis para a tarefa em questão. Para cada tarefa, é preciso entender os recursos disponíveis e escrever código para extrair esses recursos do banco de dados do OpenStreetMap.

Uma alternativa a essa abordagem manual de engenharia de recursos seria usar redes convolucionais nos tiles renderizados do mapa.

1. Como as redes convolucionais poderiam ser usadas?

Se houver um relacionamento forte o suficiente entre as imagens do mapa (tiles) e a variável de resposta, uma rede convolucional poderá aprender os componentes visuais do mapa que são úteis para cada problema. Os designers do OpenStreetMap fizeram um ótimo trabalho ao garantir que a renderização do mapa expusesse tanta informação quanto o sistema visual pudesse compreender. E as redes de convolução provaram ser muito capazes de imitar o desempenho do sistema visual – por isso, é viável uma rede convolucional poder aprender quais recursos extrair das imagens – algo que seria demorado programar para cada domínio de problema específico.

2. Testando a hipótese

Para testar se redes convolucionais podem aprender recursos úteis do mapa, foi escolhido um problema simples: Estimar a população de um determinado bloco do mapa. O censo dos EUA fornece dados sobre o número da população no nível do setor censitário, e é possível usar a informação de população dos setores para aproximar com as informações de população do mapa.

As etapas envolvidas:

  • Faça o download dos dados da população no nível do setor censitário do Census Bureau.
  • Para um determinado nível de zoom, identifique os tiles do OpenStreetMap que se cruzam com 1 ou mais setores censitários.
  • Faça o download dos tiles de uma instância local do OpenMapTiles.
  • Soma a população dos tratos dentro de cada tile, e adicione as populações fracionárias para trechos que se cruzam com o tile.

Visualizando os setores censitários que se sobrepõem aos 3 tiles de exemplo

Isso nos dá:

  • Entrada X : uma representação de bitmap (RGB) do tile do OpenStreetMap
  • Meta Y : uma população estimada do tile

Para reiterar, as únicas informações usadas pela rede para prever a população são os valores RGB dos tiles do OpenStreetMap.

Para este experimento, gerou um conjunto de dados da Califórnia, mas o mesmo processo pode ser feito para todos os estados dos EUA.

3. Resumo

Desempenho da rede ao prever a população de um determinado ladrilho

No exemplo de estimativa da população, há informações suficientes nos tiles do OpenStreetMap para superar significativamente um estimador ingênuo de população.
Para problemas com um sinal forte o suficiente, os tiles do OpenStreetMap podem ser usados ​​como uma fonte de dados sem a necessidade de engenharia manual de recursos.

Este post foi traduzido e adaptado do original escrito por Robert Kyle do site Towards Data Science.

Categories: OSGeo Planet

CARTO Blog: Introducing the new CARTO dashboard

OSGeo Planet - Mon, 2019-02-25 10:00
The dashboard is one of the core pieces of CARTO. It’s what users see right after they login to their CARTO accounts. From here, users can manage their datasets, create map...
Categories: OSGeo Planet

gvSIG Team: Towards gvSIG 2.5: Fields importer

OSGeo Planet - Mon, 2019-02-25 08:18

We continue with a new feature of the next gvSIG Desktop version. In this post we will show you how the new tool to import fields works. Thanks to it you can import the fields that you want from one table to another, through a field that allows to establish a relationship.

This tool allows you to optimize this type of tasks, which otherwise would have to be done by establishing a series of steps: creating a link, exporting to new layer, editing the table if we want to make changes in the configuration of fields … With the fields importer all these actions are reduced to the use of a single tool, where you can define the fields to be imported and even define how to name them once imported. This is another extremely useful novelty.

Here you have a video where how to install the plugin and how it works is shown:

Categories: OSGeo Planet

gvSIG Team: Camino a gvSIG 2.5: Importador de campos

OSGeo Planet - Sun, 2019-02-24 08:04

Seguimos con las numerosas novedades de la próxima versión de gvSIG Desktop. En este post vamos a mostrar como funciona la nueva herramienta de importar campos. Gracias a ella podemos importar los campos que deseemos de una tabla a otra, mediante un campo que permita establecer una relación.

Esta herramienta permite optimizar este tipo de tareas, que de otro modo se tendrían que hacer estableciendo una serie de pasos: crear un enlace, exportar a nueva capa, editar la tabla si queremos realizar cambios en la configuración de campos…

Con el importador de campos todas estas acciones se reducen al uso de una única herramienta, donde podemos definir los campos a importar e incluso definir el nombre con el que queremos que aparezcan una vez importados. Otra novedad extremadamente útil.

Os dejamos un vídeo que muestra cómo instalar el plugin y su funcionamiento:

Categories: OSGeo Planet
Syndicate content