Planet Georezo » Planet OSGeo

Un Planet est un site Web dynamique qui agrÃ¨ge le plus souvent sur une seule page, le contenu de notes, d'articles ou de billets publiÃ©s sur des blogs ou sites Web afin d'accentuer leur visibilitÃ© et de faire ressortir des contenus pertinents aux multiples formats (texte, audio, vidÃ©o, Podcast). C'est un agrÃ©gateur de flux RSS. Il s'apparente Ã un portail web.
Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !

Feeds

5589 items (0 unread) in 75 feeds

Dans la presse

Du côté des éditeurs

Toile géomatique francophone

Géomatique anglophone

Blogs GeoRezo.net

Autres planets

Planet OSGeo

Abonnez vous à cette page (RSS) !

Planet OSGeo

Skip to page: 1 2 3 ... 14

02 August 2021

2:00

Ecodiv.earth: Compute surface area per region

sur Planet OSGeo

The question

Suppose I have a categorical raster layer. Now I want to create a second raster layer with values that represent the surface area of the categories in the first layer. Below, I test four different methods to see which of these is the fastest.

The first three methods result in a raster layer with values that represent the surface area of the categories (A in figure 1). The fourth option calculates the area for each group of cell that form physically discrete areas (B in figure 1). You can achieve the same with the first three options by first recategorizing the contiguous areas into unique categories. You can do that with the function r.clump.

The raster layer in the left upper corner shows the distribution of two categories, 1 and 2. In the first three options discussed in this post, the surface area is computed per category (A). The fourth option calculates the surface area per physically discrete areas with the same category (B).

Figure 1: The raster layer in the left upper corner shows the distribution of two categories, 1 and 2. In the first three options discussed in this post, the surface area is computed per category (A). The fourth option calculates the surface area per physically discrete areas with the same category (B).

I provide the Python code, but of course, you can run the same from the command line or using the menu. For the examples, I use the landcalss96 raster layer from the North Carolina dataset. You can download the dataset here.

r.area & r.mapcalc

We can use the r.area addon to create a raster layer with values representing the size of the categories in the category_map in terms of number of cells. Next, we multiply this with the surface area per raster cell using r.mapcalc.

# Import the libraries
import grass.script as gs
import datetime

# Set the region
gs.run_command("g.region", raster="landclass96")

# Compute the area per category (repeat 25 times)
begin_time = datetime.datetime.now()

for i in range(1,25):
    # Area per categories (number of cells)
    output1 = "test0_{}a".format(i)
    output2 = "test0_{}b".format(i)
    gs.run_command("r.area", input="landclass96", output=output1)

    # Convert number of cells to m2
    expr = expression="{} = {} * area()".format(output2, output1)
    gs.run_command("r.mapcalc", expression=expr)

# Print the runtime in seconds
runtime01 = (datetime.datetime.now() - begin_time).total_seconds()
print("The runtime is {} seconds".format(runtime01))

# Clean up
gs.run_command("g.remove", flags="f", type="raster", pattern="test0_*",
               quiet=True)

The runtime is 5.03994 seconds

r.stats and r.recode

We can use the r.stats function to compute for each raster category the area. Based on these values, we can than create a recode string and use this as input in the r.recode function to create the map with the surface area per category.

import grass.script as gs
import datetime

def surfaceArea(input, output):
  """ Compute a raster layer with for each raster cell the surface area of the
  category it belong to
  """
  # Compute the area per category
  p = gs.read_command("r.stats", flags="an", input=input, 
                      separator=";").split("\n")
  p = [i.replace('\r', '') for i in p]
  p[:] = [x for x in p if x]
  p = [i.split(";") for i in p]
  
  # Create the recode rules
  a = []
  for i in range(0, len(p)):
      sarea = float(p[i][1])
      a.append("{0}:{0}:{1}".format(p[i][0], sarea))
  rules = "\n".join(a)
  
  # Recod input raster map based on recode rules.
  gs.write_command("r.recode", input=input, output=output, 
                   rules="-", stdin=rules)

# Compute the area per category (repeat 25 times)
begin_time = datetime.datetime.now()

for i in range(1,25):
    # Area per categories (number of cells)
    output1 = "test0_{}".format(i)
    surfaceArea("landclass96", output1)

# Print the runtime in seconds
runtime01 = (datetime.datetime.now() - begin_time).total_seconds()
print("The runtime is {} seconds".format(runtime01))

# Clean up
gs.run_command("g.remove", flags="f", type="raster", pattern="test0_*",
               quiet=True)

The runtime is 4.110168 seconds

It runs faster than the previous options. I am not sure if the number of categories will make a difference though.

r.mapcalc & r.stats.zonal

The third options uses the r.mapcalc and r.stats.zonal functions. First we compute the area of each raster cell. Next, we sum all these values per category.

# Import the libraries
import grass.script as gs
import datetime

# Set the region
gs.run_command("g.region", raster="landclass96")

# Compute the area per category (repeat 25 times)
begin_time = datetime.datetime.now()

for i in range(1,25):
    # Area per categories (number of cells)
    output1 = "test0_{}a".format(i)
    output2 = "test0_{}b".format(i)
    gs.run_command("r.mapcalc", expression = "{} = area()".format(output1))
    gs.run_command("r.stats.zonal", base="landclass96", cover=output1,
                   method="sum", output=output2)

# Print the runtime in seconds
runtime01 = (datetime.datetime.now() - begin_time).total_seconds()
print("The runtime is {} seconds".format(runtime01))

# Clean up
gs.run_command("g.remove", flags="f", type="raster", pattern="test0_*",
               quiet=True)

The runtime is 5.289945 seconds

Slightly slower than the first option. The difference is small, so I ran both options a number of times. Results showed that this option is consistently slower than the first option.

r.to.vect & v.to.db

The fourth option is different, in that the raster layer is converted to a vector layer first, using r.to.vect. Then, the v.to.db function is used to calculate the area per polygon. These values will be used as source for the raster values when converting the vector layer back to a raster layer using the v.to.rast function. Note that this means that areas are calculated for the continuous cluster of cells with the same categories (B in figure 1).

# Import the libraries
import grass.script as gs
import datetime

# Set the region
gs.run_command("g.region", raster="landclass96")

# Compute the area per category (repeat 25 times)
begin_time = datetime.datetime.now()

for i in range(1,25):
    # Area per categories (number of cells)
    output1 = "test0_{}a".format(i)
    output2 = "test0_{}b".format(i)
    gs.run_command("r.to.vect", input="landclass96", output=output1,
                   type="area")
    gs.run_command("v.to.db", map=output1, option="area", columns="area",
                   units="meters")
    gs.run_command("v.to.rast", input=output1, output=output2, 
                   use="attr", attribute_column="area", memory=2000)

# Print the runtime in seconds
runtime01 = (datetime.datetime.now() - begin_time).total_seconds()
print("The runtime is {} seconds".format(runtime01))

# Clean up
gs.run_command("g.remove", flags="f", type="all", pattern="test0_*",
               quiet=True)

The runtime is 81.037101 seconds

This option is clearly much slower. However, when you need to compute multiple statistics per area, if you need to do some follow up calculations, or if you need a vector layer as output, this might still be a good option.

Summary

The combination of r.stats and r.recode is the fastest option. It requires a bit more of coding, but that’s just part of the fun, isn’t it :-). The fourth option is clearly slower, which is largely due to/from the raster to vector conversion. Currently this Google of Summer project works on the parallelization of existing modules for GRASS GIS, including the r.to.* modules. So this may improve in the near feature.

01 August 2021
22:58
From GIS to Remote Sensing: Image Conversion to Reflectance using the Semi-Automatic Classification Plugin version 7
sur Planet OSGeo

This tutorial is about the image conversion to Radiance at the Sensor’s Aperture or to Top Of Atmosphere (TOA) Reflectance. It is assumed that one has the basic knowledge of SCP and Basic Tutorials.
SCP includes several tools for preprocessing images such as Landsat, Sentinel-2, Sentinel-3. Using satellite images from various sources could require the preprocessing and radiometric correction.
Usually, remote sensing images are delivered as calibrated Digital Numbers (DN), and the conversion to radiance or reflectance can be performed through parameters that are provided with the image.
This tutorials aims to describe how to perform the conversion to TOA reflectance of remote sensing images. The calculation can be performed for all the bands at once in Band calc, knowing the required parameters.

Following the video of this tutorial.

Read more »
2:00
GRASS GIS: Installing GRASS GIS extensions currently failing on some systems
sur Planet OSGeo

Due to a long-term planned re-structuring of the addon repository, the installation of addons through g.extension is currently not working on UNIX-like systems. Installation of addons with the current stable version GRASS GIS 7.8.5 on OSGeo4W (Version 1) is not affected. All the necessary changes in g.extension have been implemented, merged and back-ported. The functionality will be back to normal very soon with the upcoming GRASS 7.8.6 and 8.0.0 releases.
29 July 2021
11:00
CARTO Blog: Extending Spatial Analytics on Snowflake with CARTO
sur Planet OSGeo

Exciting news for Snowflake users! As part of our commitment to enabling geospatial analysis natively within the cloud, today we are announcing the launch of our Spatial Ex...
28 July 2021
22:53
Stefano Costa: IOSACal 0.5, featuring IntCal20 and more
sur Planet OSGeo
After three years of slow paced development, IOSACal 0.5 is here.

As before, the preferred installation method is with pip in a virtual environment. The documentation is at [https:]]

This release brings the new IntCal20 calibration data and several improvements for different use cases, plus one important bug fix. Apart from myself, there were two contributors to this release, I’m grateful to Karl Håkansson and Wesley Weatherbee for their work.

These are the highlights from the release notes:
- the project has moved to Codeberg for source code hosting and issue tracking. The new Git repository is at [https:]] with a default branch name of main
- there is an official Code of Conduct that all contributors (including the maintainter) will need to follow, based on Contributor Covenant
- the documentation has seen some improvements, in particular in the Contributing section. Overall, making contributions easier from both expert and novice users is a major theme in this release.
- interactive use in Jupyter notebooks is made easier with CalibrationCurve that can be created in many ways (such as loading from an arbitrary file, or from a standard calibration curve called by shorthand)
- fixed a bug that made plots with AD/CE setting incorrect (contributed by Karl Håkansson)
- fixed a bug that caused a wrong plot density function for dates 80 BP to 0 BP (contributed by Karl Håkansson)
- add IntCal20 calibration data (contributed by Wesley Weatherbee)
On the technical side:
- the command line interface is now based on the Click library
- most code is now covered by tests, based on pytest
- Python 3.6 or above required
- requires Numpy 1.18 and Matplotlib 3.0
I don’t have big plans for the next release. I would like to add more tests, modernize the code and make it easier to adapt / tinker with. The only major achievement I’m looking forward to is to submit an article about IOSACal to the Journal of Open Source Software.
17:59
Free and Open Source GIS Ramblings: Great label callout lines
sur Planet OSGeo

One of the new features in QGIS 3.20 is the option to trim the start and end of simple line symbols. This allows for the line rendering to trim off the first and last sections of a line at a user configured distance, as shown in the visual changelog entry.

This new feature makes it much easier to create decorative label callout (or leader) lines. If you know QGIS Map Design 2, the following map may look familiar – however – the following leader lines are even more intricate, making use of the new trimming capabilities:

To demonstrate some of the possibilities, I’ve created a set of four black and four white leader line styles:

You can download these symbols from the QGIS style sharing platform: [https:]] to use them in your projects. Have fun mapping!
11:00
CARTO Blog: CKDelta’s international human mobility data now available in CARTO
sur Planet OSGeo

Over the past year the importance of human mobility data has increased significantly, not only as a means to analyze how to mitigate the spread of Covid; but more recently ...
27 July 2021
12:00
CARTO Blog: Making Human Mobility Models Fair, Inclusive, & Private
sur Planet OSGeo

Late in 2020, we announced the creation of CARTO’s Scientific Committee to double down on our efforts to make the work of Spatial Data Scientists more productive and to hel...
11:00
CARTO Blog: Announcing CARTO’s Return to In-Person Events
sur Planet OSGeo

After more than a year of virtual events, we are very pleased to announce that we will be returning to in-person and hybrid events over the coming weeks and months. We hope...
21 July 2021
8:24
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.9.0
sur Planet OSGeo

This post is about a new update of the Semi-Automatic Classification Plugin v. 7.9.0.
Following the changelog:-preprocessing of Landsat and Sentinel-2 bands are now converted to UInt16 with scale 0.0001 to reduce file size-added Landsat 8 band 1 processing-fixed clip multiple rasters by coordinates-fixed Classification report for degree unit

This update changes the data format of processed Landsat and Sentinel-2 bands, which are are now converted to UInt16 with scale 0.0001 to reduce file size. Basically, this allows to virtually have a Float16 band (instead of Float32) which reduces the files size. The processed bands are now almost half the file size of the bands processed with previous version of the Semi-Automatic Classification Plugin, without any significant loss of information.
Also, the Landsat 8 band 1 has been added to the preprocessing workflow and is now converted to reflectance.Other minor fixes were implemented, and the Semi-Automatic Classification Plugin v. 7.9.0 is compatible with the latest version of QGIS.
For any comment or question, join the Facebook group or GitHub discussions about the Semi-Automatic Classification Plugin.
20 July 2021
7:00
Lutra consulting: MDAL gets adopted as an OSGeo Community Project
sur Planet OSGeo

Mesh Data Abstraction Library MDAL proudly joins the OSGeo Community program

We would like to share the excellent news that the OSGeo incubation committee kindly accepted the MDAL project into its Community Program. MDAL is an MIT Licensed C++ Library which integrates into your QGIS installation and is backed by the Lutra Consulting team and the wider community.

MDAL is a low-level library which allows reading unstructured mesh data from various formats. If you’ve never seen a QGIS Mesh Layer, then check out my presentation at FOSS4G 2019.

We kicked-off the MDAL project at the time we were migrating the Crayfish plugin to QGIS version 3. The Crayfish project started in late 2012, has more than 120,000 downloads and opened the way engineers and data scientists to visualize their hydro and meteo-data in QGIS.

QGIS uses MDAL to visualize, analyze and even modify data on unstructured meshes which are used by many hydraulic / numercial modelling solvers. In addition to providing abstraction for complex mesh data structures, MDAL also allows vectoral (e.g. wind speed) and temporal data to be visualised effectively and easily in QGIS.

The MDAL project (and therefore the wider community) has benefitted from generous sponsors such as TUFLOW, 3Di, Hydrotech, DHI, FLO-2D, Artelia, Federal Ministry of Austria for Agriculture, Regions and Tourism and many others. If you’d like to see your formats or workflows supported by QGIS then please consider becoming a sponsor or contact Peter at peter.petrik@lutraconsulting.co.uk

Right now we’re working on some new mesh frame editing tools for QGIS 3.22 (due for release in autumn 2021) and of course support for additional result file formats.
You may also like... Input, a field data collection app based on QGIS. Input makes field work easy with its simple interface and cloud-based sync. Available on Android and iOS.
6:52
GeoTools Team: GeoTools 25.2 Released
sur Planet OSGeo

The GeoTools team is pleased to announce the release GeoTools 25.2: geotools-25.2-bin.zip geotools-25.2-doc.zip geotools-25.2-userguide.zip geotools-25.2-project.zip GeoTools 25.2 is published to repo.osgeo.org for direct build integration. This release is made in conjunction with GeoServer 2.19.2.Repackaged DownloadsThe above GeoTools downloads have been repackaged to include html readme and
19 July 2021
13:00
Fernando Quadro: Como importar arquivos raster para o PostGIS usando o QGIS
sur Planet OSGeo

No post de hoje irei mostrar como é possível adicionar os seus arquivos raster para o banco de dados PostgreSQL/PostGIS de uma forma rápida e prática utilizando o QGIS.

Para fazer isso, você primeiramente deve instalar o plugin “PostGIS Raster Import“, conforme demonstra a imagem abaixo:

Depois de instalado você irá encontrá-lo no menu Banco de dados (Database) do seu QGIS, veja:

Agora basta você clicar na opção “PostGIS Raster Import”, conforme demostra a tela acima, para que você possa então realizar a importação da sua imagem raster.

É importante ressaltar que antes de abrir a tela acima, você tem que ter realizado os seguintes passos:

1) Configurar a conexão do QGIS com o PostGIS
2) Adicionar a imagem raster no seu Layers List

Feito isso, é só você selecionar a imagem e o banco/schema onde deseja salvá-la e apetar o botão “Upload“.

E aí, não é fácil? Agora basta você entrar no seu banco de dados e ver a tabela referente a sua imagem raster.

Se você quer saber como importar o seu arquivo raster através da linha de comando, clique aqui, e veja o vídeo no YouTube.
18 July 2021
2:00
GeoServer Team: GeoServer 2.19.2 Released
sur Planet OSGeo
We are happy to announce GeoServer 2.19.2 release is available for download (zip and war) along with docs and extensions.

This GeoServer 2.19.2 release was produced in conjunction with GeoTools 25.2, this is a stable release recommended for production systems.

Thanks to everyone who contributed, and to Jody Garnett (GeoCat) for making this release.
Improvements and Fixes
New features are included in this release:
- GEOS-5239 Implement (Krovak) North Orientated projection
Notable improvements:
- GEOS-10149 Improve Catalog Parametrization documentation
- GEOS-10098 Upgrade version of wicket and jquery used by GeoServer
- GEOS-10064 Improving WPS Raster Download - download time
- GEOS-10009 Improve logging on lock providers
Fixes included in this release:
- GEOS-10114 Geofence server UI, error when changing the layerType from layer details tab.
- GEOS-10113 Geofence REST NPE when requesting rule with void Layer details
- GEOS-10037 WMTS Multidimensional extension make layers encoding fail on TileLayers not being GeoServerTileLayers
- GEOS-9804 The default style of the layergroup is propagated in the layer as default style
For details check the 2.19.2 release notes.
About GeoServer 2.19
Additional information on GeoServer 2.19 series:
Release notes ( 2.19.2| 2.19.1 | 2.19.0 | 2.19-RC )
17 July 2021

1:14

Martin Davis: JTS IsValidOp Built Back Better

sur Planet OSGeo

In a previous post I described how the JTS Topology Suite operation IsSimpleOp has been completely rewritten to reduce code dependencies, improve performance, and provide a simpler, more understandable implementation. The post points out that the IsValidOp implementation would benefit from the same treatment. This work has now been carried out, with similar benefits achieved.

The original IsValidOp code used the GeometryGraph framework to represent the topology of geometries. This code reuse reduced development effort, but it carried some serious drawbacks:

The GeometryGraph structure was used for many JTS operations, including overlay, buffer, and spatial predicate evaluation. This made the code complex, hard to understand, and difficult to maintain and enhance
The GeometryGraph structure computes the full topology graph of the input geometry, in order to support constructive operations such as overlay and buffer. This makes it slower and more subject to robustness problems. Non-constructive operations such as IsValidOp and IsSimpleOp can compute topology "on-the-fly", which allows short-circuiting processing as soon as an invalidity is found.

The new IsValidOp implementation is more self-contained, relying only on the noding framework and some basic spatial predicates. Using the MCIndexNoder allows short-circuited detection of some kinds of invalidity, which improves performance. And it will be easy to switch to a different noding strategy should a superior one arise.However, dropping GeometryGraph means that the topology information required to confirm validity needs to be computed some other way. The goal is to compute just enough topological structure to evaluate validity, and do that efficiently on an as-needed basis. This required some deep thinking about validity to pare the topology information required down to a minimum. This was assisted by the extensive set of unit tests for IsValidOp, which ensured that all possible situations were handled by the new logic (although there was an untested situation which uncovered a bug late in development.) The resulting algorithm uses some elegant logic and data structures, which are explained in detail below. OGC ValidityJTS implements the OGC Simple Features geometry model. To understand the validity algorithm, it helps to review the rules of geometry validity in the OGC specification:For non-polygonal geometry types, the validity rules are simple;

