OSGeo Planet

PostGIS Development: Move PostGIS extension to a different schema

OSGeo Planet - Tue, 2017-11-07 00:00

As of PostGIS 2.3, the postgis extension was changed to no longer allow relocation. All function calls within the extension are now schema qualified.

While this change fixed some issues with database restore, it created the issue of if you installed PostGIS in a schema other than the one you wanted to it is not intuitive how to move it to a different schema. Luckily there is a way to do this.

For this exercise, I will install PostGIS in the default schema and then demonstrate how to move it into another schema location.

You can run these steps using psql or pgAdmin or any other PostgreSQL tool you want.

Continue Reading by clicking title hyperlink ..
Categories: OSGeo Planet

Paul Ramsey: Parallel PostGIS IIA

OSGeo Planet - Mon, 2017-11-06 20:00

One of the core complaints in my review of PostgreSQL parallelism, was that the cost of functions executed on rows returned by queries do not get included in evaluations of the cost of a plan.

So for example, the planner appeared to consider these two queries equivalent:

SELECT * FROM pd; SELECT ST_Area(geom) FROM pd;

They both retrieve the same number of rows and both have no filter on them, but the second one includes a fairly expensive function evaluation. No amount of changing the cost of the ST_Area() function would cause a parallel plan to materialize. Only changing the size of the table (making it bigger) would flip the plan into parallel mode.

Fortunately, when I raised this issue on pgsql-hackers, it turned out to have been reported and discussed last month, and Amit Kapila had already prepared a patch, which he kindly rebased for me.

With the patch in place, I now see rational behavior from the planner. Using the default PostGIS function costs, a simple area calculation on my 60K row polling division table is sequential:

EXPLAIN SELECT ST_Area(geom) FROM pd; Seq Scan on pd (cost=0.00..14445.17 rows=69534 width=8)

However, if the ST_Area() function is costed a little more realistically, the plan shifts.

ALTER FUNCTION ST_Area(geometry) COST 100; EXPLAIN SELECT ST_Area(geom) FROM pd; Gather (cost=1000.00..27361.20 rows=69534 width=8) Workers Planned: 3 -> Parallel Seq Scan on pd (cost=0.00..19407.80 rows=22430 width=8)

Perfect!

While not every query receives what I consider a “perfect plan”, it now appears that we at least have some reasonable levers available to get better plans via applying some sensible (higher) costs across the PostGIS code base.

Categories: OSGeo Planet

gvSIG Team: Presentación de las novedades de gvSIG 2.4 (Un adelanto de…)

OSGeo Planet - Mon, 2017-11-06 15:41

En las 13as Jornadas Internacionales de gvSIG presentamos una “première” de las novedades que traerá la próxima versión de gvSIG Desktop 2.4. Aunque en este mismo blog hemos ido informando de gran parte de ellas, estando ya muy cerca la publicación de la final, es la primera vez que las presentamos en conjunto.

Un último apunte…a pesar de la cantidad de novedades presentadas, nos dejamos alguna más en la que estamos trabajando para anunciar las próximas semanas (y que pensamos va a gustar mucho).

Os dejamos con el vídeo:


Filed under: gvSIG Desktop, spanish Tagged: gvSIG 2.4, gvSIG Desktop 2.4, novedades
Categories: OSGeo Planet

OSGeo News: OTB 6.2.0 Released

OSGeo Planet - Mon, 2017-11-06 09:17
Categories: OSGeo Planet

gvSIG Team: SIG aplicado a Gestión Municipal: Módulo 8.2 ‘ Capas de puntos a partir de tablas (Capa de eventos)’

OSGeo Planet - Mon, 2017-11-06 05:12

Ya está disponible el segundo vídeo del octavo módulo, donde seguimos viendo cómo crear capas de puntos a partir de tablas. En este caso lo que veremos será cómo crear capas de eventos, es decir, a partir de una tabla con coordenadas de puntos generaremos un fichero shp con dichos puntos.

La tabla podemos tenerla por ejemplo con coordenadas geográficas que podamos haber obtenido de una medición con GPS.

Esta funcionalidad es otra forma más de poder generar nuestra cartografía en un ayuntamiento cuando solo disponemos de las coordenadas de los puntos.

La cartografía a utilizar en este vídeo la podéis descargar desde el siguiente enlace.

