posted by on Blog

No comments

Hace ya muchos años que QGIS permite exportar a SLD, formato que es utilizado por GeoServer para simbolizar las capas cartográficas.

A partir de QGIS 3.x la exportación a SLD soporta la simbolización de etiquetas y también los controles de escalas de visualización tanto en etiquetas como en los elementos geográficos. Además también parece ser que elimina algunos problemas que había con la codificación de los campos de atributos.

Por tanto, ya no es necesario utilizar Atlas Styler y pasamos a utilizar QGIS para la simbolización y exportación del SLD para Geoserver.

A continuación se muestra una serie de vídeos pertenecientes al módulo 7 del curso de Infraestructuras de datos espaciales y Geoportales, donde se crean estilos de varios tipos, se utilizan las nuevas características de control de escalas de visualización y se edita manualmente el SLD para mejorar la leyenda.

En los vídeos se utiliza la versión 3.2 de QGIS, pero con la versión posteriores se han soportados más características del SLD como la simbolización de capas en formato ráster  (QGIS 3.6)

 

  

posted by on Blog

No comments

En este apartado se van a realizar algunas pruebas de medición de tiempo de ejecución de predicados y operadores espaciales con el tipo geography.

Es una obviedad que cualquier operación sobre el esferoide que requiera el cálculo de una distancia u obtención de un punto a partir de un azimut empleará mucho más tiempo que el simple cálculo mediante geometría plana que realiza en el tipo geometry.

En este artículo se realiza una simple pero suficiente comparación para que el lector tenga una idea de que orden de magnitud de aumento del tiempo empleado en el cálculo computacional se está hablando.

Para el ejercicio vamos a cargar en PostGIS, las capas rioschegeog (rioschegeog.sql) que es la misma capa que riosche pero al igual que se ha realizado con la capa meteoche y meteochgeog, se ha convertido al tipo geography en 4326.

De la misma forma se carga la capa nucleoschegeog (nucleoschegeog.sql) que contiene los núcleos de población (capa poligonal).

Pues encontrar los ficheros sql de las capas en los datos del libro de PostGIS.