Coordinates must contain valid numbers
LineStrings must not be zero-length
LinearRings must be simple (have no self-intersections)

For polygonal geometry, on the other hand, the validity rules are quite stringent (sometimes considered too much so!). The rules are:

Rings must be simple (have no self-intersections)
Rings must not cross, and can touch only at discrete points
Holes must lie inside their shell
Holes must not lie inside another hole of their polygon
The interiors of polygons must be connected
In a MultiPolygon, the element interiors must not intersect (so polygons cannot overlap)
In a MultiPolygon, the element boundaries may intersect only at a finite number of points

Validity Algorithm for Polygonal GeometryThe new IsValidOp uses an entirely new algorithm to validate polygonal geometry. It has the following improvements:

It supports short-circuiting when an invalid situation is found, to improve performance
Spatial indexing is used in more places
The code is simpler and more modular. This makes it easier to understand, and easier to adapt to new requirements (e.g. such as the ability to validate self-touching rings described below)

The algorithm consists of a sequence of checks for different kinds of invalid situations. The order of the checks is important, since the logic for some checks depends on previous checks passing.

1. Check Ring Intersections

The first check determines if the rings in the geometry have any invalid intersections. This includes the cases of a ring crossing itself or another ring, a ring intersecting itself or another ring in a line segment (a collinear intersection), and a ring self-touching (which is invalid in the OGC polygon model). This check can use the robust and performant machinery in the JTS noding package. If an invalid intersection is found, the algorithm can return that result immediately.

Kinds of invalid intersections: (i) a self-touch; (ii) collinear; (iii) segment crossing; (iv) vertex crossing

This check is an essential precursor to all the remaining checks. If a geometry has no invalid intersections this confirms that its rings do not self-cross or partially overlap. This means that the results of orientation and point-in-polygon computations are reliable. It also indicates that the rings are properly nested (although it remains to be determined if the nesting of shells and holes is valid).

Intersection search is the most computationally expensive phase of the algorithm. Because of this, information about the locations where rings touch is saved for use in the final phase of checking connected interiors.

2. Check Shell and Hole nestingIf no invalid intersections are found, then the rings are properly nested. Now it is necessary to verify that shells and holes are correctly positioned relative to each other:

A hole must lie inside its shell
A hole may not lie inside another hole.
In MultiPolygons, a shell may not lie inside another shell, unless the inner shell lies in a hole of the outer one.

Ring position can often be tested using a simple Point-In-Polygon test. But it can happen that the ring point tested lies on the boundary of the other ring. In fact, it is possible that all points of a ring lie on another ring. In this case the Point-In-Polygon test is not sufficient to provide information about the relative position of the rings. Instead, the topology of the incident segments at the intersection is used to determine the relative position. Since the rings are known to not cross, it is sufficient to test whether a single segment of one ring lies in the interior or exterior of the other ring.

MultiPolygon with an element where all vertices lie on the boundaryChecking nesting of holes and shells requires comparing all interacting pairs of rings. A simple looping algorithm has quadratic complexity, which is too slow for large geometries. Instead, spatial indexes (using the STRtree) are used to make this process performant. 3. Check Connected Interior

The final check is that the interior of each polygon is connected. In a polygon with no self-touching rings, there are two ways that interior disconnection can happen:

a chain of one or more touching holes touches the shell at both ends, thus splitting the polygon in two
a chain of of two or more touching holes forms a loop, thus enclosing a portion of the polygon interior

To check that these conditions do not occur, the only information needed is the set of locations where two rings touch. These induce the structure of an undirected graph, with the rings being the graph vertices, and the touches forming the edges. The situations above correspond to the touch graph containing a cycle (the splitting situation is a cycle because the shell ring is also a graph vertex). (Equivalently, the touch graph of a valid polygon is a tree, or more accurately a forest, since there may be sets of holes forming disconnected subgraphs.) So a polygon can be verified to have a connected interior by checking that its touch graph has no cycles. This is done using a simple graph traversal, detecting vertices (rings) which are visited twice.

Situations causing a disconnected interior: (i) a chain of holes; (ii) a cycle of holesIf no invalid situations are discovered during the above checks, the polygonal geometry is valid according to the OGC rules.

Validity with Self-touching RingsSome spatial systems allow a polygon model in which "inverted shells" are valid. These are polygon shells which contain a self-touch in a way that encloses some exterior area. They also allow "exverted holes", which contain self-touches that disconnect the hole into two or more lobes. A key point is that they do not allow "exverted shells" or "inverted holes"; self-touches may disconnect the polygon exterior, but not the interior. Visually this looks like:

Left: Inverted shell and exverted hole (valid)Right: Exverted shell and inverted hole (invalid)
This kind of topology is invalid under the OGC polygon model, which prohibits all ring self-intersections. However, the more lenient model still provides unambiguous topology, and most spatial algorithms can handle geometry of this form perfectly well. So there is a school of thought that considers the OGC model to be overly restrictive.To support these systems JTS provides the setSelfTouchingRingFormingHoleValid option for IsValidOp to allow this topology model to be validated. Re-implementing this functionality in the new codebase initially presented a dilemma. It appeared that building the touch graph to check connectivity required computing the geometry of the additional rings formed by the inversions and exversions. This needed a significant amount of additional code and data structures, eliminating the simplicity of the graph-based approach. However, it turns out that the solution is much simpler. It relies on the fact that valid self-touches can only disconnect the exterior, not the interior. This means that self-touches of inverted shells and exverted holes can be validated by the local topology at the self-intersection node. This condition can be tested by the same logic already used to test for nested touching shells. Even better, if the self-touches are valid, then the touch-graph algorithm to check connectivity still works. (This is the same phenomenon that allows most spatial algorithms to work correctly on the inverted/exverted ring model.) Performance

As expected, the new codebase provides better performance, due to simpler code and the ability to short-circuit when an invalidity is found. Here's some performance comparisons for various datasets:

Data	Size	New (ms)	Old (ms)	Improvement
world	244 Polygons, 366K vertices	340	1250	3.7 x
invalid-polys	640 Polygons, 455K vertices	126	334	2.6 x
valid-polys	640 Polygons, 455K vertices	244	487	2 x
australia	1 MultiPolygon, 1,222K vertices	1321	69026	52 x

world is the standard dataset of world country outlines
invalid-polys is a dataset of all invalid polygons. valid-polys is the same dataset processed by GeometryFixer. The timings show the effect of short-circuiting invalidity to improve performance.
australia is a geometry of the Australian coastline and near-shore islands, with 6,697 polygon elements. The dramatic difference in performance reflects the addition of a spatial index for checking nested shells.

Australia and 6,696 islands
Next Steps

The improved IsValidOp will appear in JTS version 1.19. It has already been ported to GEOS, providing similar performance improvements. And since GEOS backs the PostGIS ST_IsValid function, that will become faster as well.

There is one remaining use of GeometryGraph in JTS for a non-constructive operation: the RelateOp class, used to compute all topological spatial predicates. Converting it should provide the same benefits of simpler code and improved performance. It should also improve robustness, and allow more lenient handling of invalid inputs. Watch this space!

16 July 2021
11:00
CARTO Blog: How to Build a Tree Equity Index & Dashboard using BigQuery
sur Planet OSGeo

Like many people who love trees and work in the geospatial field, I was fascinated (and disheartened) by a recent article I read in the New York Times called Since When Hav...
3:52
Tyler Mitchell: New to “geospatial”?
sur Planet OSGeo

This blog post I wrote for Locate Press helps set the stage for those new to the scene of mapping, geography, spatial data, and application development.

The post New to “geospatial”? appeared first on spatialguru.com.
13 July 2021
21:00
MapProxy: New MapProxy 1.13.1 release
sur Planet OSGeo
We are pleased to announce the release of MapProxy 1.13.1.

The latest release is available at: [https:]]

To upgrade within your virtualenv:
```
$ pip install --upgrade --no-deps MapProxy
```
Updated documentation is available at: [https:]]
Improvements
Support cookie management for HTTP sources.
Fixes and changes
Security fix for local file disclosure (#526).
11:00
CARTO Blog: Simplified tileset creation for streamlined app development
sur Planet OSGeo

The demands on Spatial Data Scientists and Developers to produce ever more complex data visualizations and geospatial apps within shorter timeframes are constantly increasi...
12 July 2021
15:42
Fernando Quadro: Curso Online de GeoServer em Agosto
sur Planet OSGeo
Caros leitores,

Gostaria de informá-los que estão abertas as inscrições para mais uma turma do Curso Online de GeoServer que estarei ministrando pela GEOCURSOS. O objetivo do curso é que você aprenda a configurar e compartilhar dados geográficos na internet com o GeoServer. Veja abaixo a nova ementa:
- Introdução aos padrões OGC
- Instalação e configuraç&ao
- Publicação de dados vetoriais
- Publicação de dados PostGIS
- Formatos de saída
- Instalação de Plugins
- Como realizar upgrade de versão
- Cache
- Estilos utilizando SLD
- Substituição de variáveis no SLD
- Utilização da API Rest
- Criação de camadas com SQL View
- Segurança
- Boas práticas
- Preparação do GeoServer para ambiente de produção
- Gerar HeapMap com o padrão WPS
- Como utilizar o plugin Importer
- Aplicação prática com OpenLayers
O curso ocorrerá entre os dias 02 e 12 de agosto das 19:30 as 22:00 (horário de Brasília).

Aqueles que poderem divulgar para seus contatos, agradeço. Quem quiser saber mais informações sobre o curso, pode obtê-las nos seguintes links:
- Site do curso ( [www.geocursos.com.br] )
- Twitter ( [twitter.com] )
- Facebook ( [www.facebook.com] )
- Instagram ( [www.instagram.com] )
11:00
CARTO Blog: #SDSC21: Speak at the largest Spatial Data Science Conference
sur Planet OSGeo

The fifth edition of the Spatial Data Science Conference is fast approaching and we are very excited to be gathering Data Science, Advanced Analytics, & GIS experts fro...
09 July 2021
10:49
geomati.co: Edificios 3D a partir del catastro
sur Planet OSGeo

Estas últimas semanas tuvimos cierta repercusión en redes con una aplicación web ( [https:]] ) que muestra los edificios de toda España en 3D, y permite navegar y simbolizarlos por año de construcción y por uso:

Los edificios de toda España en 3D, simbolizados por años y usos, a partir del catastro [https:]] #GIS #mapping #geomatico #geomaticolabs
— geomatico (@geomati_co) June 2, 2021

¿Cómo la desarrollamos?

Motivación

En geomatico llevamos varios años jugando con los edificios de catastro 3D y de hecho ya teníamos algún visor con toda España. Pero recientemente se generó un poco de hype con unas visualizaciones de cartografía catastral basada en años de construcción y su autor fue Dominic Royé:

El éxito inesperado del mapa de Valencia con muchas peticiones de todos vosotros me ha llevado a ofreceros un formato pdf de Valencia, Barcelona, Madrid y Málaga. ¡Gracias a todos! pic.twitter.com/IetioLkUVj
— Dominic Royé (@dr_xeo) May 4, 2021

Gracias por la motivación Dominic!

Descarga

Catastro ofrece parte de su cartografía (parcelas, edificios y direcciones) mediante un servicio ATOM de descarga.

Para su descarga masiva se empleó la aplicación Catastro Inspire Downloader. Se trata de un desarrollo interno, que liberamos en 2019 bajo licencia GNU, y que permite descargar toda la cartografía inspire de catastro a un geopackage.

Vector Tiles

Para la conversión a MVT, hemos usado ogr2ogr.

Se generaron teselas con cobertura para toda España y con niveles de zoom del 10 al 15. El motivo de empezar en un zoom tan bajo es que queríamos poder mostrar mucha información a la vez y lograr resultados como este:
Oviedo y Gijón a zoom 10
Para poder generar teselas con tanta información hemos tenido que tener mucho cuidado, generando los zooms bajos (10-13) sólo con geometrías de la capa building, y con la capa buildingparts para zooms altos (14 y 15).

Ejemplos de una construcción para cada zoom:
Zoom 10 Zoom 13 Zoom 11 Zoom 15 Zoom 12

Mediante ogr2ogr y su capacidad de ejecutar consultas sql al usarlo, pudimos crear un mbtiles para cada nivel de zoom.

Por último usamos tile-join, que viene incluido en tippecanoe para unir los mbtiles de cada nivel de zoom en una pirámide única.

Y para publicarlo tileserver-gl.

Visor

Finalmente se desarrolló una web basada en MapboxGL y ReactJS, que es el stack que solemos usar en geomatico, con dos estilos de simbolización:
Año de construcción Usos y filtrado por año
Al poderse activar y desactivar capas, permite ver la forma y extensión de cada ciudad en una determinada época.

Además se puede simbolizar por uso por lo que se detectan ejes comerciales o polígonos industriales a simple vista. Para los nostálgicos, los colores de residencial, comercial e industrial coinciden con los de SimCity.

No dudéis en buscar vuestra localidad y viajar por la España del presente o del pasado: [https:]]

La entrada Edificios 3D a partir del catastro se publicó primero en Geomatico.
08 July 2021
11:00
CARTO Blog: The Data Appeal Company POI & Sentiment Data now available in CARTO
sur Planet OSGeo

What influences you the most when it comes to choosing where you might book a table at a restaurant? Is it simply a casual glance at the overall rating of the establishment...
06 July 2021
18:50
GeoSolutions: Free Webinar – Set up and Operate a GeoServer Cluster in K8s
sur Planet OSGeo

You must be logged into the site to view this content.
12:50
Jackie Ng: Announcing: mapguide-react-layout 0.13.3
sur Planet OSGeo
Was I lying when I said I will be taking a short break from all things open source after releasing MapGuide Open Source 4.0 Preview 3?
Technically speaking, no.
This 0.13.3 release is just a few important fixes made since the 0.13.2 release that actually landed a few months ago, but I haven't "pressed the release button" until now. The fixes are:
- A fix for the initialElementVisibility mount option not working for the Aqua template
- A very important fix for inconsistent layer/group state if refreshing the legend after doing some server-side layer/group changes
This release is browser bundle (viewer.zip) only. There is no npm module release for this.
Now back to my self-imposed break.
Download
11:00
CARTO Blog: Z Score Visualization: How to Identify Hotspots with BigQuery
sur Planet OSGeo

Most Data Scientists and Analysts understand that visualizing datasets can be a crucial way for users to engage with data. Knowing where median household income is across a...
05 July 2021
15:38
GeoSolutions: GeoDataLab joins the network of GeoSolutions partners
sur Planet OSGeo

You must be logged into the site to view this content.
02 July 2021
2:00
PostGIS Development: PostGIS 3.1.3
sur Planet OSGeo
The PostGIS Team is pleased to release PostGIS 3.1.3! Best Served with PostgreSQL 14 beta2.

This release is a bug fix release, addressing issues found in the previous 3.1 release.
- #4929, Fix missing error from GetRingEdges when invoked with unexistent topology or edge (Sandro Santilli)
- #4927, Fix PostgreSQL 14 compile FuncnameGetCandidates changes needed to compile against PostgreSQL 14 beta2 or higher (Regina Obe, Julien Rouhaud)
Continue Reading by clicking title hyperlink ..
01 July 2021
11:00
CARTO Blog: Announcing #SDSC21: Telecoms & Utilities Summit
sur Planet OSGeo

Following the success of the two industry-specific #SDSC21 events, the Spatial Data Science in Financial Services Summit & the Spatial Data Science in CPG & Retail ...
30 June 2021
8:29
gvSIG Team: Conociendo la Suite gvSIG: Geomática libre, formación gratuita y casos de éxito alrededor del mundo
sur Planet OSGeo

Ya está disponible la ponencia dedicada a presentar la Suite gvSIG, organizada por SIGGMA Red Global.
29 June 2021
16:41
gvSIG Team: Disponible la ponencia «Rompiendo las barreras ¿necesarias? para implantar con éxito Infraestructuras de Datos Espaciales»
sur Planet OSGeo

En el marco de la Red CYTED IDEAIS (Asistentes Inteligentes para las Infraestructuras de Datos Espaciales) tuvo lugar hace unos días el seminario titulado «gvSIG Online: rompiendo las barreras ¿necesarias? para implantar con éxito Infraestructuras de Datos Espaciales», estando ya disponible la grabación del mismo, para todos aquellos interesados en el tema.

Durante la ponencia se tratan diversos temas, algunos no exentos de polémica, desde la importancia de las IDE a analizar si estas han fracasado, como parece se quiere hacer ver desde ciertos ámbitos de negocio, multinacionales de software privativo de por medio.

Por supuesto, se habla,y mucho, de gvSIG Online y de cómo está solución en software libre está multiplicando la aparición de Infraestructuras de Datos Espaciales en todo tipo de ámbitos y geografías.

Si os he despertado el interés, podéis ver la ponencia completa aquí:
28 June 2021
8:50
gvSIG Team: Sistema de administración de información topográfica en la Secretaría de Obras y Servicios (SOBSE) del Gobierno de Ciudad de México
sur Planet OSGeo

Hoy os traemos otro proyecto resultante de la colaboración entre la Asociación gvSIG y la Universidad Autónoma del Estado de México, en este caso realizado con gvSIG Online. La alumna, María Fernanda Cruz Gutiérrez, ha aprovechado sus prácticas profesionales para poner en marcha un sistema de administración de información topográfica en la Secretaría de Obras y Servicios (SOBSE) del Gobierno de Ciudad de México, mediante el uso de una Infraestructura de Datos Espaciales con tecnología gvSIG Online.

El proyecto se planteó para solucionar la problemática que enfrenta la SOBSE, que de manera continua genera nueva información, debido al constante cambio de la infraestructura en la ciudad, sin contar con un registro controlado de todos los proyectos y, por tanto, no existiendo un sistema que indique la existencia y el avance de dichos proyectos.

Para este proyecto se utilizó la información del proyecto Bosque de Chapultepec, ya que actualmente, el Gobierno de la Ciudad de México lleva acabo el Plan Maestro para la mejora y rehabilitación de este emblemático espacio para los mexicanos y pulmón para el mundo.

Damos acceso al documento que explica toda la problemática y proceso seguido con gvSIG Online para la puesta en marcha de la solución, junto un enlace a un geoportal resultante del trabajo.

Documentación / tutorial

Geoportal
27 June 2021
13:18
Free and Open Source GIS Ramblings: QGIS Atlas on steroids
sur Planet OSGeo

Today’s post is a video recommendation. In the following video, Alexandre Neto demonstrates an exciting array of tips, tricks, and hacks to create an automated Atlas map series of the Azores islands.

Highlights include:

1. A legend that includes automatically updating statistics

2. A way to support different page sizes

3. A solution for small areas overshooting the map border

You’ll find the video on the QGIS Youtube channel:

This video was recorded as part of the QGIS Open Day June edition. QGIS Open Days are organized monthly on the last Friday of the month. Anyone can take part and present their work for and with QGIS. For more details, see [https:]]
25 June 2021
18:58
Oslandia: (Fr) QSoccer : QGIS, football, what else ?
sur Planet OSGeo

Enclosure: [download]

Sorry, this entry is only available in French.
11:00
CARTO Blog: How to Visualize Urban Growth with Spatial Extension for BigQuery
sur Planet OSGeo

The urban growth of metropolitan areas around the world can be affected by a number of factors. During the industrial revolution the explosion in job availability fueled mu...
24 June 2021
11:00
CARTO Blog: Delivering Geospatial Datasets on the Leading Cloud Data Platforms
sur Planet OSGeo

The CARTO Data Observatory continues to evolve, giving Developers and Spatial Data Scientists unparalleled access to thousands of curated public and premium location based ...
23 June 2021
9:58
GeoTools Team: GeoTools 24.4 released
sur Planet OSGeo

The GeoTools team is pleased to share the availability of GeoTools 24.4 :geotools-24.4-bin.zip geotools-24.4-doc.zipgeotools-24.4-userguide.zipgeotools-24.4-project.zipThis release is published to the osgeo maven repository, and is made in conjunction with GeoServer 2.18.4. This is a maintenance release and is a recommended upgrade for all users of the GeoTools library.We would like to
2:00
GeoServer Team: GeoServer 2.18.4 Released
sur Planet OSGeo
We are happy to announce GeoServer 2.18.4 release is available for download (zip and war) along with docs and extensions.