El segundo vídeo-tutorial de este octavo módulo es el siguiente:

Post relacionados:


Filed under: gvSIG Desktop, spanish, training Tagged: ayuntamientos, capa de eventos, gestión municipal, GPS, tablas de atributos
Categories: OSGeo Planet

Paulo van Breugel: Hands-on course to GIS and Remote Sensing with GRASS GIS

OSGeo Planet - Sun, 2017-11-05 14:04
The hands-on GRASS GIS course at ITC – University of Twente on November 3rd, 2017 was a great success. The course, organized by ITC and OSGeo.nl, offered a very nice introduction to GRASS GIS by Veronica Andreo and a guided tour about working with GRASS GIS by Sajid Pareeth. As part of the course, we …

Continue reading Hands-on course to GIS and Remote Sensing with GRASS GIS

Categories: OSGeo Planet

gvSIG Team: Presentación de mejoras de gvSIG Roads, solución libre para gestión de carreteras

OSGeo Planet - Fri, 2017-11-03 10:40

gvSIG Roads es la solución para gestión de carreteras de la Suite gvSIG. Originalmente contenía una serie de herramientas orientadas al inventario y conservación, que se han visto considerablemente mejoradas y complementadas con otras relacionadas con áreas como la de accidentalidad. Además, la aplicación que nació en la Diputación de Valencia está ya implantada en un buen número de entidades, empezando a ser la plataforma de referencia en software libre para gestión de infraestructuras viarias.

Todo ello se presentó en las 13as Jornadas Internacionales de gvSIG y ahora os compartimos el vídeo para todos aquellos que no pudisteis asistir.

Si estás interesado en implantar gvSIG Roads, puedes contactar con la Asociación gvSIG en info@gvsig.com


Filed under: gvSIG Roads, gvSIG Suite, software libre, spanish Tagged: carreteras, Conservación, infraestructura viaria, inventario
Categories: OSGeo Planet

Markus Neteler: PDAL 1.6.0 packaged for Fedora including vertical datums and grids