Se van a realizar dos cálculos de obtención de los 5 vecinos más próximos entre dos capas.

  • Cálculo A. Mediante consultas laterales y radio de búsqueda (comandos ST_DWithin y ST_Distance). Hemos creado la siguiente consulta (sustituid capa1 y capa2 por meteoche-riosche, nucleosche-riosche, meteochegeog-rioschegeog y nucleoschjegeog-rioschegeog para obtener las consultas de la tabla de resultados. 
  • select m.gid as gida, gidb, distance,indice
         from capa1 m, lateral
          ( select r.gid as gidb, st_distance (r.geom, m.geom) as distance,
                                  ROW_NUMBER() over () as indice
              from capa2 r
                 where st_dwithin (r.geom, m.geom, 100)
              order by st_distance (r.geom, m.geom) limit 5            
          ) as tabla
          order by gida;
  • Cálculo B. Mediante el operador <-> de tipo KNN que no necesita radio de búsqueda. Igual que antes sustituid los nombres de las capas por las correspondientes.
    select m.gid as gida, gidb, distance, indice
         from capa1 m, lateral
          ( select r.gid as gidb, st_distance (r.geom, m.geom) as distance,
                                  ROW_NUMBER() over () as indice
              from capa2 r
               order by m.geom <-> r.geom limit 5                
          ) as tabla
       order by gida;

Para los cálculos con el tipo geometry se calcula para cada punto de meteoche los 5 tramos de ríos más cercanos y también para cada polígono de nucleosche los 5 tramos de ríos más cercanos.

La misma tarea se realiza con el tipo geography pero con las capas meteochegeog-rioschegeog y nucleoschegeog-rioschegeog.

 

Capas
Cálculo A (radios de búsqueda)
Cálculo B
 ( KNN <-> )
100
1000
10000
Cálculos planos con geometry (resultados en segundos)
meteoche-riosche
0.035
0.050
0.320
0.240
nucleosche-riosche
3.620
5.150
23.975
15.400
Cálculos sobre el esferoide con geography (resultados en segundos)
meteochegeog-rioschegeog
0.200
0.440
6.155
2.490
nucleoschegeog-rioschegeog
125.230
171.500
778.360
1317.380

Se puede ver como en el mejor de los casos el tipo geography es unas 6 veces más lento y en el peor hasta 6200 veces más lento. Cuando se utiliza la capa de núcleos en lugar de las estaciones los resultados son más extremos, ya que cada geometría tiene muchos puntos (no un único punto como cada estación) y por tanto produce un cálculo más intensivo de las distancias.

Con el tipo geography, el método B (KNN) es más lento que el método A (radio de búsqueda) en todos los casos menos uno (radio 10000 m. y capa meteochegeog). Lo cual hace pensar sobre si su uso es adecuado con el tipo geography. Con el tipo geometry ocurre algo parecido pero menos marcado y en menos casos.

Por último, los operadores espaciales ST_Buffer, ST_Intersection, etc. aplicados al tipo geography, etc. además de no dar resultados exactos sobre el esferoide, pueden ejecutarse varias veces más lentos como mínimo debido al doble proceso de transformación de coordenadas que llevan implícito.

 

English Translation:

In this section, we will perform some tests of the running time of predicates and space operators with the geography type.

It is obvious that any operation on the spheroid that requires the calculation of a distance or obtaining a point from an azimuth will use much more time than the simple calculation using flat geometries (geometry type).

In this article, a simple but sufficient comparison is made so that the reader has an idea about the increasing time used with the calculations (geography type).

For the exercise, we will load in PostGIS, the layers rioschegeog, meteochegeog, nucleoschegeog which are the same layer as riosche, meteoche and nucleosche but they have been transformed to the geography type (srid 4326).

You can download de SQL files from PostGIS Book.

Two calculations will be made to obtain the 5 closest neighbors between two layers.

  • Calculation A. Through lateral queries and search radius (commands ST_DWithin and ST_Distance). We have created the following query (just change the layer1 and layer2 names for meteoche-riosche, nucleosche-riosche, meteochegeog-rioschegeog and nucleoschjegeog-rioschegeog to obtain the queries.
    select m.gid as gida, gidb, distance,indice
         from capa1 m, lateral
          ( select r.gid as gidb, st_distance (r.geom, m.geom) as distance,
                                  ROW_NUMBER() over () as indice
              from capa2 r
                 where st_dwithin (r.geom, m.geom, 100)
              order by st_distance (r.geom, m.geom) limit 5            
          ) as tabla
          order by gida;
  • Calculation B. Using the <-> KNN operator that does not need a search radius. As before, replace the names of the layers with the corresponding ones.
    select m.gid as gida, gidb, distance, indice
         from capa1 m, lateral
          ( select r.gid as gidb, st_distance (r.geom, m.geom) as distance,
                                  ROW_NUMBER() over () as indice
              from capa2 r
               order by m.geom <-> r.geom limit 5                
          ) as tabla
       order by gida;

For calculations with the geometry type, the 5 closest river are calculated for each meteoche point and for each nucleosche polygon.

The same task is done with the geography type but with the meteochegeog-rioschegeog and nucleoschegeog-rioschegeog layers.

 

Layers
(search radius)
B ( KNN <-> )
100
1000
10000
Flat calculations with geometry (results in seconds).
meteoche-riosche
0.035
0.050
0.320
0.240
nucleosche-riosche
3.620
5.150
23.975
15.400
Calculations on the spheroid with geography (results in seconds)
meteochegeog-rioschegeog
0.200
0.440
6.155
2.490
nucleoschegeog-rioschegeog
125.230
171.500
778.360
1317.380

You can see how in the best case the geography type is about 6 times slower and at worst up to 6200 times slower. When the nucleos layer is used instead of the stations, the results are more extreme, since each geometry has many points (not a single point like each station) and therefore produces a more intensive calculation of the distances

With the geography type, the method B (KNN) is slower than method A (search radius) in all cases but one (radius 10000 m and meteochegeog layer). With the geometry type, something similar occurs but less exaggerated.

Finally, the spatial operators ST_Buffer, ST_Intersection, etc. applied to geography type, etc., in addition to not giving exact results on the spheroid, they can be executed several times slower at least due to the double process of transformation of coordinates.