This GeoServer 2.18.4 release was produced in conjunction with GeoTools 24.4 and GeoWebCache 1.18.4. This is a maintenance release recommended for production systems.

Thanks to everyone who contributed, and to Alessandro Parma (GeoSolutions) and Andrea Aime (GeoSolutions) for making this release.
Improvements and Fixes
This release includes support for the Krovak North Orientated projection. In addition to this new features, a few notable improvements are included:
- Upgrade version of wicket and jquery used by GeoServer.
- SLDService can now limit max unique values for uniqueInterval classification vector data (to avoid generating too many rules).
- Better logging in lock management and parameters extractor
Fixes included in this release:
- GEOS-10057 Escape style editor page user input
- GEOS-10056 Rename schemaless-mongo plug-in to mongodb-schemaless
- GEOS-10055 Escape SRS demo page user input
- GEOS-10051 Fix edge cases in the elevation parser
- GEOS-10049 Schemaless-features layer with name different from the mongo collection throws exception
- GEOS-10048 Schemaless-features mongoDB layer not present in WMS capabilities
- GEOS-10031 GWC loses GridSets bounds when importing data through the Importer plugin.
- GEOS-9748 Rendering process fails if vendor option sortByGroup is used
For details check the 2.18.4 release notes.
About GeoServer 2.18
Additional information on GeoServer 2.18 series:
- State of GeoServer 2.18 (slides)
- GeoServer Orientation (slides|video)
- Release Notes ( 2.18.4 | 2.18.3 | 2.18.2 | 2.18.1 | 2.18.0 | 2.18-RC)
2:00
SourcePole: QGIS Cloud: Fixed legend in QGIS Cloud QWC2 with CSS
sur Planet OSGeo

With QGIS Cloud Pro it is possible to change the appearance and behaviour of the QGIS Cloud Web Client via CSS. You can easily manipulate the colour of frames and fonts, etc. An example that is not obvious is displaying the legend in a fixed location on the map. In this way, the legend can be made a fixed part of the map in QGIS Cloud QWC2. In the basic configuration of QGIS Cloud QWC2 the legend of a layer is not permanently displayed.
22 June 2021
9:00
3liz: QGIS Processing R 3
sur Planet OSGeo
Le plugin QGIS Processing R version 3.0
Le plugin QGIS Processing R permet de développer des scripts avec le langage R pour le module traitement de QGIS.

Le plugin QGIS Processing R a été développé suite au travail de réorganisation du code du module traitement de QGIS 3. North Road a extrait et adapté le code du module traitement de QGIS 2 pour QGIS 3.

Une nouvelle version majeure a été publiée. Cette version intègre des améliorations développées par 3Liz sur commande de l'Ifremer pour la plateforme Sextant.

Depuis la version 2.0.0 du plugin QGIS processing R, nous avons réalisé de nombreux correctifs qui concernaient principalement le support des sorties d'algorithme :
- [Bugfix] CSV Output Table destination was not in results
- [BUGFIX] Processing R algorithms do not have enough outputs
- [Bugfix] Support file destination and output
- Folder destination path added in input commands
- Fix return output file destination value
Les améliorations importantes de la version 3.0.0 concernent les possibilités de description des algorithmes :
- Utilisation de la documentation des paramètres depuis le fichier d'aide
- Définition d'une nouvelle ligne de métadonnées display_name pour le libellé de l'algorithme
- Utilisation de la chaîne de caractère de description pour les paramètres des algorithmes
Amélioration de la documentation des scripts
Depuis la version 3.16 de QGIS, il est possible de définir une aide pour les paramètres d'un algorithme. Cette possibilité est disponible pour les plugins ajoutant un fournisseur d'algorithme, les scripts Python et les modèles de traitements.

Avec la version 3.0.0 du plugin QGIS processing R, l'aide pour les paramètres peut-être défini dans le fichier d'aide du script. Ce fichier d'aide est un fichier JSON. Le nom du paramètre sert de clé pour définir l'aide de celui-ci.

Par exemple pour un algorithme dont les paramètres polyg et RPLOTS, le document d'aide contiendra ces clés
```
{
  "ALG_DESC": "Test help.",  // Description de l'algorithme
  "ALG_CREATOR": "Me",  // Créateur de l'algorithme
  "polyg": "A polygon layer", // Aide du paramètre polyg
  "RPLOTS": "Plot output", // Aide du paramètre RPLOTS
  "ALG_HELP_CREATOR": "Me2" // Créateur de l'aide
}
```
L'aide des paramètres apparaitra sous forme de Tooltip des champs de saisie de la fenêtre de l'algorithme. Il sera utilisé comme description des paramètres dans la description des algorithmes publiés en OGC Web Processing Service (wps) avec py-qgis-wps.
Définition du titre de l'algorithme
Le titre d'un algorithme basé sur un script R est défini par le plugin de la façon suivante : 1. Le premier nom possible est déduit du nom du fichier du script R, les _ sont remplacés par des espaces. Le nom du fichier sert d'identifiant pour l'algorithme. 2. Le second nom possible est déduit de la ligne de métadonnées (ligne commençant par ##) name, les _ sont remplacés par des espaces. La valeur de la ligne de métadonnées name sert d'identifiant à l'algorithme. 3. Le troisième nom possible est la valeur de la ligne de métadonnées display_name. L'identifiant de l'algorithme sera la valeur de la ligne de métadonnées name ou le nom du fichier.

Avec la version 3.0.0 du plugin QGIS processing R, il est possible de dissocié clairement le titre de l'algorithme de son identifiant.
Description avancée des paramètres
La description des paramètres d'un algorithme basé sur un script R repose sur les lignes de métadonnées. Ces lignes commencent par ##.

Par défaut la description des paramètres se fait selon la structure imaginée par Victor Olaya pour les scripts Python dans la version pour QGIS 2 du module Traitement. Un paramètre se décrit de la façon suivante param_name=[optional] param_type [default_value/values/from_variable]. Cette structure s'appuie sur la définition des méthodes asScritCode / fromScriptcode des classes de paramètres de Processing (toutes les classes filles de QgsProcessingParameterDefinition).

Les entrées peuvent donc ressembler à ceci :
- ##Layer=vector spécifie qu'il y aura une variable Layer qui sera un couche vectorielle
- ##Size=number 10 spécifie qu'il y aura une variable Size qui sera numérique, et que la valeur par défaut de Size sera 10
- ##X=Field Layer spécifie qu'il y aura une variable X sera le nom du champ pris dans la couche vectorielle du paramètre Layer
Le script R test_algorithm_2.rsx qui permet de tester que le plugin analyse correctement la description des paramètres, présente d'autres exemples de paramètres.

Le défaut de cette description compacte des paramètres est qu'elle ne permet pas de les configurer complètement. Par exemple il n'est pas possible d'ajouter une description ou une aide.

Pour remédier à cela, nous avons décider de réutiliser une autre façon de décrire les paramètres déjà disponible dans le module Traitement de QGIS. Cette description avancée des paramètres a été conçu pour les fournisseur d'algorithmes que sont GDAL, GRASS7, SAGA et Orpheo Toolbox.

Les paramètres sont décrit de la façon suivante QgsProcessingParameter|name|description|other_parameters_separated_by_pipe. other_parameter_separated_by_pipe contient les autres paramètres d'initialisation du paramètre d'entré de l'algorithme.

Les entrées peuvent donc ressembler à ceci :
- ##QgsProcessingParameterFeatureSource|INPUT|Vector layer spécifie qu'il y aura une variable INPUT qui sera un couche vectorielle dont la description est Vector layer
- ##QgsProcessingParameterNumber|SIZE|Aggregation Size|QgsProcessingParameterNumber.Integer|10 spécifie qu'il y aura une variable Size qui sera numérique de type entier, que sa description est Aggregation Size, et que la valeur par défaut de Size sera 10
- ##QgsProcessingParameterField|FIELDS|Attributes|None|INPUT|-1|False|False spécifie qu'il y aura une variable FIELDS sera le nom du champ pris dans la couche vectorielle du paramètre INPUT et que sa description est Attributes
Le seul défaut de cette façon de décrire les entrées de l'algorithme est qu'elle nécessite de connaître les classes de paramètres de Processing (toutes les classes filles de QgsProcessingParameterDefinition).
Conclusion
L'ensemble de ces améliorations permettent de construire des algorithmes dont l'interface quelle soit graphique dans QGIS bureautique, en ligne de commande avec qgis_process, ou en mode Web avec la norme WPS et py-qgis-wps, est plus conviviale pour les différents utilisateurs.

D'ailleurs les procédés mise en oeuvre au sein du plugin QGIS Processing R pourrait très bien être adapté à d'autres langages de programmation comme Julia.
9:00
3liz: QGIS Processing R 3
sur Planet OSGeo
QGIS Processing R plugin version 3.0
The QGIS-processing-R plugin, let's you write R scripts to be processed by/in QGIS

The QGIS-processing-R plugin was developed after some refactoring of teh qgis processing in QGIS 3. North Road adapted and reused some of the QGIS 2 code to make this happen in QGIS 3.

A new major version was released. This version contains fixes developed by 3liz for Ifremer's Sextant platform.

Since version 2.0.0 of QGIS-processing-R, we've fixed mostly output related bugs :
- [Bugfix] CSV Output Table destination was not in results
- [BUGFIX] Processing R algorithms do not have enough outputs
- [Bugfix] Support file destination and output
- Folder destination path added in input commands
- Fix return output file destination value
The major addenda to version 3.0.0 are based around description of the algorithms:
- Documentation of the parameters from the help file
- New metadata entry display_name for the name of the algorithm
- Usage of the description string as a parameter of the algorithms.
Better Scripts documentation
Since version 3.16 of qgis, it is possible to define help for the parameter of an algorithm. This feature is available for plugins providing algorithm, python scripts and processing models.

Version 3.0.0 of the R processing qgis plugin, parameter help can be defined in the help file for said scripts. The help file is a json file. The name of the parameter is the key to define its help.