OSGeo Planet - Fri, 2017-11-03 10:39

 openNRW Germany)In order to simplify the installation of the latest PDAL release (Point Data Abstraction Library, http://www.pdal.io/, version 1.6.0) on Fedora, I have created an updated set of RPM packages now including vertical datums and grids (.gtx files from here).

The installation is as simple as this (the repository is located at Fedora’s COPR):

# enable extra repos to satisfy dependencies sudo dnf copr enable neteler/pdal-hexer sudo dnf copr enable neteler/points2grid # install dependencies sudo dnf install hexer sudo dnf install points2grid # enable and install PDAL sudo dnf copr enable neteler/pdal sudo dnf install PDAL PDAL-devel PDAL-vdatums # run PDAL: pdal-config --version pdal --help

Enjoy!

The post PDAL 1.6.0 packaged for Fedora including vertical datums and grids appeared first on GFOSS Blog | GRASS GIS Courses.

Categories: OSGeo Planet

gvSIG Team: gvSIG Online en el Consorcio Provincial de Bomberos de Valencia, SIG libre aplicado a la gestión de la emergencia y su prevención

OSGeo Planet - Fri, 2017-11-03 05:14

Os traemos la presentación de uno de los últimos proyectos que hemos realizado en la Asociación gvSIG. Se trata, básicamente, de la implantación y adaptación de gvSIG Online a las necesidades del Consorcio Provincial de Bomberos de Valencia de forma que tuvieran una Infraestructura de Datos Espaciales efectiva y al mismo tiempo fácil de usar.

Entre los requisitos de partida estaba la necesidad de realizar captura de datos en campo (para prevención, como la tarea de mantenimiento de hidrantes), disponer de información en la Emergencia, integración con el Sistema de Gestión de Emergencia, uso sin acceso a la Red desde puesto de mando avanzado, compartir información con otras entidades y unificar fuentes de datos.

Y, por supuesto, con una solución 100% software libre.

Si queréis conocer en detalle el proyecto no os perdáis el siguiente vídeo:

Si queréis implantar una solución similar en vuestra organización, contactad con nosotros en info@gvsig.com


Filed under: geoportal, gvSIG Online, gvSIG Suite, IDE, software libre, spanish Tagged: bomberos, emergencias, hidrantes, seguridad
Categories: OSGeo Planet

gvSIG Team: Presentación de gvSIG Crime, la solución de la Asociación gvSIG para criminología

OSGeo Planet - Thu, 2017-11-02 21:33

En las 13as Jornadas Internacionales de gvSIG se presentó gvSIG Crime, un nuevo producto que se añade al catálogo de soluciones de la Suite gvSIG. La presentación se complementó con un taller de geoestadística aplicado a criminología y otro dedicado al uso de gvSIG Desktop para análisis, visualización y aplicación de geoprocesos a información relacionada con la seguridad.

gvSIG Crime viene a cubrir la necesidad de una plataforma en software libre para la gestión de información delictual, con componentes web, de escritorio y móvil. Sin duda un producto del que vamos a oír a hablar mucho en el futuro y que no van a ser pocas las organizaciones que lo adopten.

Os dejamos con su presentación:


Filed under: gvSIG Crime, gvSIG Desktop, gvSIG Mobile, gvSIG Online, gvSIG Suite, spanish Tagged: criminología
Categories: OSGeo Planet

gvSIG Team: SIG aplicado a Gestión Municipal: Módulo 8.1 ‘Creación de capas de puntos a partir de tablas (Geocodificación: Puntos a partir de tabla con direcciones)’

OSGeo Planet - Thu, 2017-11-02 14:52

Ya está disponible el primer vídeo del octavo módulo, que trata sobre cómo crear capas de puntos a partir de tablas. En este primer vídeo veremos la parte de geocodificación, creando una capa de puntos a partir de una tabla con direcciones.

La tabla, aparte de direcciones también podría contener elementos característicos como museos, monumentos, instalaciones deportivas…, es decir, todo lugar que podríamos encontrar en buscadores como Google Maps, OpenStreetMap…, ya que emplea dichos motores de búsqueda para crear dicha capa.

Esta funcionalidad es muy útil en un ayuntamiento, ya que si disponemos por ejemplo de varias tablas con dichos elementos o sus direcciones, no tendríamos que ir digitalizando uno a uno. Gracias a este geoproceso lo podremos realizar de forma automática, y solo tendríamos que abortar una fase de control de calidad al final para ver que los resultados son correctos (ya que como sabemos dichos motores de búsqueda también tienen ciertos errores). Aparte, podemos indicarle en el geoproceso que nos muestre qué elementos o direcciones no han sido encontrados, para así poder digitalizarlos de otra forma.

También mostraremos cómo acceder a Google Street View desde gvSIG, muy interesante para el trabajo de oficina, para ciertas consultas que nos evitarían el tener que acercarnos al lugar en persona.

La cartografía a utilizar en este vídeo la podéis descargar desde el siguiente enlace.

El primer vídeo-tutorial de este octavo módulo es el siguiente:

Post relacionados:


Filed under: gvSIG Desktop, spanish, training Tagged: ayuntamientos, direcciones, geocodificación, gestión municipal, Google Maps, OpenStreetMap, OSM
Categories: OSGeo Planet

gvSIG Team: State of art, What is the difference between Geopaparazzi and gvSIG Mobile, tools for gvSIG Desktop and much more

OSGeo Planet - Thu, 2017-11-02 08:40

During the 13th International gvSIG Conference Andrea Antonello of HydroloGIS spoke us about Geopaparazzi and gvSIG Mobile.

If you need an engineering survey tool, an open source Mobile GIS don’t miss this video:


Filed under: english, Geopaparazzi, gvSIG Mobile
Categories: OSGeo Planet

Equipo Geotux: Generación de metadatos con QSphere en QGIS

OSGeo Planet - Wed, 2017-11-01 15:13

QSphere es un complemento de QGIS que de acuerdo a la documentación oficial "es una extensión que se llevó a cabo en el marco de jornadas de información en la atención a ADL (Administradores de Datos) de la Secretaría de Desarrollo Sustentable del Estado francés para la implementación de catálogos, que permite la documentación de metadatos". Desarrollo por Christophe MASSE, del Centro de servicios informáticos e ingeniería del Ministerio de Ambiente de Francia.

Básicamente QSphere permite generar la documentación de metadatos conforme a la norma ISO 19139 de recursos geográficos en QGIS Desktop, así como la exploración de metadatos a través de los servicios de catálogos.

QSphere presenta una interfaz gráfica amigable para generar la documentación de metadatos de acuerdo a la iniciativa INSPIRE, usando ayudantes, formularios, editor y salidas en XML y presentación en HTML para la salida en un Servicio Web de Catálogos.

Para mayor información consulte el sitio Web del proyecto: https://qgis.projets.developpement-durable.gouv.fr/projects/qsphere

 

 

Nota: Este documento hace parte del material de guías de talleres del curso de Servicios Web Geográficos de la Maestría en Geomática de la Universidad Nacional de Colombia Sede Bogotá, mayor información en http://www.aulageo.cloud/course/unal-ogc-2017/ INSTALACIÓN DE QSPHERE

Para la instalación del complemento se requiere agregar el repositorio de QGIS del Ministerio de Ambiente de Francia:

http://piece-jointe-carto.developpement-durable.gouv.fr/NAT002/QGIS/plugins/plugins.xml

Repositorio QSpehre

Luego de sincronizar el repositorio de complementos, se puede realizar la instalación del módulo de QSphere.

La versión instalada a la fecha, corresponde a la versión 4.3.8 en QGIS 2.18.x. Las versiones más actuales del complemento está orientada a las versión de desarrollo de QGIS 3.

Nota 1:…


Read more...
Categories: OSGeo Planet

Paul Ramsey: Parallel PostGIS II

OSGeo Planet - Tue, 2017-10-31 20:00

A year and a half ago, with the release of PostgreSQL 9.6 on the horizon, I evaluated the parallel query infrastructure and how well PostGIS worked with it.

The results at the time were mixed: parallel query worked, when poked just the right way, with the correct parameters set on the PostGIS functions, and on the PostgreSQL back-end. However, under default settings, parallel queries did not materialize. Not for scans, not for joins, not for aggregates.

With the recent release of PostgreSQL 10, another generation of improvement has been added to parallel query processing, so it’s fair to ask, “how well does PostGIS parallelize now?”

Parallel PostGIS II

TL;DR:

The answer is, better than before:

  • Parallel aggregations now work out-of-the-box and parallelize in reasonable real-world conditions.
  • Parallel scans still require higher function costs to come into action, even in reasonable cases.
  • Parallel joins on spatial conditions still seem to have poor planning, requiring a good deal of manual poking to get parallel plans.
Setup

In order to run these tests yourself, you will need:

  • PostgreSQL 10
  • PostGIS 2.4

You’ll also need a multi-core computer to see actual performance changes. I used a 4-core desktop for my tests, so I could expect 4x improvements at best.

For testing, I used the same ~70K Canadian polling division polygons as last time.

createdb parallel psql -c 'create extension postgis' parallel shp2pgsql -s 3347 -I -D -W latin1 PD_A.shp pd | psql parallel

PDs

To support join queries, and on larger tables, I built a set of point tables based on the polling divisions. One point per polygon:

CREATE TABLE pts AS SELECT ST_PointOnSurface(geom)::Geometry(point, 3347) AS geom, gid, fed_num FROM pd; CREATE INDEX pts_gix ON pts USING GIST (geom);

Ten points per polygon (for about 700K points):

CREATE TABLE pts_10 AS SELECT (ST_Dump(ST_GeneratePoints(geom, 10))).geom::Geometry(point, 3347) AS geom, gid, fed_num FROM pd; CREATE INDEX pts_10_gix ON pts_10 USING GIST (geom);

One hundred points per polygon (for about 7M points):

CREATE TABLE pts_100 AS SELECT (ST_Dump(ST_GeneratePoints(geom, 100))).geom::Geometry(point, 3347) AS geom, gid, fed_num FROM pd; CREATE INDEX pts_100_gix ON pts_100 USING GIST (geom);

The configuration parameters for parallel query have changed since the last test, and are (in my opinion) a lot easier to understand.

These parameters are used to fine-tune the planner and execution. Usually you don’t need to change them.

  • parallel_setup_cost sets the planner’s estimate of the cost of launching parallel worker processes. Default 1000.
  • parallel_tuple_cost sets the planner’s estimate of the cost of transferring one tuple from a parallel worker process to another process. Default 0.1.
  • min_parallel_table_scan_size sets the minimum amount of table data that must be scanned in order for a parallel scan to be considered. Default 8MB.
  • min_parallel_index_scan_size sets the minimum amount of index data that must be scanned in order for a parallel scan to be considered. Default 512kB.
  • force_parallel_mode forces the planner to parallelize is wanted. Values: off | on | regress
  • effective_io_concurrency for some platforms and hardware setups allows true concurrent read. Values from 1 (for one spinning disk) to ~100 (for an SSD drive). Default 1.

These parameters control how many parallel processes are launched for a query.

  • max_worker_processes sets the maximum number of background processes that the system can support. Default 8.
  • max_parallel_workers sets the maximum number of workers that the system can support for parallel queries. Default 8.
  • max_parallel_workers_per_gather sets the maximum number of workers that can be started by a single Gather or Gather Merge node. Setting this value to 0 disables parallel query execution. Default 2.

Once you get to the point where #processes == #cores there’s not a lot of advantage in adding more processes. However, each process does exact a cost in terms of memory: a worker process consumes work_mem the same as any other backend, so when planning memory usage take both max_connections and max_worker_processes into consideration.

Before running tests, make sure you have a handle on what your parameters are set to: I frequently found I accidentally tested with max_parallel_workers set to 1.

show max_worker_processes; show max_parallel_workers; show max_parallel_workers_per_gather; Aggregates

First, set max_parallel_workers and max_parallel_workers_per_gather to 8, so that the planner has as much room as it wants to parallelize the workload.

PostGIS only has one true spatial aggregate, the ST_MemUnion function, which is comically inefficient due to lack of input ordering. However, it’s possible to see some aggregate parallelism in action by wrapping a spatial function in a parallelizable aggregate, like Sum():

SET max_parallel_workers = 8; SET max_parallel_workers_per_gather = 8; EXPLAIN ANALYZE SELECT Sum(ST_Area(geom)) FROM pd

Boom! We get a 3-worker parallel plan and execution about 3x faster than the sequential plan.

Finalize Aggregate (cost=15417.45..15417.46 rows=1 width=8) (actual time=236.925..236.925 rows=1 loops=1) -> Gather (cost=15417.13..15417.44 rows=3 width=8) (actual time=236.915..236.921 rows=4 loops=1) Workers Planned: 3 Workers Launched: 3 -> Partial Aggregate (cost=14417.13..14417.14 rows=1 width=8) (actual time=231.724..231.724 rows=1 loops=4) -> Parallel Seq Scan on pd (cost=0.00..13800.30 rows=22430 width=2308) (actual time=0.049..30.407 rows=17384 loops=4) Planning time: 0.111 ms Execution time: 238.785 ms

Just to confirm, re-run it with parallelism turned off:

SET max_parallel_workers_per_gather = 0; EXPLAIN ANALYZE SELECT Sum(ST_Area(geom)) FROM pd

Back to one thread and taking about 3 times as long, as expected.

Scans

The simplest spatial parallel scan adds a spatial function to the filter clause.

SET max_parallel_workers = 8; SET max_parallel_workers_per_gather = 8; EXPLAIN ANALYZE SELECT * FROM pd WHERE ST_Area(geom) > 10000;

Unfortunately, that does not give us a parallel plan.

The ST_Area() function is defined with a COST of 10. If we move it up, to 100, we can get a parallel plan.

SET max_parallel_workers_per_gather = 8; ALTER FUNCTION ST_Area(geometry) COST 100; EXPLAIN ANALYZE SELECT * FROM pd WHERE ST_Area(geom) > 10000;

Boom! Parallel scan with three workers:

Gather (cost=1000.00..20544.33 rows=23178 width=2554) (actual time=0.253..293.016 rows=62158 loops=1) Workers Planned: 5 Workers Launched: 5 -> Parallel Seq Scan on pd (cost=0.00..17226.53 rows=4636 width=2554) (actual time=0.091..210.581 rows=10360 loops=6) Filter: (st_area(geom) > '10000'::double precision) Rows Removed by Filter: 1229 Planning time: 0.128 ms Execution time: 302.600 ms

It appears our spatial function costs may still be too low in general to get good planning. And as we will see with joins, it’s possible the planner is still discounting function costs too much in deciding whether to go parallel or not.

Joins

Starting with a simple join of all the polygons to the 100 points-per-polygon table, we get:

SET max_parallel_workers_per_gather = 4; EXPLAIN SELECT * FROM pd JOIN pts_100 pts ON ST_Intersects(pd.geom, pts.geom);

PDs & Points

In order to give the PostgreSQL planner a fair chance, I started with the largest table, thinking that the planner would recognize that a “70K rows against 7M rows” join could use some parallel love, but no dice:

Nested Loop (cost=0.41..13555950.61 rows=1718613817 width=2594) -> Seq Scan on pd (cost=0.00..14271.34 rows=69534 width=2554) -> Index Scan using pts_gix on pts (cost=0.41..192.43 rows=232 width=40) Index Cond: (pd.geom && geom) Filter: _st_intersects(pd.geom, geom)

There are a number of knobs we can press on. There are two global parameters:

  • parallel_setup_cost defaults to 1000, but no amount of lowering the value, even to zero, causes a parallel plan.
  • parallel_tuple_cost defaults to 0.1. Reducing it by a factor of 100, to 0.001 causes the plan to flip over into a parallel plan.
SET parallel_tuple_cost = 0.001;

As with all parallel plans, it is a nested loop, but that’s fine since all PostGIS joins are nested loops.

Gather (cost=0.28..4315272.73 rows=1718613817 width=2594) Workers Planned: 4 -> Nested Loop (cost=0.28..2596658.92 rows=286435636 width=2594) -> Parallel Seq Scan on pts_100 pts (cost=0.00..69534.00 rows=1158900 width=40) -> Index Scan using pd_geom_idx on pd (cost=0.28..2.16 rows=2 width=2554) Index Cond: (geom && pts.geom) Filter: _st_intersects(geom, pts.geom)

Running the parallel plan to completion on the 700K point table takes 18s with four workers and 53s with a sequential plan. We are not getting an optimal speed up from parallel processing anymore: four workers are completing in 1/3 of the time instead of 1/4.

If we set parallel_setup_cost and parallel_tuple_cost back to their defaults, we can also change the plan by fiddling with the function costs.

First, note that our query can be re-written like this, to expose the components of the spatial join:

SET parallel_tuple_cost=0.1; SET parallel_setup_cost=1000; SET max_parallel_workers_per_gather = 4; EXPLAIN SELECT * FROM pd JOIN pts_100 pts ON pd.geom && pts.geom AND _ST_Intersects(pd.geom, pts.geom);

The default cost of _ST_Intersects() is 100. If we adjust it up by a factor of 100, we can get a parallel plan.

ALTER FUNCTION _ST_Intersects(geometry, geometry) COST 10000;

However, what if our query only used a single spatial operator in the join filter? Can we still force a parallel plan on this query?

SET parallel_tuple_cost=0.1; SET parallel_setup_cost=1000; SET max_parallel_workers_per_gather = 4; EXPLAIN SELECT * FROM pd JOIN pts_100 pts ON pd.geom && pts.geom;

The && operator could activate one of two functions:

  • geometry_overlaps(geom, geom) is bound to the && operator
  • geometry_gist_consistent_2d(internal, geometry, int4) is bound to the 2d spatial index

However, no amount of increasing their COST causes the operator-only query plan to flip into a parallel mode:

ALTER FUNCTION geometry_overlaps(geometry, geometry) COST 1000000000000; ALTER FUNCTION geometry_gist_consistent_2d(internal, geometry, int4) COST 10000000000000;

So for operator-only queries, it seems the only way to force a spatial join is to muck with the parallel_tuple_cost parameter.

More Joins

Can we parallelize a common GIS use case: the spatial overlay?

Shifted PDs

Here is a table that simply shifts the polling divisions up and over, so that they can be overlaid to create a new set of smaller polygons.

CREATE TABLE pd_translate AS SELECT ST_Translate(geom, 100, 100) AS geom, fed_num, pd_num FROM pd; CREATE INDEX pd_translate_gix ON pd_translate USING GIST (geom); CREATE INDEX pd_fed_num_x ON pd (fed_num); CREATE INDEX pdt_fed_num_x ON pd_translate (fed_num);

The overlay operation finds, for each geometry on one side, all the overlapping geometries, and then calculates the shape of those overlaps (the “intersection” of the pair). Calculating intersections is expensive, so it’s something want to happen in parallel, even more than we want the join to happen in parallel.

This query calculates the overlay of all polling divisions (and their translations) in British Columbia (fed_num > 59000):

EXPLAIN SELECT ST_Intersection(pd.geom, pdt.geom) AS geom FROM pd JOIN pd_translate pdt ON ST_Intersects(pd.geom, pdt.geom) WHERE pd.fed_num > 59000 AND pdt.fed_num > 59000;

Unfortunately, the default remains a non-parallel plan. The parallel_tuple_cost has to be adjusted down to 0.01 or the cost of _ST_Intersects() adjusted upwards to get a parallel plan.

Conclusions
  • The costs assigned to PostGIS functions still do not provide the planner a good enough guide to determine when to invoke parallelism. Costs assigned currently vary widely without any coherent reasons.
  • The planner behaviour on spatial joins remains hard to predict: is the deciding factor the join operator cost, the number of rows of resultants, or something else altogether? Counter-intuitively, it was easier to get join behaviour from a relatively small 6K x 6K polygon/polygon overlay join than it was for the 70K x 7M point/polygon overlay.
Categories: OSGeo Planet

GeoSolutions: New release of MapStore with Annotations and Quick Search

OSGeo Planet - Mon, 2017-10-30 15:00

Release 2017.05.00

Dear Reader,

we are pleased to announce release 2017.05.00 of MapStore, our flagship Open Source webgis product. The full list of changes for this release can be found here, but the most interesting additions are the following:

  • General Review of Map Layout, reorgainizing tools in the bottom-right corner and adding the footer.
  • TOC UI Review, so that now the map's table of contents is organized in cards.
  • Catalog UI Review, to make the catalog widget more intuitive. You can add as many sources as you want and save them in the map.
  • Initial Support for annotations, now you can quickly annotate the map with markers having also the ability to customize their style and description.
  • Quick Filter on Feature Grid, now you can search directly from the featuregrid without opening the query panel. You can also synchronize the content of the map with the filtered data.
General Review of Map Layout We have started an in-depth review of the map look&feel; now the scale and coordinate indicators are placed in a footer, together with the attribution. The table of contents has been reorganized, allowing filtering and grouping all the layer tools in the top toolbar; the layers are now organized in cards that can be expanded or collapsed to see the legend. [gallery type="slideshow" size="full" ids="3752,3750"] The catalog widget has also been reviewed. Now you can add OGC CSW, WMS, or WMTS services in a more intuitive way and store them in the map configuration for later reuse.  [caption id="attachment_3748" align="aligncenter" width="1024"]New Catalog UI New Catalog UI[/caption]   [caption id="attachment_3749" align="aligncenter" width="1024"]Add Catalog Services Add Catalog Services[/caption] Initial version of Map Annotations We have implemented a first version of map annotations that can be used to implement markers. You can easily add to the map your own markers, customizing content, icon and color. You can  use this functionalities to mark your favorite places, the places to visit for work or whatever you want. Annotations are saved in the map context, hence you can share them with your friends, coworkers or the users of your geoportal. More feature and look&feel improvements will be performed in the next releases. [caption id="attachment_3765" align="aligncenter" width="1024"]Annotations Annotations[/caption] Quick Search

We have been struggling over the years with complex interactions with visual query builders to filter data exposed via the OGC WFS services. We have therefore decided to try and build a simplified filtering capability to easily filter vector layers directly from the data grid column headers. You can now enter text or insert a formula (like > 10 or <= -23) right in the header and see the data grid filter rows automatically. You can also synchronize the content of the map to match the content of the data grid. 

[caption id="attachment_3769" align="aligncenter" width="1024"]Quick Search and Map Sync Quick Search and Map Sync[/caption] Future Work

We have great plans for the future which translates into many new features in the working. Just to give you a little preview of an interesting one, for the next release we are implementing charting capabilities for vector layers directly inside the map. Here below a preview.

[caption id="attachment_3770" align="aligncenter" width="1024"]Preview of Charts functionality Preview of Charts functionalities[/caption]

In addition, there are other things in the pipeline, in sparse order:

  • Integration with GeoNode
  • Integrate styler for GeoServer
  • Revamp of the Catalog Widget to make it more usable
  • Support for layers with TIME
  • Support general map annotations, beyond simple markers

If you are interested in learning about how we can help you achieving your goals with open source products like GeoServerMapstore, GeoNode and GeoNetwork through our Enterprise Support Services and GeoServer Deployment Warranty offerings, feel free to contact us!

The GeoSolutions team,
Categories: OSGeo Planet

OTB Team: Orfeo ToolBox 6.2 is out!

OSGeo Planet - Mon, 2017-10-30 13:38
We are happy to announce that Orfeo ToolBox 6.2 is out! As usual, ready-to-use binary packages are available for Windows, Linux and Mac OS X: OTB 6.2 You can also checkout the source directly with git: git clone https://git@git.orfeo-toolbox.org/git/otb.git OTB -b release-6.2 We welcome your feedback and requests, and encourage you to join the OTB […]
Categories: OSGeo Planet

From GIS to Remote Sensing: Developing the SCP 6: Download products and Sentinel-3

OSGeo Planet - Mon, 2017-10-30 09:00
I am updating the Semi-Automatic Classification Plugin (SCP) to version 6 (codename Greenbelt) which will be compatible with the upcoming QGIS 3.

In this previous posts, I described the main changes to the SCP dock, the Main interface and the ability to create multiple band sets.
In this post I present the new interface for downloading free products such as Landsat, Sentinel-2, ASTER, MODIS and the new addition Sentinel-3.

Download products
Categories: OSGeo Planet

gvSIG Team: SIG aplicado a Gestión Municipal: Módulo 7.2 ‘Edición (SHP de geometrías derivadas)’

OSGeo Planet - Mon, 2017-10-30 08:07

Ya está disponible el segundo vídeo del séptimo módulo, donde mostraremos una funcionalidad más de la parte de edición, muy importante para el trabajo en un ayuntamiento.

La funcionalidad que veremos en este vídeo es la de crear ficheros .SHP de geometrías derivadas. Esto nos permitirá crear una capa de polígonos a partir de una de puntos o de líneas, y también una capa de líneas a partir de una de puntos. Nos será muy útil por ejemplo cuando tenemos los puntos que forman el eje de una calle de nuestro municipio, donde tenemos un campo con el orden que llevarían (si no lo tenemos debemos comprobar en la Vista qué puntos son cuando los seleccionamos para ver en qué orden están), así no tendríamos que ir digitalizando punto a punto. Lo mismo ocurriría cuando tenemos los puntos que forman una parcela. Si tenemos por ejemplo una parcela formada por 500 puntos, utilizando esta herramienta no tendríamos que ir digitalizando uno a uno esos puntos para formar el polígono, ya que se crearía de forma automática.

La cartografía a utilizar en este vídeo la podéis descargar desde el siguiente enlace.

El segundo vídeo-tutorial de este séptimo módulo es el siguiente:

Post relacionados:


Filed under: gvSIG Desktop, spanish, training Tagged: ayuntamientos, edición, geometrías derivadas, gestión municipal
Categories: OSGeo Planet

QGIS Blog: QGIS Server refactoring is done!

OSGeo Planet - Sun, 2017-10-29 22:31

As you may know, QGIS is jumping to a new major version. (Yes!) Doing so was made necessary because of the need to switch to Python 3, Qt5, but also because we needed to break the QGIS API in several places.

A year ago there was an appeal on the QGIS developer mailing list about the strong need for love that the QGIS server code base required. Indeed, the API was locked by some old methods of QGIS server. In short, QGIS server was reparsing the .qgs project file in its own way, and created dependencies to parts of QGIS we needed to drop.

As outsourcing the server code base was not an option, so we had to refactor it. The involved parties decided to get engaged in a code sprint in the city of Lyon , France dedicated to sharing their vision, planning the work and finally making all the following happen:

Higher level refactoring

All services (WMS GetMap, WFS GetFeature, GetLegendGraphics, WCS, GetPrint etc..) have been rewritten. Some like WMS were entirely rewritten. Kudos to the devs!

New features

Deep, complex and unrewarding tasks

  • Remove all singleton calls
  • Cut all the dependencies to the old QGIS project file parser
  • Minimize dependencies to GUI library. Since fonts are necessary to render maps, totally removing them was not feasible.

Infrastructure tasks

Additionally, some of these new developments have already been presented at FOSS4G-EU in July.

Congratulations to the developers who worked hard on this!

Now this deserves to be well tested, please report back any issues!


Categories: OSGeo Planet
Syndicate content