Let's look at an example for an algorithm whose parameters and polyg and RPLOTS, the help file would contain the following keys:
```
{
  "ALG_DESC": "Test help.",  // Algorithm's description
  "ALG_CREATOR": "Me",  // Algorithm's creator
  "polyg": "A polygon layer", // polyg parameter help
  "RPLOTS": "Plot output", // RPLOTS parameter help
  "ALG_HELP_CREATOR": "Me2" // Algorithm help's creator
}
```
The help for parameter will appear in the form of a tooltip on the input field in the window of the algorithm. It will be used as a description for the parameters in the algorithm published as an OGC Web Processing Service WPS with py-qgis-wps.
Defining the algorithm title
The title of a R script algorithm is defined like so by the plugin:
1. The first possible title is based on the name of the R script file _ are replaced by spaces. The file name also serves as an ID for the algorithm.
2. The second possible title is read from the metadata (lines starting with ## ) name, as above the _ are replaced by spaces. The name metadata serves as an ID for the algorithm.
3. THe third and last possibility is the display_name metadata entry. The ID will either be deducted from the file name or the name metadata.
With version 3.0.0 of the R processing qgis plugin, you can clearly identify the algorithm tile and its ID.
Advanced parameter description
Parameter description in a R based algorithm rely on metadata. These lines start with ##.

Parameter description use the structure developed by Victor Olaya in the QGIS 2 of the processing module. A parameter is explained with the following metadata sequence param_name=[optional] param_type [default_value/values/from_variable]. This structure relies onf the asScritCode / fromScriptcode from the processing class parameters (all the children classes of QgsProcessingParameterDefinition).

Entries can look like this
- ##Layer=vector there will be a Layer parameter and it will be a vector layer
- ##Size=number 10 there will be a Size parameter, it will be a numeric value and it's default value will be 10
- ##X=Field Layer There will be a variable named X whose field name will be taken from the Layer parameter
The R script test_algorithm_2.rsx let you test the plugin and will properly analyse parameter descriptions. It also contains other parameter examples.

There is one issue with this compact description of parameters : it's incomplete. For instance, you can't add a description, or an help entry.

To fix this, we decided to follow what other processing modules for QGIS were particularly : GDAL, GRASS7, SAGA and Orpheo Toolbox.

Parameters are described as such QgsProcessingParameter|name|description|other_parameters_separated_by_pipe. other_parameter_separated_by_pipe contains the other initialization parameter for the algorithm.

Entries can look like this:
- ##QgsProcessingParameterFeatureSource|INPUT|Vector layer There will be an INPUT variable. INPUT is a vector layer and it's description is Vector Layer.
- ##QgsProcessingParameterNumber|SIZE|Aggregation Size|QgsProcessingParameterNumber.Integer|10 A numeric variable named Size, whose description will be Aggregation Size a and default value will be 10.
- ##QgsProcessingParameterField|FIELDS|Attributes|None|INPUT|-1|False|False Specifies that there is a FIELDS variable whose name will be taken from the INPUT vector parameter, and it's description is Attribute.
The only issue with this technique is that you eed now all the classes for Processing parameters (all the children classes of QgsProcessingParameterDefinition)
To conclude
All these features will let you build algorithms, that will be way easier to use either on the desktop, command line with qgis_process or using the web with WPS and py-qgis-wps.

What we did to have R scripts in QGIS-processing-R could be adapted to other programming languages like Julia.
21 June 2021
11:00
CARTO Blog: Authoritative Environmental Remediation Mapping in NYC
sur Planet OSGeo

This post was originally published on eSpatially New York by Sam Wear and has been reproduced with permission.
11:00
CARTO Blog: Join CARTO at Mobile World Congress MWC21 Barcelona
sur Planet OSGeo

With in-person events making a welcome return this year, we are very pleased to announce that CARTO will be attending Mobile World Congress (MWC) Barcelona taking place nex...
20 June 2021
20:33
gvSIG Team: VCSGis I, usando un control de versiones con mi información cartográfica personal.
sur Planet OSGeo
¿Quién no ha tenido que recurrir a una copia perdida, en alguna carpeta del ordenador, con nuestros datos, para rescatar información tal y como estaba hace unos meses? No es que sea algo que ocurra todos los días, pero de vez en cuando se da y entonces suele causarnos algún dolor de cabeza. Y más aún si solo tenemos que recuperar algunos registros de una capa que borramos o modificamos hace semanas por accidente y queremos recuperar solo esos.

En los últimos años, en otros contextos que no están relacionados con la gestión de cartografía, ya va siendo normal encontrarnos con sistemas de control de versiones (VCS, del inglés Version Control System) para gestionar la información. Sin embargo, en los entornos SIG, no es tan habitual, sobre todo por la escasa o nula oferta que podemos encontrar en entornos no privativos. Pues bien, a partir de gvSIG Desktop 2.6 podremos disponer de un sistema de control de versiones, VCSGis, en un software libre y que podremos utilizar directamente sin instalar nada más que el propio gvSIG Desktop.

Entonces, si tengo instalado (o una portable) gvSIG Desktop 2.6…

¿Cómo puedo empezar a usar el control de versiones sobre mis tablas y capas ?
- Lo primero será crear un repositorio para el control de versiones. Algo así como un espacio en el que se almacenarán todos mis datos… y los cambios que voy haciendo sobre ellos. En jerga gvSIG le llamaremos un repositorio VCSGis
- Lo segundo, crear una copia de trabajo vinculada a dicho repositorio. Será sobre esa copia de trabajo sobre la que trabajaremos habitualmente.
- Tercero… cargar nuestras tablas y capas en la copia de trabajo y sincronizarla con el repositorio VCSGis.
A partir de ahí, simplemente seguiremos trabajando de forma normal con gvSIG Desktop e iremos sincronizando con el repositorio de vez en cuando, normalmente al inicio o fin de nuestra sesión de trabajo.

Esto, dicho así, a algunos podrá parecerles algo complicado, pero nada mas lejos de la realidad. Voy a ir contándolo con un poquito mas de detalle en este post, solo un poquito, que no quiero alargarme demasiado.

Creación de un repositorio personal

El repositorio VCSGis no es más que una base de datos con una serie de tablas especiales, donde VCSGis almacena nuestra información. Para nuestro uso personal, normalmente será suficiente con usar el gestor de base de datos H2 que viene incluido con gvSIG Desktop. Para ello, simplemente accederemos al menú:
```
Herramientas -> VCSGis -> Administración -> Inicializar un repositorio.
```
Nos solicitará que seleccionemos una conexión a una base de datos e inicializará el repositorio VCSGis en ella.

Creación de una copia de trabajo

Lo segundo que teníamos que hacer… crear una copia de trabajo vinculada a ese repositorio. La copia de trabajo no es más que otra base de datos, normalmente en formato H2Spatial, donde estarán nuestras tablas, con las que trabajaremos, y una serie de tablas para poder mantener la información sincronizada con el repositorio.

Crear una copia de trabajo es también una tarea muy sencilla. Accederemos a la opción de menú:
```
Herramientas -> VCSGis -> Inicializar copia de trabajo.
```
Nos pedirá que seleccionemos la conexión a la base de datos del repositorio, y un nombre de archivo en el que crear nuestra copia local.

Estos dos pasos, crear el repositorio y la copia local, normalmente los haremos una sola vez. Una vez ya creados y configurados, podemos trabajar con ellos, sin necesidad de volver a crear otros.

Añadir capas y guardarlas en el repositorio

Ya tenemos nuestro repositorio y nuestra copia de trabajo. Solo hemos tardado unos pocos minutos. Ahora cargaremos nuestras capas en la copia local y las sincronizaremos con el repositorio.

Cargaremos en una Vista nuestra capa… por ejemplo, yo tengo por aquí una de provincias de España (esp_provincias). No voy a contar como cargar una capa en una Vista de gvSIG Desktop, seguro que ya sabéis. Con la capa cargada en la Vista, seleccionaremos la opción de menú:
```
Herramientas -> VCSGis -> Añadir a la copia de trabajo.
```
En el cuadro de diálogo que se muestra indicaremos nuestra copia de trabajo y, en la pestaña Capas, seleccionaremos la capa que queremos cargar de entre las existentes en la Vista de gvSIG Desktop. Y, por último, pulsaremos el botón de “Añadir a la copia de trabajo”. Una vez terminado el proceso, cerraremos el diálogo.

Como resultado tendremos cargada en la Vista nuestra capa… ¡¡ dos veces !!

Es normal. Estamos viendo nuestra capa original y una copia que se ha creado en… nuestra copia de trabajo. Eliminaremos la capa original de la Vista y, a partir de ese momento, trabajaremos con la que está en nuestra copia de trabajo.

Pero aún no hemos terminado del todo este proceso. Todavía tenemos que sincronizar nuestra copia de trabajo con el repositorio. Algo que sigue siendo muy fácil. Seleccionaremos la opción de menú:
```
Herramientas -> VCSGis -> Mostrar cambios
```
Seleccionaremos nuestra copia de trabajo y veremos, en la pestaña Copia de trabajo, que aparece la capa que acabamos de añadir. Solo tenemos que marcarla (haciendo clic en el check de esta), y pulsar el botón con la flechita azul que dice “commit”. Y al terminar ya podemos cerrar la ventana.

Guardar mi capa de Provincias en el repositorio ha llevado menos de un minuto. Y hacer todos los pasos, desde el comienzo del artículo, me ha llevado menos de 5. Si la capa a añadir a nuestro repositorio personal es muchísimo mas grande puede tardar algo mas, pero solo será durante esa carga inicial donde notaremos la pesadez de la capa.

Realizar modificaciones en nuestras capas

¿Y ahora, qué tendría que hacer para trabajar con mi capa?

Si hemos cerrado gvSIG Desktop, cuando lo volvamos a abrir tenemos que cargar de nuevo la capa. También fácil. Sacaremos el dialogo de Añadir capa y seleccionaremos la pestaña VCSGis. Seleccionaremos nuestra copia local, y nos mostrará las capas que tenemos disponibles, podremos seleccionar la nuestra y cargarla en la Vista.

Una vez cargada… trabajamos con ella como solemos hacer, si precisamos modificarla entramos en edición, la modificamos y terminamos edición. Tantas veces como necesitemos. Durante un rato nos olvidamos que se trata de una capa que esta en un sistema de control de versiones y trabajamos con ella como con cualquier capa de gvSIG en base de datos. Cuando hayamos terminado de trabajar con ella… seleccionamos la herramienta de Mostrar cambios. Indicamos nuestra copia de trabajo, marcamos nuestra capa en la lista de capas de esa copia de trabajo y pulsamos el botón Commit. Como hicimos cuando añadimos la capa al repositorio. Y nuestros cambios se integrarán en él.

El proceso de modificación de nuestra capa, y sincronización con el repositorio, lo repetiremos tantas veces como necesitemos, y de esa forma dispondremos de un histórico de cómo se encontraba la capa en cada momento.

Recuperar una versión anterior de mis datos

Y un día, de repente, nos pasa. ¡Oh! ¡Nos acabamos de dar cuenta que ya debe hacer un par de semanas que borramos un registro!. Debí borrar por error la provincia de Almería, y no me había dado cuenta hasta hoy. Y lo peor es que he estado trabajando sobre otras zonas de la capa y no quiero perder los cambios. Es ahí donde te acuerdas que llevas trabajando un tiempo con un sistema de control de versiones. Y que puedes utilizarlo para recuperar los datos de hace dos semanas y mezclarlos con tus cambios.

En general siempre podrás recuperar una versión de tus capas desde la ventana de “Obtener copia local (checkout)” que encontraras en la opción de menú:
```
Herramientas -> VCSGis -> Obtener copia local (checkout)
```
Pero antes de seguir… asegurate que no tienes cambios por sincronizar con el repositorio, que todos tus cambios sobre la capa que quieres trabajar están guardados, subidos, en el repositorio. Si ya no tienes ningún cambio en tu copia local, volvemos a la ventana de “Obtener copia local (checkout)”.

Seleccionaremos nuestra copia de trabajo, nuestra capa, marcaremos el check de “Sobrescribir tabla”, y pulsaremos en el botón de revisión para seleccionar que revisión queremos recuperar, en mi caso la revisión 1, que era la última en la que aún estaba la provincia de Almería. Finalmente, pulsaremos en el botón de “Obtener copia local (checkout)” y cuando termine, cerraremos este diálogo.

Y ahora… nuestra capa en la copia local está en el estado en que estaba la revisión que he seleccionado… y…

¿Dónde están los cambios que hice desde entonces ?

¡¡¿Los he perdido?!!

No. No hay que asustarse. Están en el repositorio. Solo tenemos que ir a la ventana de cambios, seleccionar nuestra copia de trabajo e ir a la pestaña de Repositorio. Seleccionaremos nuestra capa y pulsaremos en el botón de “Descargar cambios remotos de la tabla seleccionada” y en la tabla de la derecha tendremos todos los cambios que hemos realizado desde la revisión que tenemos ahora en la copia local. Podremos seleccionar cuales queremos descargar y cuales no, y luego subiremos el estado en que dejemos nuestra capa al repositorio.

Una pequeña anotación. Si en la lista de cambios seleccionamos un registro, y tenemos en la Vista activa la capa en cuestión, podemos utilizar los botones Centrar y Zoom, para ver cómo estaba y mostrará la información gráfica del registro.

Lo he contado todo muy rápido, dar una pincelada rápida de lo que sería trabajar con el sistema de control de versiones de gvSIG Desktop VCSGis. Se pueden hacer muchas más cosas de lo que he contado, pero este articulo ya ha salido muy largo. Lo dejamos para futuros post.

Importante de cara a acercarse a VCSGis… dos conceptos a recordar:
- Repositorio VCSGis. Donde se guardan todos nuestros datos.
- Copia de trabajo (ligada a un repositorio). Donde tenemos una copia de una versión de nuestros datos con la que trabajamos.
Y otra cosa importante… si tenemos que hacer copia de nuestros datos lo haremos de la base de datos del repositorio, normalmente dos ficheros (.mv.db y .trace.db) y lo haremos cuando no este gvSIG Desktop arrancado

Espero que os haya servido, o como mínimo que haya sido interesante.
19 June 2021
19:26
Jackie Ng: Announcing: MapGuide Open Source 4.0 Preview 3
sur Planet OSGeo
Here is the long awaited third preview release of MapGuide Open Source 4.0.
Refer to the release notes for download links and an overview of what's new and change since the last preview release.
For MapGuide users on Linux who use Java, you will be glad to hear that Java support is back and fully operational with this release (no more 403 errors from Tomcat). Restoring Java support on Linux came at a small price, we now no longer ship MapGuideApi.jar as the Java wrapper to the MapGuide API. We now only ship MapGuideApiEx.jar which has been in all MapGuide Open Source releases since 2.5 and this wrapper fixes most of the "cruftiness" of the original Java wrapper as described in this RFC where it was first introduced.
For those who like to swap the bundled GDAL dll on windows with a version with an expanded suite of raster/vector driver support, this release will make this process more seamless:
- Our internal GDAL version is now 2.4.4, the latest in the 2.x series.
- Our internal xalan/xerces dlls now have a "fdo" suffix in their dll name, so you are no longer forced to overwrite these dlls when overlaying an external GDAL dll from gisinternals and introduce potential instability as a result.
- All of our FDO providers that link to GDAL/OGR now only use their C API to avoid any potential ABI incompatibilities from replacing our internal GDAL dll with an external one that may not be built with the same MSVC compiler version as ours.
Other than that, Preview 3 is mostly a roll up of fixes to MapGuide/FDO since the last preview release to tide things over while work is still ongoing to support PHP7 in our MapGuide API to clear the obstacle to a final 4.0 release.
But before then, as of this release I will be taking a short break from all things open source. I am mildly burned out all things considered and a good solid month or two away from all things open source should hopefully be enough time to recharge the batteries.
18 June 2021
12:11
gvSIG Team: Clipping overlapping polygons on the same layer
sur Planet OSGeo

Sometimes we can have a layer where we have overlapping polygons, and we need to clip one of them so that there is no overlap (for example a large parcel with an internal parcel, where we really have the polygon of the large parcel without the gap).

For this, the Difference geoprocess can be applied on gvSIG, but with a specific configuration and steps. In this video you can see better how it would be applied:
12:06
gvSIG Team: Recortar polígonos superpuestos en una misma capa
sur Planet OSGeo

En ocasiones podemos tener una capa donde tenemos polígonos superpuestos, y necesitamos que uno de ellos esté recortado para que no haya superposición (por ejemplo una parcela grande con una parcela interna, donde realmente tenemos el polígono de la parcela grande sin el hueco).

Para ello se puede aplicar el geoproceso Diferencia de gvSIG, pero con una configuración específica, y unos pasos concretos. En este vídeo podéis ver mejor cómo se aplicaría:
0:55
GeoTools Team: GeoTools 25.1 Released
sur Planet OSGeo

The GeoTools team is pleased to announce the release GeoTools 25.1: geotools-25.1-bin.zip geotools-25.1-doc.zip geotools-25.1-userguide.zip geotools-25.1-project.zip GeoTools 25.1 is published to repo.osgeo.org for direct build integration. This release is made in conjunction with GeoServer 2.19.1 and GeoWebCache 1.19.1.DuplicatingStyleVisitor vendor optionsThe SLD vendor options
17 June 2021
15:19
GeoSolutions: GeoSolutions Participation at FOSS4G 2021
sur Planet OSGeo

You must be logged into the site to view this content.
11:00
CARTO Blog: CARTO announced as a Google Cloud Edge partner for Communications Service Providers
sur Planet OSGeo

Last year, Google Cloud announced a new initiative bring partner solutions to the network edge, enabling a wide range of clients in industries such as CPG, Retail, and Manu...
16 June 2021
7:00
Lutra consulting: Mergin CE (open source) released
sur Planet OSGeo

We’d like to share some exciting news with you about our cloud-based geo-data synchronisation service, Mergin.

In this post we’ll talk both about Mergin the online managed service (Mergin Cloud) and also about the software stack that powers it (the Mergin Software Stack).
Mergin CE
The Mergin Software Stack has been developed and maintained at Lutra Consulting over the past 3 years to power our Mergin Cloud service and has been maturing nicely in production.

We believe a sync service for supporting field-based GIS activities has been a missing piece of the open geospatial puzzle, and as strong advocates of open source software, we’re now sharing the Mergin Software Stack with the community. Therefore, on the 14th of June we released Mergin CE on GitHub. The CE stands for Community Edition.

The release means a fully open solution for field data collection and synchronisation is now possible using QGIS, Input app and Mergin CE.

Mergin CE is released under the AGPL licence and we are open to contributions from others. Looking forward to seeing what the open source community has to offer!

Mergin CE gives you the freedom to deploy, host and manage your own Mergin server on your own infrastructure, giving you complete control over your data. Mergin CE comes without commercial support.

Our main efforts are still very much focussed on the continuous improvement of Mergin Cloud, making it an awesome fully managed service for our customers.

We also now provide Mergin EE (Enterprise Edition) for those who want an on-premises deployment but with extra features like Active Directory integration, commercial support, and/or prefer a licence other than AGPL.
Changes to Mergin Cloud
Releasing Mergin CE got us taking another look at Mergin Cloud’s Community (free of charge) tier. That’s why from today we’re updating Mergin Cloud’s Terms of Service so its free tier can no longer be used to store projects for commercial use. Mergin accounts storing projects for commercial use should now purchase a paid subscription after their initial 14 day evaluation period.

A common surveying setup is a single paid account (providing extra storage for projects) and a handful of free tier accounts used by surveyors for collecting field data. This is still possible because the new Terms only require that the Mergin account hosting/storing/owning the commercial project has a paid subscription.

For example, consider two users: Fred (who uses a free account) and Penny (who uses a paid account). Penny is permitted to use the project Penny/Survey for commercial purposes as it resides on her paid account. Fred (who uses a free account) is permitted to collaborate on the commercial project Penny/Survey as it resides on Penny’s paid account. However, Fred may not use the project Fred/Survey2 for commercial use as it resides on his free account.

In light of the release of Mergin CE, we feel it is fair to encourage those using Mergin Cloud’s free tier for commercial gain to support us with one of our affordable subscriptions. The link also has a number of frequently asked questions relating to this change.
You may also like... Input, a field data collection app based on QGIS. Input makes field work easy with its simple interface and cloud-based sync. Available on Android and iOS.
15 June 2021
13:53
geomati.co: Adquisición de imágenes satélite de alta resolución, ¡contacte con ventas!
sur Planet OSGeo

Jornadas SIG Libre 2021
La entrada Adquisición de imágenes satélite de alta resolución, ¡contacte con ventas! se publicó primero en Geomatico.
13:09
geomati.co: El servicio para desarrolladores de Transports Metropolitans de Barcelona
sur Planet OSGeo

Jornadas SIG Libre 2021

La entrada El servicio para desarrolladores de Transports Metropolitans de Barcelona se publicó primero en Geomatico.
11:00
CARTO Blog: Analyzing Water Access in Brazil during the COVID-19 Pandemic
sur Planet OSGeo

With over 17 million cases, and close to 500,000 deaths, Brazil has suffered the world’s third worst COVID-19 outbreak outside the United States and India and its second-de...
12 June 2021
16:35
Volker Mische: Video uploads for an online conference
sur Planet OSGeo
This blog post should give some insights on what happens behind the scenes in preparation of an online conference, and I also hope that some of the scripts I created might be useful for others as well. We were using pretalx for the submissions and Seafile for video uploads. Both systems are accessed over their HTTP API.

This year’s FOSSGIS 2021 conference was a pure online conference. Though it had the same format as every year. Three days of conference, with four tracks in parallel. This leads to about 100 talks. I joined the organizing team about 10 weeks before the conference took place. The task sounded easy. The speakers should be able to upload their talks prior to the conference, so that during the conference less could go wrong.

All scripts are available at [https:]] licensed under the MIT License.
The software
The speakers submitted their talks through pretalx, a conference management system I highly recommend. It is open source and has an active community. I’ve worked on/with it over the past few to make it suitable for OSGeo conferences. The latest addition is the public community voting plugin, which has been used for the FOSS4G 2021 as well as this conference. pretalx has a great HTTP API to get data out of the system. It doesn’t yet have much support for manipulating the data, but pull-requests are welcome.

For storing the video files, Seafile was used. I haven’t had any prior experience with it. It took me a bit to figure out, that the Python API is for local access only and that the public API is a pure HTTP API. You can clearly see that their API is tailored to their use in their web interface and not really designed for third party usage. Nonetheless, it guarantees that you can do everything via the HTTP API, that can be done through the web UI.

My scripts are heavily based on command line tools like b2sum, curl, cut, jq and jo, hence a lot of shell is used. For more complex data manipulation, like merging data, I use Python.
The task
The basic task is providing pre-recorded videos for a conference that were uploaded by the speakers themselves. The actual finer grained steps are:
- Sending the speakers upload links
- Looking through the videos to make sure they are good
- Re-organizing the files suitable to be played back according to the schedule
- Make the final files easily downloadable
- Create a schedule which lists the live/pre-recorded talks
Sending upload links
In Seafile you can create directories and make them publicly available so that people can upload files. Once uploaded, you won’t see what else in that directory. In order to be able to easily reference the uploaded videos back to the corresponding talk, it was important to create one dedicated directory per talk, as you won’t know which filenames people will use for their videos.

The speakers will receive an email containing dedicated upload links for each of their talks. See the email_upload_links directory for all the scripts that are needed for this step.
pretalx
First you need to get all the talks. In pretalx that’s easy, go to your conference, e.g. [https:]] . We only care about the accepted talks, which can be done with selecting a filter. If you access it through curl, you’ll get a JSON response like that one: [https:]] . pretalx returns 25 results per request. I’ve created a script called pretalx-get-all.py that automatically pages through all the results and concatenates them.

A talk might be associated with multiple speakers. Each speaker should get an email with an upload link. There were submissions that are not really talks in the traditional sense, so people shouldn’t get an email. The query for jq looks like that:

[.results[] | select((.submission_type[] | contains("Workshop")) or (.submission_type[] == "Anwendertreffen / BoF") | not) | { code: .code, speaker: .speakers[].code, title: .title, submission_type: .submission_type[]}]

The submissions contain only the speaker IDs and names, but not other details like their email address. We query the speakers API (e.g. [https:] and post-process the data again with jq, as we care about their email addresses.

You can find all the requests and filter in the email_upload_links/upload_talks_to_seafile.sh script.
Seafile
Creating and upload link is a two-step process in Seafile. First create the directory, then creating a public accessible upload link for the directory. The directories are named after the pretalx ID of the talk (Full script for creating directories).
Creating emails
After acquiring the data, the next step is to process the data and creating the individual emails. Combining the data is done with the combine_talks_speakers_upload_links.py script, where the output is again post-processed with jq. The data_to_email.py script takes that data output and a template file to create the actual email as files. The template file is used as a Python format string, where the variables a filled with the data provided.

Those email files are then posted to pretalx, so that we can send them over their email system. That step is more complicated as currently there is no API in pretalx to do that. I logged in through the web interface and manually added a new email, while having the developer tools open. I then copied the POST request “as cURL” to have a look at the data it sent. There I manually extracted the session and cookie information in order to add emails from the command line. The script that takes the pre-generated emails and puts them into pretalx is called email_to_pretalx.sh.
Reviewing the uploaded videos
Once a video is uploaded, it gets reviewed. The idea was, that the speakers don’t need to care too much about the start and the end of the video, e.g. when they start the recording and there is a few seconds of silence while switching to the presentation. The reviewer will cut the beginning and end of the video and also convert it to a common format.

We wanted to preserve the original video quality, hence we use LosslessCut and converted it then to the Matroska format. The reviewers would also check that the video isn’t longer than the planned slot.

See the copy_uploads directory for all the scripts that are needed for this step.
pretalx
The reviewers get a file with things to check for each video file. We get the needed metadata again from pretalx and post-process it with jq. As above for the emails, there is again a template file which (this time) generates Markdown files with the information for the reviewers. The full script is called create_info_files.sh.
Seafile
Once videos are uploaded they should be available for the reviewers. The uploaded files are the primary source, hence it makes sense to always make copies of the talks, so that the original uploads are not lost. The sync_files_and_upload_info.sh script copies the talks into a new directory (together with the information files), which is then writeable for the reviewers. They will download the file, review it, cut it if needed, convert it to Matroska and upload it again. Once uploaded, they move the directory into one called fertig (“done” in German) as an indicator that no one else needs to review it.

I run the script daily as a cron job, it only copies the new uploads. Please note that it only checks the existence on a directory level. This means that if a talk was reviewed and a speaker uploads a new version of the talk, it won’t be copied. That case didn’t often happen often and speakers actually let us know about it, so it’s mostly a non-issue (also see the miscellaneous scripts section for more).

Last step is that someone looks through the filled out markdown files to check if everything was alright, respectively make sure that e.g. the audio volume is fixed, or asks the speaker for a new upload. The then checked videos are moved to yet another directory, which then contains all the talks that are ready to be streamed.
Re-org files for schedule
So far, the video files were organized by directories that are named after the pretalx ID of the talk. For running the conference we used OBS for streamer. The operator would need to play the right video at the right time. Therefore, it makes sense to sort them by the schedule. The cut_to_schedule.sh script does that re-organization, which can be found in the cut_to_schedule directory.
pretalx
To prevent accidental inconsistencies, the root directory is named after the current version of the pretalx schedule. So if you publish a new version of the schedule and run the script again, you’ll get a new directory structure. The video files still have an arbitrary name, chosen by the uploader/reviewer, we want a common naming scheme instead. The get_filepath.py script creates such a name that also sorts chronologically and contains all the information the OBS operators need. The current scheme is <room>/day<day-of-the-conference>/day<day-of-the-conference>_<day-of-the-week>_<date>_<time>_<pretalx-id>_<title>.mkv.
Seafile
The directories do not only contain the single final video, but also the metadata and perhaps the original video or a presentation. The file we actually copy is the *.mkv file which was modified last, which will be the cut video. The get_files_to_copy.sh script creates a list of the files that should be copied, it will only list the files that weren’t copied yet (based on the filename). The copy_files.sh script does the actual copying and is rather generic, it only depends on a file list and Seafile.
Easily downloadable files
Seafile has a feature to download a full directory as zip file. I originally planned to use that. It turns out that the size of the files can be too large, I got the error message Unable to download directory "day1": size is too large.. So I needed to provide another tool, as I didn’t want that people would need to click and download all individual talks.

The access to the files should as easy as possible, i.e. the operators that need the files shouldn’t need a Seafile account. As the videos also shouldn’t be public, the compromise was using a download link secured with a password. This means that an authentication step is needed, which isn’t trivial. The download_files.sh script does login and then downloads all the files in that directory. For simplicity, it doesn’t do recursively. This means that any stage would need to run this script for each day.

I also added a checksum check for more robustness. I created those checksums manually with running b2sum * > B2SUMS in each of the directories and then uploaded them to Seafile.
List of live/pre-recorded talks
Some talks are recorded and some are live, the list_recorded_talks.py script, creates a Markdown file that contains a schedule with that information, including the lengths of the talks if they are pre-recorded. This is useful for the moderators to know how much time for questions will be. At the FOSSGIS we have 5 minutes for questions, but if the talk runs longer, there will be less time.

You need the schedule and the length of the recorded talks. This time I haven’t fully automated the process, it’s a bit more manual than the other steps. All scripts can be found in the list_recorded_talks directory.

Get the schedule:
```
curl [https:] > schedule.json
```
For getting the lengths of the videos, download them all with the download script from the Easily downloadable files section above. Then run the get_length.sh script in each of the directories and output then into a file. For example:
```
cd your-talks-day1
/path/to/get_lengths.sh > ../lengths/day1.txt
```
Then combine the lengths of all days into a single file:
```
cat ../lengths/*.txt > ../talk_lengths.txt
```
Now you can create the final schedule:
```
cd ..
python3 /path/to/list_recorded_talks.py schedule.json talk_lengths.txt
```
Here’s a sample schedule from the FOSSGIS 2021.
Miscellaneous Scripts Speaker notification
The speakers didn’t get feedback whether their video was correctly uploaded/processed (other than seeing a successful upload in Seafile). A short time before the conference, we were sending out the latest information that speakers needs to know. We decided to take the chance to also add information whether their video upload was successful or not, so that they can contact us in case something with the upload didn’t go as they expected (there weren’t any issues :).

It is very similar to sending out the email with the upload links. You get the information about the speakers and talks in the same way. The only difference is we now also need the information whether the talk was pre-recorded or not. We get that from Seafile:
```
curl --silent -X GET --header 'Authorization: Token <seafile-token>' 'https://seafile.example.org/api2/repos/<repo-id>/?p=/<dir-with-talks>&t=d'|jq --raw-output '.[].name' > prerecorded_talks.txt
```
The full script to create the emails can be found at email_speaker_final.sh. In order to post them to pretalx, you can use the email_to_pretalx.sh script and follow the description in the creating emails section.
Number of uploads
It could happen that people upload a new version of the talk. The current scripts won’t recognize that if a previous version was already reviewed. Hence, I manually checked the directories for the ones with more than one file in it. This can easily be done with a single curl command to the Seafile HTTP API:
```
curl --silent -X GET --header 'Authorization: Token <seafile-token>' 'https://seafile.example.org/api2/repos/<repo-id>/dir/?p=/<dir-with-talks>&t=f&recursive=1'|jq --raw-output '.[].parent_dir'|sort|uniq -c|sort
```
The output is sorted by the number of files in that directory:
```
  1 /talks_conference/ZVAZQQ
  1 /talks_conference/DXCNKG
  2 /talks_conference/H7TWNG
  2 /talks_conference/M1PR79
  2 /talks_conference/QW9KTH
  3 /talks_conference/VMM8MX
```
Normalize volume level
If the volume of the talk was too low, it was normalized. I used ffmpeg-normalize for it:
```
ffmpeg_normalize --audio-codec aac --progress talk.mkv
```
Conclusion
Doing all this with scripts was a good idea. The less manual work the better. It also enabled me to process talks even during the conference in a semi-automated way. I created lots of small scripts and sometimes used just a subset of them, e.g. the copy_files.sh script, or quickly modified them to deal with a special case. For example, all lightning talks of a single slot (2-4) were merged together into one video file. That file of course then isn’t associated with a single pretalx ID any more.

During the conference, the volume level of the pre-recorded talks was really different. I think for next time I’d like to do some automated audio level normalization after the people have uploaded the file. It should be done before reviewers have a look, so that they can report in case the normalization broke the audio.

The speakers were confused whether the upload really worked. Seafile doesn’t have an “upload now” button or so, it does it’s JavaScript magic once you’ve selected a file. That’s convenient, but was also confusing me, when I used it for the first time. And if you reload the page, you also won’t see that something was uploaded already. So perhaps it could also be automated that speakers get an email “we received your upload” or so.

Overall I’m really happy how the whole process went, there weren’t major failures like lost videos. I also haven’t heard any complaints from the people that needed to use any of the videos at any stage of the pipeline. I’d also like to thank all the speakers that uploaded a pre-recorded video, it really helped a lot running the FOSSGIS conference as smooth as it was.
10 June 2021
11:00
CARTO Blog: Building a Spatial Model to Classify Global Urbanity Levels
sur Planet OSGeo

Decision-makers in the private and public sector are trying to understand our rapidly changing use of urban areas. The way we shop and travel; what we expect from our livin...
09 June 2021
11:00
CARTO Blog: How to use Angular & CARTO to Build Scalable Spatial Apps
sur Planet OSGeo

Angular is one of the most popular frameworks for building web applications with a huge community of developers. It includes powerful features for building scalable applica...
7:00
Lutra consulting: Geodiff version 1.0
sur Planet OSGeo
We are excited to announce that the geodiff library has finally reached version 1.0. We have started to develop geodiff back in 2019 as a part of our efforts to allow synchronisation of changes between the Input mobile app and Mergin platform.

At the core, geodiff library provides functionality to:
- compare a pair of GeoPackage databases and create “diff” files containing changes between them
- apply a “diff” file to a GeoPackage database
- rebase changes in a “diff” file
- invert, concatenate diffs and other utility functions
Thanks to the above low-level operations, any changes to data stored in spatial/non-spatial tables in GeoPackages can be easily transferred to others and applied. And thanks to the “rebase” functionality - inspired by source code management systems like git - we can automatically merge changes from multiple users capturing data offline in Input/Mergin (see our recent blog post that covers rebasing for more).

The library is written in C++, providing stable C API and offering Python bindings as well (look for pygeodiff package in pip). It also comes with a command line interface tool geodiff covering all major features. The whole package has a very permissive MIT license.
Support for drivers
Initially, geodiff library only worked with SQLite / GeoPackage files. This has changed with the version 1.0 - geodiff supports drivers, allowing use of different database backends to compare and apply diffs. In the 1.0 release we have added PostGIS driver in addition to SQLite/GeoPackage driver.

This means that users can compare tables or apply diffs in PostGIS databases using the same APIs as with GeoPackages. And not only that - diff files are compatible across different drivers. That means it is possible to take a diff file from a GeoPackage and apply it to PostGIS database!

Using the PostGIS driver we were able to create mergin-db-sync tool as a companion to Mergin platform. With DB sync, one can keep a local PostGIS database always in sync with a project in Mergin, supporting automatic transfer of changes from Mergin to PostGIS and the other way round as well - from PostGIS to back Mergin.
Try it
The library is hosted on GitHub in lutraconsulting/geodiff repository. We would love to hear your feedback!
Stay tuned for more!
As announced earlier, next week we will be open sourcing Mergin, our platform for easy sharing of spatial data in teams (whether they are in office or in the field). If you have not heard about Mergin platform yet, please have a look at the Mergin website, try Mergin plugin for QGIS and Input app, a mobile app based on QGIS for iPhone/iPad and Android devices. Since the initial release in early 2019, Mergin and Input have been used by thousands of users around the world.

At Lutra Consulting, we are dedicated to improving free and open source software for geospatial. We will be releasing Mergin as open source to solve another missing piece in the puzzle, providing open source end-to-end solution for mobile data capture for QGIS users. Watch our blog and Twitter for further updates!
08 June 2021
12:49
GeoSolutions: Free Webinar – A DevOps Perspective on GeoServer: Monitoring, Metering, Logging and Troubleshooting a GeoServer Installation
sur Planet OSGeo

You must be logged into the site to view this content.
10:35
gvSIG Team: Seminario virtual: gvSIG Online, rompiendo las barreras necesarias para implantar con éxito Infraestructuras de Datos Espaciales
sur Planet OSGeo

Os invitamos al cuarto seminario online de la Red CYTED IDEais, que se realizará el jueves 24 de junio. En ella hablaremos de la solución gvSIG Online, una plataforma en software libre para implantar Infraestructuras de Datos Espaciales, y de los motivos de su éxito, al romper las principales barreras que impiden disponer de soluciones informáticas para gestionar eficientemente la información geográfica de cualquier organización.

Os podéis inscribir en [https:]]
07 June 2021
18:11
GeoSolutions: FedGeoDay
sur Planet OSGeo

You must be logged into the site to view this content.
04 June 2021
13:21
Free and Open Source GIS Ramblings: MovingPandas v0.7 released!
sur Planet OSGeo
The latest v0.7 release is now available from conda-forge.

New features include:
- Functions to convert Trajectories to GeoDataFrames (points, line segments, or whole trajectories)
- Clip and intersection now return TrajectoryCollection objects
As always, all tutorials are available from the movingpandas-examples repository and on MyBinder:
03 June 2021
2:00
GRASS GIS: Fred Limp's retirement
sur Planet OSGeo

The GRASS GIS community wants to honor Fred Limp on his retirement The GRASS GIS Project wants to honor Dr. Fred Limp, Jr., on the eve of his retirement, June 2021, from the Department of Geosciences at the University of Arkansas (UA). Fred was an early adopter and active promoter of GRASS GIS and open source geospatial technologies. He wrote a regular column called “Growing GRASS with Fred Limp” for the GRASS newsletter, GRASSCLIPPINGS (see pages 15-16).
31 May 2021
20:30
Fernando Quadro: 20 anos de PostGIS
sur Planet OSGeo

Hoje, há vinte anos, foi enviado o primeiro e-mail da lista de discussão dos usuários do PostGIS (na época hospedada no yahoogroups.com), anunciando o primeiro lançamento numerado do PostGIS.

O início da história do PostGIS estava intimamente ligada a uma empresa de consultoria fundada por Paul Ramsey alguns anos antes, a Refractions Research (2001) . Seus primeiros contratos acabaram sendo com o governo que, por suas próprias razões, não queria trabalhar com software ESRI.

Paul Ramsey escreveu um post detalhando como foi esse processo até chegar a histórica versão 0.1. Se você tiver interesse em ler essa história por completo, basta clicar aqui.
10:00
Paul Ramsey: PostGIS at 20, The Beginning
sur Planet OSGeo
Twenty years ago today, the first email on the postgis users mailing list (at that time hosted on yahoogroups.com) was sent, announcing the first numbered release of PostGIS.

$Refractions$

The early history of PostGIS was tightly bound to a consulting company I had started a few years prior, Refractions Research. My first contracts ended up being with British Columbia (BC) provincial government managers who, for their own idiosyncratic reasons, did not want to work with ESRI software, and as a result our company accrued skills and experience beyond what most “GIS companies” in the business had.

We got good at databases, and the FME. We got good at Perl, and eventually Java. We were the local experts in a locally developed (and now defunct) data analysis tool called Facet, which was the meat of our business for the first four years or so.

That Facet tool was a key part of a “watershed analysis atlas” the BC government commissioned from Facet in the late 1990’s. We worked as sub-contractors, building the analytical routines that would suck in dozens of environmental layers, chop them up by watershed, and spit out neat tables and maps, one for each watershed. Given the computational power of the era, we had to use multiple Sun workstations to run the final analysis province-wide, and to manage the job queue, and keep track of intermediate results, we placed them all into tables in PostgreSQL.

Putting the chopped up pieces of spatial data as blobs into PostgreSQL was what inspired PostGIS. It seemed really obvious that we had the makings of an interactive real-time analysis engine, with all this processed data in the database, if we could just do more with the blobs than only stuff them in and pull them out.
Maybe We Should do Spatial Databases?
Reading about spatial databases circa 2000 you would find that:
- There was the Oracle 8i Spatial Data Option (SDO).
- There was an OpenGIS Simple Features for SQL specification (SFSQL).
- There wasn’t much else.
This led to two initiatives on our part, one of which succeeded and the other of which did not.

First, I started exploring whether there was an opportunity in the BC government for a consulting company that had skill with Oracle’s spatial features. BC was actually standardized on Oracle as the official database for all things governmental. But despite working with the local sales rep and looking for places where spatial might be of interest, we came up dry.

The existing big Oracle ministries (Finance, Justice) didn’t do spatial, and the heavily spatial natural resource ministries (Forests, Environment) were still deeply embedded in a “GIS is special” head space, and didn’t see any use for a “spatial database”. This was all probably a good thing, as it turned out.

Our second spatial database initiative was to explore whether any of the spatial models described in the OpenGIS Simple Features for SQL specification were actually practical. In addition to describing the spatial types and functions, the specification described three ways to store the spatial part of a table.
- In a set of side tables (scheme 1a), where each feature was broken down into x’s and y’s stored in rows and columns in a table of numbers.
- In a “binary large object” (BLOB) (scheme 1b).
- In a “geometry type” (scheme 2).
Since the watershed work had given us experience with PostgreSQL, we carried out the testing with that database, examining: could we store spatial data in the database and pull it out efficiently enough to make a database-backed spatial viewer.

For the viewer part of the equation, we ran all the experiments using a Java applet called JShape. I was quite fond of JShape and had built a few little map viewer web pages for clients using it, so hooking it up to a dynamic data source rather than files was a rather exciting prospect.

All the development was done on the trusty Sun Ultra 10 I had taken out a $10,000 loan to purchase when starting up the company. (At the time, we were still making a big chunk of our revenue from programming against the Facet software, which only ran on Sun hardware.)
- The first experiment, shredding the data into side tables, and then re-constituting it for display was very disappointing. It was just too slow to be usable.
- The second experiment, using the PostgreSQL BLOB interface to store the objects, was much faster, but still a little disappointing. And there was no obvious way to add an index to the data.
Breakthrough
At this point we almost stopped: we’d tried all the stuff explained in the user-level documentation for PostgreSQL. But our most sophisticated developer, Dave Blasby, who had actually studied computer science (most of us had mathematics and physics degrees), and was unafraid of low-level languages, looked through the PostgreSQL code and contrib section and said he could probably do a custom type, given some time.

So he took several days and gave it a try. He succeeded!

When Dave had a working prototype, we hooked it up to our little applet and the thing sang. It was wonderfully quick, even when we loaded up quite large tables, zooming around the spatial data and drawing our maps. This is something we’d only seen on fancy XWindows displays on UNIX workstations and now were were doing it in an applet on ordinary PC. It was quite amazing.

We had gotten a lot of very good use out of the PostgreSQL database, but there was no commercial ecosystem for PostgreSQL extensions, so it seemed like the best business use of PostGIS was to put it “out there” as open source and see if it generated some in-bound customer traffic.

At the time, Refractions had perhaps 6 staff (it’s hard to remember precisely) and many of them contributed, both to the initial release and over time.
- Dave Blasby continued polishing the code, adding some extra functions that seemed to make sense.
- Jeff Lounsbury, the only other staffer who could write C, took up the task of a utility to convert Shape files into SQL, to make loading spatial data easier.
- I took on the work of setting up a Makefile for the code, moving it into a CVS repository, writing the documentation, and getting things ready for open sourcing.
- Graeme Leeming and Phil Kayal, my business partners, put up with this apparently non-commercial distraction. Chris Hodgson, an extremely clever developer, must have been busy elsewhere or perhaps had not joined us just yet, but he shows up in later commit logs.
Release
Finally, on May 31, Dave sent out the initial release announcement. It was PostGIS 0.1, and you can still download it, if you like. This first release had a “geometry” type, a spatial index using the PostgreSQL GIST API, and these functions:
- npoints(GEOMETRY)
- nrings(GEOMETRY)
- mem_size(GEOMETRY)
- numb_sub_objs(GEOMETRY)
- summary(GEOMETRY)
- length3d(GEOMETRY)
- length2d(GEOMETRY)
- area2d(GEOMETRY)
- perimeter3d(GEOMETRY)
- perimeter2d(GEOMETRY)
- truly_inside(GEOMETRY, GEOMETRY)
The only analytical function, “truly_inside()” just tested if a point was inside a polygon. (For a history of how PostGIS got many of the other analytical functions it now has, see History of JTS and GEOS on Martin Davis’ blog.)

Reading through those early mailing list posts from 2001, it’s amazing how fast PostGIS integrated into the wider open source geospatial ecosystem. There are posts from Frank Warmerdam of GDAL and Daniel Morissette of MapServer within the first month of release. Developers from the Java GeoTools/GeoServer ecosystem show up early on as well.

There was a huge demand for an open source spatial database, and we just happened to show up at the right time.
Where are they Now?
- Graeme, Phil, Jeff and Chris are still doing geospatial consulting at Refractions Research.
- Dave maintained and improved PostGIS for the first couple years. He left Refractions for other work, but still works in open source geospatial from time to time, mostly in the world of GeoServer and other Java projects.
- I found participating in the growth of PostGIS very exciting, and much of my consulting work… less exciting. In 2008, I left Refractions and learned enough C to join the PostGIS development community as a contributor, which I’ve been doing ever since, currently as a Executive Geospatial Engineer at Crunchy Data.
8:00
Blog 2 Engenheiros: Como criar patches e customizar os símbolos da legenda no QGIS?
sur Planet OSGeo
Uma das áreas do QGIS que mais evoluiu nos últimos anos foi a simbologia, sendo que uma forma que desenvolver novos símbolos é por meio de patches. Assim, nesta postagem iremos mostrar como criá-los para modificar nossas legendas. Confiram!

Nós já sabemos que o QGIS esta sempre se atualizam e melhorando e uma das novas funcionalidades é a personalização dos patches das legendas. Essa funcionalidade esta disponível a partir do QGIS 3.14.

O objetivo de toda legenda é explicar ao leitor o que os diferentes símbolos do mapa representam. Dessa forma, os patches permitem ter formas de legendas mais intuitivas e formatos personalizados, além de incluir mais pontos, linhas e polígonos para representar com melhor precisão o que é visto no mapa.

Para realizar essa atividade nos vamos precisar do QGIS 3.14 em diante, ou seja, caso você tenha instalado em seu computador o QGIS com versão inferior ao QGIS 3.14, esse recurso não poderá ser utilizado.
Como criar Patches
Os patches de uma legenda podem ser gerenciados a partir do gerenciador de estilos do QGIS (QGIS Style Manager). Ao abrir o QGIS, no menu principal você encontrará a opção “Gerenciador de Estilos”, conforme apresentado na figura abaixo.
Gerenciador de Estilos.
Ao abrir o gerenciador, note que inicialmente, você não terá nenhum patch de legenda, pois o QGIS não instala um conjunto padrão.
Abrindo o Gerenciador de Estilos.
Desta forma, você pode importar legendas de patches.
Importando patches existentes
Uma forma de importar as legendas é por meio de patches disponíveis no GitHub (ou outros sites). Lembrando que esses são patches criados por outros membros da comunidade QGIS e disponibilizados gratuitamente para todos.

OBS: Você usará um repositório GitHub online criado pela Kartoza por meio desta URL.

Abrindo a URL você irá encontrar as informações apresentadas na Figura abaixo.
URL GITHUB.
Agora, para esta postagem iremos utilizar o patche “klas-karlsson-patcher.xml”, conforme apresentado na figura abaixo.
escolhendo o patche
Ao clicar na opção mencionada, abrirá a seguinte janela contendo um código apresentado abaixo.
Copiando o código.
Para copiar o código para o QGIS, basta clicar no botão “RAW” e copiar a URL (endereço eletrônico).
Botão Raw.
Após copiar a URL, de volta ao QGIS no Gerenciador de Estilos, no canto inferior clique no botão “Importar/Exportar”.
Escolha a opção Importar/Exportar.
Ao Abrir (conforme figura abaixo), escolha a opção importar.

Note que a janela de importação será aberta (Figura abaixo).
Janela de Importação.
Agora com a opção aberta, defina na opção “Importação de” a opção “Importação por URL” e em seguida insira a URL copiada.
Inserindo a URL.
Em seguida clique na opção “Buscar Itens” e os patches da URL inserida serão incorporados no seu QGIS. Selecione a opção “Adicionar aos Favoritos” e “Não Importar tags incorporadas” e coloque onde esta escrito “Imported”, o nome do arquivo “klas karlsson”, o mesmo nome do arquivo.
URL inserida.
Em seguida, clique em “selecionar tudo” e em seguida em “Importar”.

Ao selecionar a opção “importar”, irá aparecer uma caixa perguntado “Importar shape patch da legenda” , clicar em “Yes to all”.
Clique em Yes to All.
Agora você verá mais de 30 novos patches de legenda para escolher. Isso inclui formas de patch de legenda para camadas de polígono, linha e ponto.
Aplicação de patches de legenda aos itens em uma legenda
Aqui, você aprenderá como aplicar um patch de legenda a um item de legenda no Editor de impressão.

Para realizar este procedimento, feche o gerenciador de estilos e volte ao compositor de impressão.
Exemplo de mapa para inserção do patch.
Agora, selecione a legenda do mapa que será habilitado a opção “Itens da Legenda”, localizada no guia propriedades do item.

Basta clicar duas vezes em uma das camadas/legendas adicionadas e clicar no botão ao lado de formato, em seguida, clique em configurar patch. Nesta opção, irá aparecer os patches adicionados, bastando você selecionar o que você quer colocar na legenda.
Aplicando a camada patch.
Um exemplo da modicação da legenda é apresentado abaixo.
Patch inserido.
Agora, clique no botão azul no topo da guia para voltar e você terá um patch de legenda personalizado aplicado.
Criação de um patch de legenda personalizada a partir de um recurso
Agora iremos um pouco mais longe.

Neste item, descreverei como criar um patch de legenda a partir de um shapefile existente.

É importante frisar que você também pode usar essas etapas para criar um patch de legenda a partir de um recurso digitalizado, apenas com o propósito de criar uma forma de patch de legenda personalizada.

Caso você queira saber mais sobre o formato utilizado para a criação de patches, sugerimos que você dê uma lida na postagem sobre WKT (Well Known Text) do Iporã Possanti.

Agora mãos a massa!

Você irá retornar a tela principal do mapa do QGIS, adicionar um shapefile que você gostaria que tivesse suas formas representadas na legenda. Clique no botão para ‘Alternar edição’ para colocar esta camada no modo de edição e em seguida, selecione a feição que você quer utilizar (caso haja mais de uma no shape) e use a ferramenta “Copiar Recursos” para copiar o shapefile.

Agora você pode sair do modo edição e abrir o gerenciador de estilos.

Em seguida, mude para a aba “Legend Patch Shapes” e em seguida clique no botão verde mais adicionar item e escolha a forma apropriada do shape, isto é, Marcador (Ponto), Linha ou Preenchimento (Polígono) de Legenda.

Note que haverá uma expressão geométrica básica na caixa de texto; exclua este código e clique em CTrl + V para colar a geometria de seu recurso como WKT. A geometria do seu recurso é colada na caixa Forma. Cuidado ao utilizar shapefiles com muitos vértices, isso poderá travar um pouco seu computador.

Agora você precisa editar isso. Todos os atributos de sua camada são incluídos, mas você só precisa da geometria.

Em seguida, role para o topo e exclua tudo antes da linha Multipolígono ou outra função geométrica (Multilinha, Multiponto, Curva composta, etc) dependendo da geometria de seu patch de legenda.

E vá até o final e exclua qualquer coisa após o fechamento
Escolhendo a patche. Fonte: Septima, 2021.
Usando essas etapas, você pode construir sua biblioteca de formas de patch de legenda para atender às suas necessidades cartográficas!

Você também pode usar este fluxo de trabalho com uma tela de mapa vazia e uma camada de rascunho temporária para digitalizar uma forma personalizada para um novo patch de legenda.

E ai gostou da postagem?

Se sim, não deixe de comentar logo abaixo desta postagem.
```
Referências:

GITHUB. QGIS Legend. 2021. Disponível em:< [https:] 
MAPAS ABERTOS. Codificado camadas vetoriais com WKT (Well Known Text). 2021. Disponível em:< [https:] 
QGIS. QGIS Brasil. 2021. Disponível em:< [https:] 
SEPTIMA. QGIS Legend Patches. 2021. Disponível em:< [https:] 
```
The post Como criar patches e customizar os símbolos da legenda no QGIS? first appeared on Blog 2 Engenheiros.
27 May 2021
2:48
Martin Davis: JTS IsSimple gets simpler (and faster)
sur Planet OSGeo
Hard to believe that the JTS Topology Suite is almost 20 years old. That's 140 in dog years! Despite what they say about old dogs, one of the benefits of longevity is that you have the opportunity to learn a trick or two along the way. One of the key lessons learned after the initial release of JTS is that intersection (node) detection is a fundamental part of many spatial algorithms, and critical in terms of performance. This resulted in the development of the noding package to provide an API supporting many different kinds of intersection detection and insertion.
Prior to this, intersection detection was performed as part of the GeometryGraph framework, which combined it with topology graph formation and analysis. At the time this seemed like an elegant way to maximize code reuse across many JTS operations, including overlay, buffering, spatial predicates and validation. But as often the case, there are significant costs to such general-purpose code:
- The overall codebase is substantially more complex
- A performance penalty is imposed on algorithms which don't require topology construction
- Algorithms are harder to read and understand.
- The code is brittle, and so hard to modify
- Porting the code is more difficult
Because of this, a focus of JTS development is to free operations from their dependency on GeometryGraph - with the ultimate goal of expunging it from the JTS codebase. A major step along this road was the rewrite of the overlay operations.
Another operation that relies on GeometryGraph is the IsSimpleOp class, which implements the OGC Simple Features isSimple predicate. The algorithm for isSimple essentially involves determining if the geometry linework contains a self-intersection. GeometryGraph is unnecessarily complex for this particular task, since there is no need to compute the entire topology graph in order to find a single self-intersection. Reworking the code to use the the MCIndexNoder class in the noding API produces a much simpler and more performant implementation. I also took the opportunity to move the code to the operation.valid package, since the operations of isSimple and isValid are somewhat complementary.
Now, isSimple is probably the least-used OGC operation. Its only real use is to test for self-intersections in lines or collections of lines, and that is not a critical issue for many workflows. However, there is one situation where it is quite useful: testing that linear network datasets are "vector-clean" - i.e. contain LineStrings which touch only at their endpoints.
A linear network containing non-simple intersections (isSimple == false)
To demonstrate the performance improvement, I'll use a dataset for Rivers of the US maintained by the US National Weather Service. It supplies two datasets: a full dataset of all rivers, and a subset of major rivers only. You might expect a hydrographic network to be "vector-clean", but in fact both of these datasets contain numerous instances of self-intersections and coincident linework.
Here's the results of running the isSimple predicate on the datasets. On the larger dataset the new implementation provides a 20x performance boost!

Dataset New time Old time

Subset (909,865 pts) 0.25 s 1 s

Full (5,212,102 pts) 2 s 30 s

Finding Non-Simple Locations
The new codebase made it easy to add a functionality enhancement that computes the locations of all places where lines self-intersect. This can be used to for visual confirmation that the operation is working as expected, and to indicate places where data quality needs to be improved. Here's the non-simple intersection points found in the river network subset:
Closeups of some non-simple intersection locations:

IsSimpleOp is the easiest algorithm to convert over from using GeometryGraph. As such it serves as a good proof-of-viability, and establishes useful code patterns for further conversions.
Next up is to give IsValidOp the same treatment. This should provide similar benefits of simplicity and performance. And as always, porting the improved code to GEOS.
26 May 2021
11:00
CARTO Blog: US Broadband Map: Closing the Digital Divide in America
sur Planet OSGeo

During the past year we have all come to rely on our high speed broadband internet connections more than ever as remote home working has become the norm and we consume ever...
25 May 2021
14:12
gvSIG Team: Disponibles las presentaciones de gvSIG en las Jornadas SIG Libre
sur Planet OSGeo

Ya están disponibles los vídeos de las dos presentaciones realizadas por la Asociación gvSIG en las Jornadas de SIG Libre de este año. En ellas se muestra el potencial de gvSIG Online como plataforma de gestión de la información geográfica de un ayuntamiento y, por otro lado, un adelanto de los nuevos desarrollos para disponer de herramientas avanzadas de edición que incluyan mecanismos para optimizar la edición multiusuario.

gvSIG online, Infraestructuras de Datos Espaciales para la gestión municipal

Resumen: gvSIG Online es la solución de la Suite gvSIG para la implantación de Infraestructuras de Datos Espaciales, basada en componentes de software libre como Geoserver, PostGIS y OpenLayers, entre otros. Con un conjunto de herramientas que facilitan enormemente la administración de la información geográfica y la generación de geoportales, su implantación crece día a día y en todo tipo de instituciones. Entre ellas, las administraciones locales.

Durante la ponencia se presentarán las principales herramientas de gvSIG Online aplicadas a la gestión municipal, mostrando diversos casos de éxito de implantación en ayuntamientos o entidades relacionadas con la gestión municipal, de diversas geografías. Se mostrará también la integración con gestores de expedientes y con apps desarrolladas con gvSIG MApps, el framework de desarrollo de apps móviles que se integra con el resto de la Suite gvSIG.

Vídeo: [diobma.udg.edu]

Mantenimiento y gestión avanzada de cartografía con gvSIG Desktop

Resumen: Los últimos desarrollo de gvSIG Desktop han potenciado diversos aspectos de la aplicación, entre ellos la edición avanzada, mediante la incorporación de diversas herramientas que lo acercan cada vez más a las prestaciones que ofrece un CAD para el mantenimiento de cartografía avanzada. Sin embargo, en organizaciones con competencias en edición cartográfica existía un problema no resuelto: disponer de un control de versiones, aplicado al mantenimiento de la información geográfica, que permitiera editar de forma simultanea, generar bloqueos, realizar comprobaciones y validaciones a la hora de consolidar la información y controlar los históricos. Este complejo desarrollo, que lleva a gvSIG Desktop a un nuevo nivel en cuanto a edición profesional, es lo que se presentará en la ponencia propuesta.

Vídeo: [diobma.udg.edu]
9:03
Andrea Antonello: Time to use SMASH, the next generation Geopaparazzi
sur Planet OSGeo
Yes, you read it (and it is not the 1st of April). We are taking Geopaparazzi into unsupported land and declaring SMASH as its successor. We (HydroloGIS) started SMASH with flutter as a test project a couple of years ago to support the IOS world, but it turned out to be the best way to go for a small company as ours is. And, after a while passed fooling ourselves, we had to admit that it doesn't really make sense to support two mobile projects. Much better to channel all energies into a single one.
That said, what does this mean for the Geopaparazzi project and users relying on it:
- HydroloGIS will from now on perform fixes and developments only if funded. This means that we will not continue to add new features and will not make bugfixes on voluntary basis anymore.
- Geopaparazzi users should move to SMASH. More about this later in the post.
- Geopaparazzi is an open source project, you can contribute to it, pay someone (also different from us) to do bugfixes. We will consider pull requests with well documented fixes, so if you are using geopaparazzi for a project that is critical to you, get in touch with us or any other provider to have your issues solved.
What's next. Well, that one is simple. SMASH is next. We started using it for testing purposes and never looked back. SMASH is simpler to use, simpler to develop, simpler to everything. So... overcome your mental friction and try it out.
Most important: SMASH is compatible with geopaparazzi projects and vice versa, so nothing will change in your data evaluation process.
Ok, but what will I miss?
Well, mostly 3 things:
1. the smooth 3D view. That has been something that late geopaparazzi offered. If your main need is 3D (or better 2.5D), then SMASH is not an option for you. But to be honest, since the first moment we added 3D to geopaparazzi, we noticed that it is something that one doesn't need during surveys. So if I could go back, I would probably refrain from adding it anyways.
2. spatialite. That one has been a struggle to keep updated and working also on older versions. It is a powerful engine of which on mobile we just exploited 0.01%. That, plus the fact that geopackage is now used more or less everywhere, supported by the major desktop GIS and simple to implement for any platform, made us completely abandon spatialite for our mobile applications.
3. translations. Those take time. And your involvement.
Hmmm, and what will I gain?
First and foremost: a slick and responsive user interface. And that is one of the important things out in the field. The buttons in the right place, configurable in size, indicators of state and of survey status.
But then there are several features that SMASH supports and geopaparazzi would never have (for a full comparison have a look here):
- IOS suppport. But soon we will also have the first experimental desktop versions. Macos and Linux are already working and windows is on the way.
- way better support for GPS logs. Kalman filter, log profile view with stats markers, diagnostic tool and log statistics in the logs list.
- onscreen logging information.
- GPX are imported as layers and can be styled.
- complete geopackage support. Visualization of tiles and vector data, editing of vector data both alphanumeric and geometric.
- experimental Postgis support. Online editing of vector data both alphanumeric and geometric.
- support for geotiffs and images with world files
- shapefile visualization support (but please do yourself a favor and use geopackage)
- SLD styling. SMASH supports styling of vector data (shapefile, gpx, geopackage, postgis) using simple SLD.
- export project to geopackage. This can help when exporting the survey to GIS.
- centralization with the GSS survey server.
- last but not least: icons on notes and form sections. Who doesn't love icons?!??!?!
Also, SMASH has already attracted external contributions. One example is the redmine support, which is very interesting to enable SMASH for example as a geo-ticketing tool.
Well, that seems quite a lot to me. So if you are still a geopaparazzi user, think of SMASH as the next generation geopaparazzi, because that is the way the future turns out to be. Actually, it is all already here.
A few last comments:
- the geopaparazzi mailinglists will still be active
- all these projects' source codes live under the same umbrella organization
A big thank you to all the people that contributed to geopaparazzi, being it donations, bugfixes, features, custom projects or translations. I really hope you can trust us and move forward with us in the fast growing SMASH project.
24 May 2021
13:49
GeoSolutions: Rilasciato il nuovo plugin RNDT per GeoNetwork 3.10
sur Planet OSGeo

You must be logged into the site to view this content.
2:00
GeoServer Team: GeoServer 2.19.1 Released
sur Planet OSGeo
We are happy to announce GeoServer 2.19.1 release is available for download (zip and war) along with docs and extensions.

This GeoServer 2.19.1 release was produced in conjunction with GeoTools 25.1 and GeoWebCache 1.19.1. this is a stable release recommended for production systems.

Thanks to everyone who contributed, and to Jody Garnett (GeoCat) for making this release.
Improvements and Fixes
Several new features are included in this release:
- GetFeatureInfo can now includes ColorMap labels for the location clicked, check out the tutorial.
- A new styling vendor option inclusion to control control legend generation for WMS GetLegendGraphic using values of legendOnly, mapOnly, or normal to define how a style element is used.
Notable improvements:
- Improve parameter extractor logging
- Customization of complex GeoJSON WFS output is now available for other data stores, previously this was restricted attributes marked @dataType by the AppSchema plugin.
- SLD Service now places a limit, configured by system variable ``-Dorg.geoserver.sldService.maxUniqueRange=1024`, of the number of unique intervals.
Fixes included in this release:
- Fix elevation key-value-pair parser (used in WMS GetMap) handling of edge cases such as zero intervals
- Fix importer application of gridset bounds, (ot was not working correctly when GWC DiskQuote in use)
- Inspire schemas URL updated to their new [HTTPS] location
- WCS 2.0 slicing on lat/long fix, was sometimes returning adjacent pixel
- WMS Layers with dimensions were missing from GetCapabilities when using catalog security challenge mode.
- App Schema download was missing a required jar.
- Improvements helping coverage format compatibility with file references
- Address GeoFence interaction with non global named tree container
- Address WPS Download animation out of memory issues
- Address rendering process regression with use of vendor option sortByGroup resulting in “internal error rendering process failed”
Internal:
- Upgrade to commons-io 2.8.0
- Autoformat maven pom.xml files
For details check the 2.9.1 release notes.
About GeoServer 2.19
Additional information on GeoServer 2.19 series:
Release notes ( 2.19.1 | 2.19.0 | 2.19-RC )
2:00
Veronica Andreo: Outcomes of an online GRASS GIS course
sur Planet OSGeo
In March 2021, I taught a GRASS GIS online workshop as part of the distance learning offer of Gulich Institute (CONAE - UNC) in Argentina. We had a total of 65 students from different countries in South America.

During the workshop, we studied different topics within GRASS ecosystem, but we mostly covered remote sensing, Object Based Image Analysis (OBIA) and time series analysis, making use of GRASS GIS extensions to obtain and process Landsat, Sentinel and MODIS data. All the workshop materials, including presentations, code, and data, are available here (in Spanish).

As final assignment to pass the course and get their certificate, students were given two options:
- write a report in Spanish for which they should pick a topic of interest, find relevant data and use GRASS modules to obtain results or,
- write a tutorial in English of a topic relevant for them or even something new they wanted to learn, always with GRASS as main tool/focus.
As an incentive, the best reports and tutorials would be given the chance to be presented live through Gulich Institute Youtube channel. Tutorials, because of the extra difficulty of language, would also be highlighted in GRASS GIS website and social media (See the news here).

The topics chosen by the students were diverse and really interesting: from changes in snow cover in southern Argentina, to productivity of high altitude grasslands, wildfire simulations, segmentation to aid digitizing of implanted forests, network analysis, comparison of classification approaches to map urban areas, landscape characterization, urban heat islands, spatial and temporal gap-filling and species identification through OBIA and machine learning.

On May 14, those reports and tutorials that resulted selected were presented live with an audience of almost 90 people. It was really satisfying to witness the student’s learning process and outcome. Many of them overcame installation difficulties, learnt and studied new modules, searched for data, explored different solutions. Some, even moved to Linux and learnt to use Git/GitHub. Have a look ?

With this post I would like to encourage others to follow such an approach that resulted rewarding in many aspects. For students to get their work showcased, for their families to see aunt/uncle, mum or dad on the screen (we had some very sweet messages in the online chat ?), and also for us as teachers/trainers. Furthermore, I believe these events bring science, higher education and technology closer to the general public and… we never know who might be inspired by our work! ?
21 May 2021
2:00
PostGIS Development: PostGIS 3.1.2
sur Planet OSGeo
The PostGIS Team is pleased to release the release of PostGIS 3.1.2!

This release is a bug fix release, addressing issues found in the previous 3.1 release.
- #4871, TopoGeometry::geometry cast returns NULL for empty TopoGeometry objects (Sandro Santilli)
- #4826, postgistigergeocoder Better answers when no zip is provided (Regina Obe)
- #4817, handle more complex compound coordinate dystems (Paul Ramsey)
- #4842, Only do axis flips on CRS that have a “Lat” as the first column (Paul Ramsey)
- Support recent Proj versions that have removed pjgetrelease (Paul Ramsey)
- #4835, Adjust tolerance for geodetic calculations (Paul Ramsey)
- #4840, Improper conversion of negative geographic azimuth to positive (Paul Ramsey)
- #4853, DBSCAN cluster not formed when recordset length equal to minPoints (Dan Baston)
- #4863, Update bboxes after scale/affine coordinate changes (Paul Ramsey)
- #4876, Fix raster issues related to PostgreSQL 14 tablefunc changes (Paul Ramsey, Regina Obe)
- #4877, mingw64 PostGIS / PostgreSQL 14 compile (Regina Obe, Tom Lane)
- #4838, Update to support Tiger 2020 (Regina Obe)
- #4890, Change Proj cache lifetime to last as long as connection (Paul Ramsey)
- #4845, Add Pg14 build support (Paul Ramsey)
Continue Reading by clicking title hyperlink ..
18 May 2021
15:17
gvSIG Team: Disponible grabación de las Jornadas “Uso de las Tecnologías Libres de Información Geográficas en Educación Básica – experiencias iberoamericanas” 2021
sur Planet OSGeo

Ya están disponibles las grabaciones de las distintas presentaciones realizadas en las Jornadas “Uso de las Tecnologías Libres de Información Geográficas en Educación Básica – experiencias iberoamericanas”, que se celebraron de forma online los días 12 y 13de mayo de 2021.

Estas jornadas, organizadas por la Red CYTED GeoLIBERO, han servido de excelente ejemplo para conocer experiencias de uso de la geomática libre en el sector educativo preuniversitario, y también para debatir a través de la mesa redonda «Oportunidades y desafíos de las TIGs libres como herramientas de enseñanza pre-universitaria».

Sin más os dejamos con la playlist de Youtube de las Jornadas: [https:]
11:00
CARTO Blog: Healthcare Analytics: How Boston uses Location Intelligence
sur Planet OSGeo

The Vital Village Network began in the winter of 2010 when an interdisciplinary group of practitioners at Boston Medical Center, New England’s largest safety net hospital, ...
17 May 2021
14:04
gvSIG Team: Nàquera Spatial Data Infrastructure on gvSIG technology
sur Planet OSGeo

The Nàquera municipality has launched its Spatial Data Infrastructure, based on gvSIG Online technology, the gvSIG Suite solution for SDIs.

As first public geoportal, which can now be consulted, an urban planning map viewer has been generated, in which it is possible to access different town-planning information of the municipality, partial plans, sector regulations (livestock roads, Sierra Calderona Natural Park, …), cadastre.

In this way, the Nàquera City Council joins the increasingly numerous group of local administrations that are committed to the gvSIG Online solution for the management of their geographic information. A bet based on the use of open source and standard technologies.
13:36
gvSIG Team: Infraestructura de Datos Espaciales de Nàquera con tecnología gvSIG
sur Planet OSGeo

El Ayuntamiento de Nàquera ha puesto en marcha su Infraestructura de Datos Espaciales, basada en la tecnología gvSIG Online, la solución de la Suite gvSIG para IDEs.

Como primer geoportal público, ya consultable, se ha generado un visor de mapas de urbanismo, en el que se puede acceder a distintas información urbanística del municipio, planes parciales, normativa sectorial (vías pecuarias, Parque Natural Sierra Calderona,… ), catastro.

De este modo, el Ayuntamiento de Nàquera se suma al cada vez más numeroso conjunto de administraciones locales que apuestan por la solución gvSIG Online para la gestión de su información geográfica. Una apuesta basada en el uso de tecnologías libres y estándares.
11:00
CARTO Blog: CARTO selected by AI4Cities to accelerate City Sustainability
sur Planet OSGeo

82% of all greenhouse gas emissions in European cities are a consequence of mobility and energy. In order to reduce CO2 emissions, meet their climate commitments, and accel...
14 May 2021
9:07
gvSIG Team: The Municipality of Durazno puts faith in gvSIG for its Spatial Data Infrastructure
sur Planet OSGeo

The Durazno Departmental Administration, which manages one of the nineteen departments that make up the Eastern Republic of Uruguay, has launched its Spatial Data Infrastructure, putting faith in gvSIG Online as the technological base for the management of all its geographic information.

The SDI portal is accessible here: [https:]]

Besides private geoportals that may be operational, you can already access several public geoportals, allowing you to consult considerable information, such as the following:

[https:]]

…where we can even access information on pavement and lighting taxes, health, urban development and environment.

From the gvSIG Association we congratulate the Municipality of Durazno for putting faith in open source software to modernize and optimize its territory management. An example that we hope will be replicated in other municipalities.
12 May 2021
11:00
CARTO Blog: CARTO at Snowflake Summit 2021
sur Planet OSGeo

We are excited to share the details on our participation as Petabyte sponsors of this year’s Snowflake Summit, taking place on 8-10 June. As you will have noticed over the ...
11 May 2021
17:45
gvSIG Team: La Intendencia de Durazno apuesta por gvSIG para su Infraestructura de Datos Espaciales
sur Planet OSGeo

La Intendencia Departamental de Durazno, que gestiona uno de los diecinueve departamentos que componen la República Oriental del Uruguay ha puesto en marcha su Infraestructura de Datos Espaciales, apostando por gvSIG Online como base tecnológica para la gestión de toda su información geográfica.

El portal de entrada a la IDE está accesible aquí: [https:]]

Además de geoportales privados que puedan estar operativos, ya se puede acceder a varios geoportales públicos, permitiendo consultar con considerable información, como el siguiente:

[https:]]

… donde podemos incluso acceder a información de tasas de pavimento y alumbrado, salubridad, desarrollo urbanístico y medio ambiente.

Desde la Asociación gvSIG damos la enhorabuena a la Intendencia de Durazno por apostar por el software libre para modernizar y optimizar su gestión del territorio. Un ejemplo que esperemos que se replique en otras intendencias.
17:17
GeoSolutions: Free Webinar – A DevOps perspective on GeoServer: Deployment planning guidelines
sur Planet OSGeo

You must be logged into the site to view this content.
7:00
Lutra consulting: How Mergin/Input sync changes in your QGIS projects
sur Planet OSGeo
People often ask whether the Mergin service and the Input app can deal with multiple team members doing edits at the same time.

They happily find out that the answer is yes - it is one of the core features that greatly simplifies life of our users. In this post we will shed some light on how things work behind the scenes.

Getting started
Let’s think of a simple project directory that needs to be synchronised between multiple desktop or mobile users, containing just two files:
- a QGIS project file my-project.qgz that sets up map layers, styling, …
- a GeoPackage file my-data.gpkg containing all GIS data
Our sample GIS data will contain a tree survey table, containing location, species and age of various trees:

When users edit data in my-data.gpkg, the traditional cloud storage solutions (such as Dropbox, Google Drive, Microsoft OneDrive and others) simply copy the modified files there. They do not understand the file content though - so if two people modify the same file, they have no way of knowing how to merge changes together. In the worse case, when two versions of the same file are uploaded, they keep just the version which was synchronised last. Or slightly better, they resort to creation of conflicting copies which need to be manually merged later. As one can imagine, merging and consolidating modifications from multiple GeoPackages back to one copy is a slow, tedious and error-prone job.

the Mergin service has been designed to understand spatial data, especially GeoPackages that are becoming the most popular format to store vector & attribute data. This is thanks to the open source geodiff library that we have developed while working on Mergin.
Synchronising data using “diffs”
The first trick is that synchronisation of GeoPackage files between Mergin server and clients (Input app, QGIS or other apps) only transfers actual changes in tables (“diffs” in technical jargon).

Our Mergin project with the tree survey has been prepared and downloaded by users. Jack did a field survey and he added or updated some rows in the survey table (changes highlighted in yellow and green):

After pressing sync button, his changes are detected and uploaded to Mergin, encoded as a list of changes to the survey table:

Another user, Jill, also downloaded the tree survey project to her mobile device prior to Jack’s changes. When Jill synchronises the project to get the latest version, the changes as uploaded by Jack are downloaded and applied to her local copy of the project, getting the same data as seen by Jack.

At this point, the advantage of uploading/download only changes in tables may not seem obvious besides saving some network bandwidth… Read on to learn how this is used to support multi-user editing.
Merging changes from multiple users
So far we have expected that Jill does not have any pending changes to sync, so that was easy. Now let’s assume that Jill has also done some changes on her device:

Here comes the more tricky part - how do we merge changes from Jack and Jill back to a single table:

In Mergin, cases that require merging changes from multiple users are handled by the “rebase” operation, a concept we have borrowed from version control systems for source code.

Let’s assume that Jack has synchronised his changes first. Later, when Jill synchronises her changes, a couple of things happen on her device before uploading the changes: Jill’s changes will be temporarily undone, Jack’s changes get applied, and finally Jill’s changes are re-applied after being rebased on top of Jack’s changes.

What does it mean to rebase someone’s changes? There are a couple of possible edit conflicts that could happen between rows of a database table with matching IDs (insert/insert, update/delete, delete/delete, update/update). These edit conflicts need to be resolved in order to be able to merge changes from multiple users.

In our example, both Jack and Jill have added a row with ID = 4. This is not allowed, and therefore Jill’s new row ID will get changed to ID = 5 (any unused ID would do). As a result, here’s how the merged table will look at the end - combining changes of both users:

If both Jack and Jill modified the same row (the update/update edit conflict), we can only accept one edit automatically. The conflicting edit of the other user is written to a special conflict file and uploaded to Mergin, so no data gets lost, and the conflict can be later inspected by the project admin. Fortunately, this kind of conflict does not happen often if the survey work is well planned to avoid users simultaneously modifying the same features within the GeoPackage data.
What if conflict files appear
There are some cases when automatic merging is not supported. In those cases, Mergin is unable to find out details about changes in the data file(s) and has to resort to creation of a conflicting copy which gets uploaded to Mergin project along the original data file(s). In particular the problems may appear when:
- Other format than GeoPackage is used for data storage (e.g. shapefiles)
- Database or table structure is changed (e.g. adding new columns or new tables)
In the future, these limitation may be removed, but at this point it is good to keep them in mind.

If you plan to change structure of the survey tables and the project is already being used on multiple devices, it may be a good idea to create a new Mergin project with the modified database structure and instruct users to switch to the new project. Otherwise conflict files may start popping up as long as some users have older version of the project, adding more manual work to collate data.
You may also like... Input, a field data collection app based on QGIS. Input makes field work easy with its simple interface and cloud-based sync. Available on Android and iOS.
7:00
Lutra consulting: How Mergin/Input sync changes in your QGIS projects
sur Planet OSGeo
People often ask whether the Mergin service and the Input app can deal with multiple team members doing edits at the same time.

They happily find out that the answer is yes - it is one of the core features that greatly simplifies life of our users. In this post we will shed some light on how things work behind the scenes.

Getting started
Let’s think of a simple project directory that needs to be synchronised between multiple desktop or mobile users, containing just two files:
- a QGIS project file my-project.qgz that sets up map layers, styling, …
- a GeoPackage file my-data.gpkg containing all GIS data
Our sample GIS data will contain a tree survey table, containing location, species and age of various trees:

When users edit data in my-data.gpkg, the traditional cloud storage solutions (such as Dropbox, Google Drive, Microsoft OneDrive and others) simply copy the modified files there. They do not understand the file content though - so if two people modify the same file, they have no way of knowing how to merge changes together. In the worse case, when two versions of the same file are uploaded, they keep just the version which was synchronised last. Or slightly better, they resort to creation of conflicting copies which need to be manually merged later. As one can imagine, merging and consolidating modifications from multiple GeoPackages back to one copy is a slow, tedious and error-prone job.

the Mergin service has been designed to understand spatial data, especially GeoPackages that are becoming the most popular format to store vector & attribute data. This is thanks to the open source geodiff library that we have developed while working on Mergin.
Synchronising data using “diffs”
The first trick is that synchronisation of GeoPackage files between Mergin server and clients (Input app, QGIS or other apps) only transfers actual changes in tables (“diffs” in technical jargon).

Our Mergin project with the tree survey has been prepared and downloaded by users. Jack did a field survey and he added or updated some rows in the survey table (changes highlighted in yellow and green):

After pressing sync button, his changes are detected and uploaded to Mergin, encoded as a list of changes to the survey table:

Another user, Jill, also downloaded the tree survey project to her mobile device prior to Jack’s changes. When Jill synchronises the project to get the latest version, the changes as uploaded by Jack are downloaded and applied to her local copy of the project, getting the same data as seen by Jack.

At this point, the advantage of uploading/download only changes in tables may not seem obvious besides saving some network bandwidth… Read on to learn how this is used to support multi-user editing.
Merging changes from multiple users
So far we have expected that Jill does not have any pending changes to sync, so that was easy. Now let’s assume that Jill has also done some changes on her device:

Here comes the more tricky part - how do we merge changes from Jack and Jill back to a single table:

In Mergin, cases that require merging changes from multiple users are handled by the “rebase” operation, a concept we have borrowed from version control systems for source code.

Let’s assume that Jack has synchronised his changes first. Later, when Jill synchronises her changes, a couple of things happen on her device before uploading the changes: Jill’s changes will be temporarily undone, Jack’s changes get applied, and finally Jill’s changes are re-applied after being rebased on top of Jack’s changes.

What does it mean to rebase someone’s changes? There are a couple of possible edit conflicts that could happen between rows of a database table with matching IDs (insert/insert, update/delete, delete/delete, update/update). These edit conflicts need to be resolved in order to be able to merge changes from multiple users.

In our example, both Jack and Jill have added a row with ID = 4. This is not allowed, and therefore Jill’s new row ID will get changed to ID = 5 (any unused ID would do). As a result, here’s how the merged table will look at the end - combining changes of both users:

If both Jack and Jill modified the same row (the update/update edit conflict), we can only accept one edit automatically. The conflicting edit of the other user is written to a special conflict file and uploaded to Mergin, so no data gets lost, and the conflict can be later inspected by the project admin. Fortunately, this kind of conflict does not happen often if the survey work is well planned to avoid users simultaneously modifying the same features within the GeoPackage data.
What if conflict files appear
There are some cases when automatic merging is not supported. In those cases, Mergin is unable to find out details about changes in the data file(s) and has to resort to creation of a conflicting copy which gets uploaded to Mergin project along the original data file(s). In particular the problems may appear when:
- Other format than GeoPackage is used for data storage (e.g. shapefiles)
- Database or table structure is changed (e.g. adding new columns or new tables)
In the future, these limitation may be removed, but at this point it is good to keep them in mind.

If you plan to change structure of the survey tables and the project is already being used on multiple devices, it may be a good idea to create a new Mergin project with the modified database structure and instruct users to switch to the new project. Otherwise conflict files may start popping up as long as some users have older version of the project, adding more manual work to collate data.
You may also like... Input, a field data collection app based on QGIS. Input makes field work easy with its simple interface and cloud-based sync. Available on Android and iOS.
10 May 2021
17:08
OTB Team: OTB release 7.3.0 is available
sur Planet OSGeo

We are happy to announce that OTB version 7.3.0 has been released! Ready to use binary packages are available on the package page of the website: OTB-7.3.0-Darwin64.run (Mac OS) OTB-7.3.0-Linux64.run (Linux) OTB-7.3.0-Win32.zip (Windows 32 bits) OTB-7.3.0-Win64.zip (Windows 64 bits) It is also possible to checkout the branch with git: The documentation for OTB 7.3.0 can […]
06 May 2021
10:00
Paul Ramsey: MapScaping Podcast - GDAL
sur Planet OSGeo
Yesterday I talked about all-things-GDAL (or at least all the things that fit in 30 minutes) with MapScaping Podcast’s Daniel O’Donohue.
In the same way that Linux is the under-appreciated substrate of modern computing, GDAL is the under-appreciated substrate of modern geospatial data management. If the compute is running in the cloud, it’s probably running on Linux; if the geospatial data are flowing through the cloud, they’re probably flowing through GDAL.

At the same time as it has risen to being the number one spatial data processing tool in the world (by volume anyways), GDAL has maintained an economic support model from the last century. One maintainer (currently Even Rouault), earning a living with new feature development, and doing all the work of code quality, integration, testing, documentation, and promotion as a loss leader. This model burns out maintainers, and it doesn’t ask the organizations that gain the most value from GDAL (the ones pushing terrabytes of pixels through the cloud) to contribute commensurate with the value they receive.

With the new GDAL sponsor model, the organizations who receive the most value are stepping up to do their share. If your organization uses GDAL, and especially if it uses it in volume, consider joining the other sponsors in making sure GDAL remains high quality and cutting edge by sponsoring.

Thanks Daniel, for having me on!
05 May 2021
11:00
CARTO Blog: OGC appoints Javier de la Torre to its Board of Directors
sur Planet OSGeo

We are very pleased to announce the appointment of Javier de la Torre, Founder and Chief Product Officer of CARTO, to The Open Geospatial Consortium’s (OGC) Board of Direct...
11:00
CARTO Blog: Real Estate Analytics: The Working from Home Effect
sur Planet OSGeo

Many things have changed in our day to day lives since the start of the pandemic, and industries such as retail, tourism, and real estate are forced to navigate through a c...
10:24
gvSIG Team: Jornadas “Uso de las Tecnologías Libres de Información Geográficas en Educación Básica – experiencias iberoamericanas”
sur Planet OSGeo

No os perdáis las próximas jornadas organizadas por la red de investigación GeoLIBERO: “Uso de las Tecnologías Libres de Información Geográficas en Educación Básica – experiencias iberoamericanas“, días 12 y 13 de mayo de 2021.
En ellas se van a contar distintas experiencias del maravilloso proyecto, denominado gvSIG Batoví, con el que han llevado los SIG en software libre a las aulas. De verdad, vale mucho la pena ver lo que han conseguido. Para estas jornadas se ha conseguido reunir a distintos equipos que durante estos años han participado en el proyecto gvSIG Batoví (más de uno dejó la educación básica atrás).
El programa, pudiendo inscribiros a las charlas a las que queráis asistir, lo podéis consultar aquí:
http://www.gvsig.com/es/eventos/tec-libres-ig-iberoamericanas-2021/programa
04 May 2021
11:00
CARTO Blog: Using Route Optimization & IoT Data in Waste Management
sur Planet OSGeo

In Portland, Oregan, the city picked up more waste in 2020 than any other year on record: 3,000 tons, 50% more than the previous year. As a result of the pandemic, more peo...
10:00
Paul Ramsey: Spatial Indexes and Bad Queries
sur Planet OSGeo
So, this happened:

Basically a GeoDjango user posted some workarounds to some poor performance in spatial queries, and the original query was truly awful and the workaround not a lot better, so I snarked, and the GeoDjango maintainer reacted in kind.

Sometimes a guy just wants to be a prick on the internet, you know? But still, I did raise the red flag of snarkiness, so it it seems right and proper to pay the fine.

I come to this not knowing entirely the contract GeoDjango has with its users in terms of “hiding the scary stuff”, but I will assume for these purposes that:
- Data can be in any coordinate system.
- Data can use geometry or geography column types.
- The system has freedom to create indexes as necessary.
So the system has to cover up a lot of variability in inputs to hide the scary stuff.

We’ll assume a table name of the_table a geometry column name of geom and a geography column name of geog.
Searching Geography
This is the easiest, since geography queries conform to the kind of patterns new users expect: the coordinates are in lon/lat but the distances are provided/returned in metres.

Hopefully the column has been spatially indexed? You can check in the system tables.
```
SELECT * 
FROM pg_indexes 
WHERE tablename = 'the_table';
```
Yes, there are more exact ways to query the system tables for this information, I give the simple example for space reasons.

If it has not been indexed, you can make a geography index like this:
```
CREATE INDEX the_table_geog_x 
  ON the_table
  USING GIST (geog);
```
And then a “buffered” query, that finds all objects within a radius of an input geometry (any geometry, though only a point is shown here) looks like this.
```
SELECT *
FROM the_table
WHERE ST_DWithin(
    the_table.geog,
    ST_SetSRID(ST_MakePoint(%lon, %lat), 4326),
    %radius
    );
```
Note that there is no “buffering” going on here! A radius search is logically equivalent and does not pay the cost of building up buffers, which is an expensive operation.

Also note that, logically, ST_DWithin(A, B, R) is the same as ST_Distance(A, B) < R, but in execution the former can leverage a spatial index (if there is one) while the latter cannot.
Indexable Functions
Since I mention that ST_DWithin() is indexable, I should list all the functions that can make use of a spatial index:
And for a bonus there are also a few operators that access spatial indexes.
- geom_a && geom_b returns true if the bounding box of geom_a intersects the bounding box of geom_b in 2D space.
- geom_a &&& geom_b returns true if the bounding box of geom_a intersects the bounding box of geom_b in ND space (an ND index is required for this to be index assisted),
Searching Planar Geometry
If the data are planar, then spatial searching should be relatively easy, even if the input geometry is not in the same coordinate system.

First, is your data planar? Here’s a quick-and-dirty query that returns true for geographic data and false for planar.
```
SELECT srs.srtext ~ '^GEOGCS' 
FROM spatial_ref_sys srs
JOIN geometry_columns gc
ON srs.srid = gc.srid
WHERE gc.f_table_name = 'the_table'
```
Again, do you have a spatial index on your geometry column? Check!
```
CREATE INDEX the_table_geom_x 
  ON the_table
  USING GIST (geom);
```
Now, assuming query coordinates in the same planar projection as the data, a fast query will look like this:
```
SELECT *
FROM the_table
WHERE ST_DWithin(
    geom,
    ST_SetSRID(ST_MakePoint(%x, %y), %srid)
    %radius
    );
```
But what if users are feeding in queries in geographic coordinates? No problem, just convert them to planar before querying:
```
SELECT *
FROM the_table
WHERE ST_DWithin(
    geom,
    ST_Transform(
        ST_SetSRID(ST_MakePoint(%lon, %lat), 4326), 
        %srid)
    %radius
    );
```
Note that here we are transforming the geography query to planar, not transforming the planar column to geographic!

Why? There’s only one query object, and there’s potentially 1000s of rows of table data. And also, the spatial index has been built on the planar data: it cannot assist the query unless the query is in the same projection.
Searching Lon/Lat Geometry
This is the hard one. It is quite common for users to load geographic data into the “geometry” column type. So the database understands them as planar (that’s what the geometry column type is for!) while their units (longitude and latitude) are in fact angular.

There are benefits to staying in the geometry column type:
- There are far more functions native to geometry, so you can avoid a lot of casting.
- If you are mostly working with planar queries you can get better performance from 2D functions.
However, there’s a huge downside: questions that expect metric answers or metric parameters can’t be answered. ST_Distance() between two geometry objects with lon/lat coordinates will return an answer in… “degrees”? Not really an answer that makes any sense, as cartesian math on anglar coordinates returns garbage.

So, how to get around this conundrum? First, the system has to recognize the conundrum!
- Is the column type “geometry”?
- Is the SRID a long/lat coordinate system? (See test query above.)
Both yes? Ok, this is what we do.

First, create a functional index on the geography version of the geometry data. (Since you’re here, make a standard geometry index too, for other purposes.)
```
CREATE INDEX the_table_geom_geog_x
ON the_table
USING GIST (geography(geom));

CREATE INDEX the_table_geom
ON the_table
USING GIST (geom);
```
Now we have an index that understands geographic coordinates!

All we need now is a way to query the table that uses that index efficiently. The key with functional indexes is to ensure the function you used in the index shows up in your query.
```
SELECT * 
FROM the_table
WHERE ST_DWithin(
    geography(geom),
    geography(ST_SetSRID(ST_MakePoint(%lon, %lat), 4326))
    %radius
    );
```
What’s going on here? By using the “geography” version of ST_DWithin() (where both spatial arguments are of type “geography”) I get a search in geography space, and because I have created a functional index on the geography version of the “geom” column, I get it fully indexed.
Random Notes
- The user blog post asserts incorrectly that their best performing query is much faster because it is “using the spatial index”.
```
SELECT 
    "core_searchcriteria"."id", 
    "core_searchcriteria"."geo_location"::bytea,
     "core_searchcriteria"."distance",
     ST_DistanceSphere(
        "core_searchcriteria"."geo_location", 
        ST_GeomFromEWKB('01010000 \3462000000000000000@U@000000000000@@'::bytea)) AS "ds" 
     FROM "core_searchcriteria" 
        WHERE ST_DistanceSphere(
            "core_searchcriteria"."geo_location", 
            ST_GeomFromEWKB('01010000 \3462000000000000000@U@000000000000@@'::bytea)
        ) <= "core_searchcriteria"."distance";
```
- However, the WHERE clause is just not using any of the spatially indexable functions. Any observed speed-up is just because it’s less brutally ineffecient than the other queries.
- Why was the original brutally inefficient?
```
SELECT 
    "core_searchcriteria"."id", 
    "core_searchcriteria"."geo_location"::bytea, 
    "core_searchcriteria"."distance", 
    ST_Buffer(
        CAST("core_searchcriteria"."geo_location" AS geography(POINT,4326)), "core_searchcriteria"."distance"
        )::bytea AS "buff" FROM "core_searchcriteria" 
    WHERE ST_Intersects(
        ST_Buffer(
            CAST("core_searchcriteria"."geo_location" AS geography(POINT,4326)), "core_searchcriteria"."distance"), 
        ST_GeomFromEWKB('01010000 \3462000000000000000@U@000000000000@@'::bytea)
    )
```
- The WHERE clause converts the entire contents of the data column to geography and then buffers every single object in the system.
- It then compares all those buffered objects to the query object (what, no index? no).
- Since the column objects have all been buffered… any spatial index that might have been built on the objects is unusable. The index is on the originals, not on the buffered objects.
7:27
Martin Davis: Fixing Invalid Geometry with JTS
sur Planet OSGeo
TLDR: JTS can now fix invalid geometry!
The JTS Topology Suite implements the Geometry model defined in the OGC Simple Features specification. An important part of the specification is the definition of what constitutes valid geometry. These are defined by rules about the structural and geometric characteristics of geometry objects. Some validity rules apply to all geometry; e.g. vertices must be defined by coordinates with finite numeric values (so that NaN and Inf ordinates are not valid). In addition, each geometric subtype (Point, LineString, LinearRing, Polygon, and Multi-geometry collections) has its own specific rules for validity.
The rules for Polygons and MultiPolygons are by far the most restrictive. They include the following constraints:
1. Polygons rings must not self-intersect
2. Rings may touch at only a finite number of points, and must not cross
3. A Polygon interior must be connected (i.e. holes must not split a polygon into two parts)
4. MultiPolygon elements may touch at only a finite number of points, and must not overlap
These rules guarantee that:
- a given area is represented unambiguously by a polygonal geometry
- algorithms operating on polygonal geometry can make assumptions which provide simpler implementation and more efficient processing
Valid polygonal geometry is well-behaved
Given the highly-constrained definition of polygonal validity, it is not uncommon that real-world datasets contain polygons which do not satisfy all the rules, and hence are invalid. This occurs for various reasons:
- Data is captured using tools which do not check validity, or which use a looser or different definition than the OGC standard
- Data is imported from systems with different polygonal models
- Data is erroneous or inaccurate
Because of this, JTS does not enforce validity on geometry creation, apart from a few simple structural constraints (such as rings having identical first and last points). This allows invalid geometry to be represented as JTS geometry objects, and processed using JTS code. Some kinds of spatial algorithms can execute correctly on invalid geometry (e.g. determining the convex hull). But most algorithms require valid input in order to ensure correct results (e.g. the spatial predicates) or to avoid throwing exceptions (e.g. overlay operations). So the main reason for representing invalid geometry is to allow validity to be tested, to take appropriate action on failure.
Often users would like "appropriate action" to be Just Make It Work. This requires converting invalid geometry to be valid. Many spatial systems provide a way to do this:
- PostGIS has the ST_MakeValid function (which is backed by an implementation in GEOS)
- QGIS has a Fix Geometries process.
- OpenJUMP has MakeValidOp
- The ESRI Java Geometry API has an operation called (confusingly) makeSimple.
But this has a been a conspicuous gap in the JTS API. While it is possible to test for validity, there has never been a way to fix an invalid geometry. To be fair, JTS has always had an unofficial way to make polygonal geometry valid. This is the well-known trick of computing geometry.buffer(0), which creates a valid output which often is a good match to the input. This has worked as a stop-gap for years (in spite of an issue which caused some problems, now fixed - see the post Fixing Buffer for fixing Polygons). However, using buffer(0) on self-intersecting "figure-8" polygons produces a "lossy" result. Specifically, it retains only the largest lobes of the input linework. This is undesirable for some uses (although it is advantageous in other situations, such as trimming off small self-intersections after polygon simplification).
Buffer(0) of Figure-8 is lossy
So, it's about time that JTS stepped up to provide a supported, guaranteed way of fixing invalid geometry. This should handle all geometry, although polygonal geometry repair is the most critical requirement.
This raises the question of what exactly the semantics of repairing polygons should be. While validity is well-specified, there are no limits to the complexity of invalid polygons, and a variety of possible approaches to fixing them. The most significant decision is how to determine the interior and exterior of a polygonal geometry with self-intersections or overlaps. (This is the classic "bow-tie" or "figure-8" - although self-intersecting polygons can be far more complex.) The question comes down to whether the geometry linework or structure is used to determine interior areas.
If linework is used to create validity, to node the constituent linework to form a topologically-valid coverage. This coverage is then scanned with an alternating even-odd strategy to assign areas as interior or exterior. This may result in adjacent interior or exterior areas, in which case these are merged.
Alternatively, the structure of the polygonal geometry can be taken as determinative. The shell and hole rings are assumed to accurately specify the nature of the area they enclose (interior or exterior). Likewise, the (potentially overlapping or adjacent) elements of a MultiPolygon are assumed to enclose interior area. The repair operation processes each ring and polygon separately. Holes are subtracted from shells. Finally, if required the repaired polygons are unioned to form the valid result.
PostGIS MakeValid and the ESRI Java Geometry API makeSimple both use the linework approach. However, for some relatively simple invalid geometries this produces results which seem overly complex.  Complex output from ST_MakeValid
For this reason I have implemented the structure-based approach in JTS. It provides results that are closer to the existing buffer(0) technique (and conveniently allows using the existing buffer code). This made it a relatively simple matter to implement the repair algorithm as the GeometryFixer class.
Here's some examples of how GeometryFixer works. First, the example above, showing the (arguably) simpler result that arises from using the structure information:Figure-8s are handled as desired (keeping all area):
Self-overlapping shells have all interior area preserved:Of course, the GeometryFixer also handles simple fixes for all geometry types, such as removing invalid coordinates.
One further design decision is how to handle geometries which are invalid due to collapse (e.g. a line with a single point, or a ring which has only two unique vertices). GeometryFixer provides an option to either remove collapses, or to return them as equivalent lower dimensional geometry.
To see the full range of effects of GeometryFixer, the JTS TestBuilder can be used to view and run the GeometryFixer on the set of 75 test cases for invalid polygonal geometry in the file TestInvalidA.xml.
It's been a long time coming, but finally JTS can function as a full-service repair shop for geometry, no matter how mangled it might be.
29 April 2021
21:59
XYCarto: Static Vector Tiles II: Openlayers with Custom Projection
sur Planet OSGeo
Building off the work from my previous post on vector tiles, I wanted to develop a second process for use in Openlayers. There are many tutorials out there demonstrating the use of vector tiles with predefined styles and tutorials explaining how to build a fully vector tile map online. My aim instead is to demonstrate the processes to build:
1. A vector tile set up overlaying a raster tile cache
2. How to integrate a custom style.json
3. How to do all of this in a custom projection using Openlayers
As always, there is more than one method to do any of this. What is shown below can definitely be improved upon. Please take this and make it better.

Github Respository is here.

Website example is here.

This example uses Openlayers6. The map is served in the NZTM projection (EPSG:2193). No effort has been made in ordering the labels. The labels display as the Openlayers decluttering orders them. Included in the JS code is a basic pop-up window demonstrating how to get information from the vector tile.

The project is built as a static set up. The vector tile cache is built directly into the website. THIS IS NOT OPTIMAL, but does demonstrate the principle. Ideally, you would have a location like AWS S3, to serve your tile cache from.

In order to use a custom projection, you will need to build an XYZ tile cache. MBTiles do not handle projections other than Web Mercator (EPSG:3857).
Basic steps
1. Download or reproject the shapefile in NZTM
2. Upload shapefile to PostgreSQL database with PostGIS extensions
3. Tile PostgreSQL table into NZTM (EPSG:2193) XYZ tile cache using TRex
4. Construct Openlayers6 JS for tile consuption
Sample Data
[https:]]

Note:

The Geographic Names layer is clipped and filtered for this example. I clipped only to the Wellington Region and filtered the data only to use:
```
desc_code = BAY, METR, LOC, POP, TOWN, SBRB
```
Upload to PostgreSQL
```
shp2pgsql -s 2193 /data/wellyRegion_townBay.shp public.wellyRegion_townBay_nztm | psql -h localhost -d <yourDatabaseHere> -U <youUserNameHere>
```
TRex Tiling
TRex will create an XYZ tile cache in the projection of your choosing. You will need to know the resolutions and bounding box of your projection in order to make this work. I was fortunate to have this information at hand thanks to a great tutorial from LINZ.

TRex uses a config file for tiling. The config used in this example is here

The command used to run TREX:
```
t_rex generate --progress true --maxzoom=14 --minzoom=0 --extent=174.627603,-41.613839,176.259896,-40.737190  --config /configpsql_points.toml
```
TRex will generate gzip pfb’s. If you prefer to unzip them:
```
find . -type f | xargs -n1 -P 1 -t -I % gzip -d -r -S .pbf %
```
```
find . -type f | xargs -n1 -P 1 -t -I % % %.pbf
```
Openlayers JS
The Openlayers for this is version 6. <script> tags needed are:
```
<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/v6.5.0/css/ol.css" type="text/css">

<script src="https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/v6.5.0/build/ol.js"></script>

<script src="http://planet.osgeo.org//cdnjs.cloudflare.com/ajax/libs/proj4js/2.3.15/proj4.js"></script>

<script src="https://unpkg.com/ol-mapbox-style@6.3.2/dist/olms.js" type="text/javascript"></script>
```
For the full JS example
NZTM Construct in Openlayers
Building the projection for Openlayers
```
// set NZTM projection extent so OL can determine zoom level 0 extents.
// Define NZTM projection
proj4.defs("EPSG:2193","+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs");

// Register projection with OpenLayers
ol.proj.proj4.register(proj4);

// Create new OpenLayers projection
var proj2193 = new ol.proj.Projection({
	code: 'EPSG:2193',
	units: 'm',
	extent: [827933.23, 3729820.29, 3195373.59, 7039943.58]
});

// NZTM tile matrix origin, resolution and matrixId definitions.
var origin = [-1000000, 10000000];
var resolutions = [ 8960, 4480, 2240, 1120, 560, 280, 140, 70, 28, 14, 7, 2.8, 1.4, 0.7, 0.28, 0.14, 0.07 ];
var matrixIds = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16];
```
Applying to Raster and Vector Tiles Raster Tiles
Another great tutorial from LINZ regarding the set up of an XYZ for raster tiles.
```
// Tile Services Map
var urlTemplate =
  "https://tiles.maps.linz.io/nz_colour_basemap/NZTM/{z}/{x}/{y}.png";

// Set raster layer
var layer = new ol.layer.Tile({
  source: new ol.source.XYZ({
    url: urlTemplate,
    projection: proj2193,
    attributions: ['<a href="http://data.linz.govt.nz">Data from LINZ. CC BY 4.0</a>'],
    tileGrid: new ol.tilegrid.TileGrid({
      origin: origin,
      resolutions: resolutions,
      matrixIds: matrixIds,
      extent: [827933.23, 3729820.29, 3195373.59, 7039943.58]
    })
  })
});
```
Vector Tiles
Set up the vector layer to use custom projection:
```
// Set vector layer
var placeSource = new ol.source.VectorTile({
  cacheSize: 0,
  overlaps: true,
  tilePixelRatio: 1, // oversampling when > 1
  tileGrid: new ol.tilegrid.TileGrid({ 
    origin: [-1000000, 10000000],
    maxZoom: 16,
    tileSize: 4096,
    extent: [827933.23, 3729820.29, 3195373.59, 7039943.58],
    resolutions: resolutions,
  }),
  extent: [827933.23, 3729820.29, 3195373.59, 7039943.58],
  format: new ol.format.MVT(),
  projection: ol.proj.get('EPSG:2193'),
  url: 'https://xycarto.github.io/static.vector.tiles.openlayers.nztm/tiles/wellyRegion_townBay_nztm/{z}/{x}/{y}.pbf'
});

var vectorMap = new ol.layer.VectorTile({
  declutter: true,
  source: placeSource,
  renderMode: 'vector',
  zIndex: 10
  })
```
Styling
For the style file example.
1. The method in this example is loading the vector tile and overaying it on a raster tile cache. In order to accomplish this, a vector tile cache must be loaded first to the map, THEN the rules from the style JOSN are applied using:
```
fetch('./styleText.json').then(function(response) {
  response.json().then(function(glStyle) {
    olms.applyStyle(vectorMap, glStyle, 'wellyRegion_townBay_wgs');
  });
});
```
1. The above uses olms.applyStyle. To access this function you will need to add the scipt tag to your HTML:
```
<script src="https://unpkg.com/ol-mapbox-style@6.3.2/dist/olms.js" type="text/javascript"></script>
```
Notes
1. Not fully complete. Working example only
2. Runs slow in Safari
3. This is in no way the only way to do this. My hope is someone takes this and make it better.
4. Still needs label work for use on mobile devices.
11:00
CARTO Blog: Enhancing Geospatial in BigQuery with CARTO Spatial Extension
sur Planet OSGeo

At CARTO, we firmly believe that the future of geospatial analysis lies in the realm of next generation cloud data warehouses. Traditional data sources (such as census data...
4:08
Martin Davis: JTS goes to Mars!
sur Planet OSGeo

The other day this badge popped up on my GitHub profile:
Sure enough, there is JTS in the list of dependencies provided by the Jet Propulsion Laboratory (JPL).
So take that, Elon - JTS got there first! With a lot of help from NASA, of course.
Oh how nice, the Earthlings are giving me some target practice!
28 April 2021
17:32
GIScussions: Malena Libman
sur Planet OSGeo

This post is reposted from Mappery

Yesterday the open source and open data geo communities were devastated by the tragic news of the passing of our friend and colleague Malena Libman. There was an outpouring of grief and celebration of her zest for life, humour, warmth and contribution to open geo.

Jody Garnett posted this picture of Malena’s tattoo which is truly a Map in the Wild today.

I met Malena in 2018 in Dar es Salaam for FOSS4G, the first time you met her you knew that she was something different, a force of nature. She wanted some advice about chairing a global FOSS4G event because she had a plan to host FOSS4G in Buenos Aires in 2021, by the end of the conference she had convinced me to advise her.

I’m struggling to find the words to express how tragic it is that Malena will not be with us to celebrate FOSS4G 2021 but I know that her co-chair and close friend Maria Aria de Reyna and the rest of the organising team will make this a special event to celebrate her memory.
13:00
Narcélio de Sá: QGIS – Cálculo de área tridimensional com o r.surf.area
sur Planet OSGeo

Nesse vídeo iremos aprender como usar a função r.surf.area para realizar o cálculo de área de uma superfície tridimensional. Ou seja calcularemos a área de uma região levando em consideração a sua topografia.
Notas sobre o calculo do r.surf.area
Como podemos observar na documentação do algorítimo, link abaixo, o cálculo depende muito da resolução dos dados (pense nisso como um problema fractal de linha costeira; quanto mais resolução, mais detalhes, mais área, etc).

O r.surf.area funciona melhor quando a superfície que está sendo avaliada se estende até as bordas da região atual e a resolução da célula é pequena. Superfícies que são especialmente longas e finas e têm limites altamente irregulares tendem a ter áreas de superfície subestimadas.

E lembre-se definir uma resolução de célula alta (área pequena) reduzirá muito esse impacto, mas causará tempos de processamento mais longos.
Links úteis
Documentação da função: https://grass.osgeo.org/grass74/manua…

Artigo sobre a estimativa de erro na delimitação de a?ea 3D utilizando o r.surf.area: [https:]]

O que vocês acharam deste tutorial
QGIS - Cálculo de área tridimensional com o r.surf.area ?

Aguardo seus comentários, dicas e sugestões.

Faça uma doação para o canal via Picpay: https://app.picpay.com/user/narceliodesa
Ou faça um doação via PIX: narceliosapereira@gmail.com
Nos siga em todas as plataformas: https://linktr.ee/narceliodesa
Contato comercial: narceliosapereira@gmail.com

The post QGIS – Cálculo de área tridimensional com o r.surf.area appeared first on Narcélio de Sá.
11:00
CARTO Blog: 6 Companies using Location Intelligence for Sustainability
sur Planet OSGeo

Last week the 51st annual Earth Day was celebrated with three days of events taking place centered around climate action. A key theme during the events was that of sustaina...
23 April 2021
23:12
GRASS GIS: New GRASS GIS tutorials
sur Planet OSGeo

Participants of a GRASS GIS workshop contribute new tutorials The workshop Geospatial data analysis with GRASS GIS organized by Gulich Institute in Argentina, concluded last week with participants from different Latin American countries defending their work. The workshop went through different topics within GRASS ecosystem, but mostly covered remote sensing, Object Based Image Analysis (OBIA) and time series analysis, making use of GRASS GIS extensions to obtain and process Landsat, Sentinel and MODIS data.

Skip to page: 1 2 3 ... 14

← Blog Interopérabilité &...

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Carte des membres Sites amis	Agenda Biblio Netvibes Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Carte des CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Dataset	New time	Old time
Subset (909,865 pts)	0.25 s	1 s
Full (5,212,102 pts)	2 s	30 s

Le portail francophone de la géomatique

Feeds

Planet OSGeo

Enclosure: [download]