Page 1 of 1 (5 posts)

  • talks about »
  • sem categoria

Tags

Last update:
Tue Mar 28 06:55:10 2017

A Django site.

QGIS Planet

QGIS Top Features 2015

EN | PT

With the release of the first long term release (2.8 LTR), and two other stable versions (2.10 and 2.12), 2015 was a great (and busy) year for the QGIS community, with lots of improvements and new features landing on QGIS source code.

As a balance, I have asked users to choose wich were their favorite new features during 2015 (from the visual changelogs list). As a result I got the following Top 5 features list.

5 – Python console improvements (2.8)

Since QGIS 2.8, we can drag and drop python scripts into QGIS window and they will be executed automatically. There is also a new a toolbar icon in the plugins toolbar and a shortcut ( Ctrl-Alt-P) for quick access to the python console.

4 – Processing new algorithms (2.8)

Also in QGIS 2.8, there were introduced some new algorithms to the processing framework. If you are into spatial analysis this must have done your day (or year).

  • Regular points algorithm
  • Symmetrical difference algorithm
  • Vector split algorithm
  • Vector grid algorithm
  • Hypsometric curves calculation algorithm
  • Split lines with lines
  • Refactor fields attributes manipulation algorithm

3 – Show rule-based renderer’s legend as a tree (2.8)

There were introduced a few nice improvements to QGIS legend. Version 2.8 brought us a tree presentation for the rule-based renderer. Better still, each node in the tree can be toggled on/off individually providing for great flexibility in which sublayers get rendered in your map.

2 – Advanced digitizing tools (2.8)

If you ever wished you could digitize lines exactly parallel or at right angles, lock lines to specific angles and so on in QGIS? Since QGIS 2.8 you can! The advanced digitizing tools are a port of the CADinput plugin and adds a new panel to QGIS. The panel becomes active when capturing new geometries or geometry parts.

Untitled

1 – Rule-based labeling (2.12)

This was a very awaited feature (at least by me), and it was voted by the majority of users. Since 2.12, you can style features labels using rules. This gives us even more control over placement and styling of labels. Just like the rule based cartographic rendering, label rules can be nested to allow for extremely flexible styling options. For example, you can render labels differently based on the size of the feature they will be rendered into (as illustrated in the screenshot).

image25

There were other new features that also made the delight of many users. For example, the Improved/consistent projection selection (2.8), PostGIS provider improvements (2.12), Geometry Checker and Geometry Snapper plugins (2.12), and Multiple styles per layer (2.8).

Don’t agree with this list? You can still cast your votes. You can also check the complete results in here.

Obviously, this list means nothing at all. I was a mere exercise as with such a diverse QGIS crowd it would be impossible to build a list that would fit us all. Besides, there were many great enhancements, introduced during 2015, that might have fallen under the radar for most users. Check the visual changelogs for a full list of new features.

On my behalf, to all developers, sponsors and general QGIS contributors,

THANK YOU VERY MUCH FOR YOUR TREMENDOUS WORK!

I wish you a fantastic (and productive) 2016.


Getting multipolygon vertexes using PostGIS

EN | PT

Today I needed to create a view in PostGIS that returned the vertexes of a multi-polygon layer. Besides, I needed that they were numerically ordered starting in 1, and with the respective XY coordinates.

Screenshot from 2015-11-05 23:58:19

It seemed to be a trivial task – all I would need was to use the ST_DumpPoints() function to get all vertexes – if it wasn’t for the fact that PostGIS polygons have a duplicate vertex (the last vertex must be equal to the first one) that I have no interess in showing.

After some try-and-fail, I came up with the following query:

CREATE OR REPLACE VIEW public.my_polygons_vertexes AS
WITH t AS -- Transfor polygons in sets of points
    (SELECT id_polygon,
            st_dumppoints(geom) AS dump
     FROM public.my_polygons),
f AS -- Get the geometry and the indexes from the sets of points 
    (SELECT t.id_polygon,
           (t.dump).path[1] AS part,
           (t.dump).path[3] AS vertex,
           (t.dump).geom AS geom
     FROM t)
-- Get all points filtering the last point for each geometry part
SELECT row_number() OVER () AS gid, -- Creating a unique id
       f.id_polygon,
       f.part,
       f.vertex,
       ST_X(f.geom) as x, -- Get point's X coordinate
       ST_Y(f.geom) as y, -- Get point's Y coordinate
       f.geom::geometry('POINT',4326) as geom -- make sure of the resulting geometry type
FROM f 
WHERE (f.id_polygon, f.part, f.vertex) NOT IN
      (SELECT f.id_polygon,
              f.part,
              max(f.vertex) AS max
       FROM f
       GROUP BY f.id_polygon,
                f.part);

The interesting part occurs in the WHERE clause, basically, from the list of all vertexes, only the ones not included in the list of vertexes with the maximum index by polygon part are showed, that is, the last vertex of each polygon part.

Here’s the result:

Screenshot from 2015-11-05 23:58:40

The advantage of this approach (using PostGIS) instead of using “Polygons to Lines” and “Lines to points” processing tools is that we just need to change the polygons layer, and save it, to see our vertexes get updated automatically. It’s because of this kind of stuff that I love PostGIS.


Multiple format map series using QGIS 2.6 – Part 2

EN | PT

In my last post, I have tried to show how I used QGIS 2.6 to create a map series where the page’s orientation adapted to the shape of the atlas features. This method is useful when the final scale of the maps is irrelevant, or when the size of the atlas elements is  similar, allowing one to use a fixed scale. On the other hand, when using a fixed scale is mandatory and the features size are too different, it is needed to change the size of the paper. In this second part ot the post, I will try to show how I came to a solution for that.

As a base, I used the map created in the previous post, from which I did a duplicate. To exemplify the method, I tried to create a map series at 1:2.000.000 scale. Since I was going to change both width and height of the paper, I did not need to set an orientation, and therefore, I deactivated the data defined properties of the orientation option:

ith some maths with the map scale, the size of the atlas feature and the already defined margins, I came up with the following expressions to use, respectively,  in width and height:

((bounds_width( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1 + 10
((bounds_height( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1 + 30

Allow me to clarify. (bounds_width( $atlasgeometry ) / 2000000.0) is the atlas feature’s width in meters when represented at 1:2.000.000. This is multiplied by 1000 to convert it to millimeters (the composer’s settings units). In order to keep the atlas feature not to close to the margin, I have decided to add 10% of margin around it, hence the multiplication by 1.1. To finish I add the map margins value that were already set in the previous post (i.e.,20 mm, 5 mm, 10 mm, 5 mm)

As one can see from the previous image, after setting the expressions in the paper width and height options, it’s size already changed according to the size of the atlas features. But, as expected, all the itens stubbornly kept their positions.For that reason, it has been necessary to change the size and position expressions for each of then.

Starting by the map item size, the expressions to use in width and height were not difficult to understand since they would be the paper size without the margins size:

((bounds_width( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1
((bounds_height( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1

Screenshot from 2014-11-16 23:07:43

To position the items correctly, all was needed was to replace the “CASE WHEN … THEN … END” statement by the expressions defined before. For instance, the expressions used in the X and Y options for the legend position:

(CASE WHEN  bounds_width(  $atlasgeometry ) >=  bounds_height( $atlasgeometry) THEN 297 ELSE 210 END) - 7
(CASE WHEN  bounds_width(  $atlasgeometry ) >=  bounds_height( $atlasgeometry) THEN 210 ELSE 297 END) - 12

Became, respectively:

(((bounds_width( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1 + 10) - 7
(((bounds_height( $atlasgeometry ) / 2000000.0) * 1000.0) * 1.1 + 30) - 12

Screenshot from 2014-11-16 23:22:40

Changing the expressions of the X and Y position options for the remaining composer’s items I have reached the final layout.

alaska_region_Kenai Peninsula

Once again, printing/exporting all (25) maps was only one click away.

mosaico_regioes_fixed

Since QGIS allows exporting the composer as georeferenced images, opening all maps in QGIS I got this interesting result.

Screenshot from 2014-11-17 00:02:38

As one can see by the results, using this method, we can get some quite strange formats. That is why in the 3rd and last post of this article, I will try to show how to create a fixed scale map series using standard paper formats (A4, A3, A2, A1 e A0).

Disclaimer: I’m not an English native speaker, therefore I apologize for any errors, and I will thank any advice on how to improve the text.


Fourth report

What do I have completed this week?

  • The progress signal is successfully connected to both progress bar (when running from the console) and AlgorithmDialog (When using the processing toolbox).
  • Fixed the bug that makes the algorithm return “None”.
  • Fixed the bug that makes QGIS crash (sometimes) after the first time we run the algorithm.
  • The multithreading on the AlgorithmDialog seems to work fine.
  • More general implementation that allows to test the multithreading with any algorithm.

What am I going to achieve for the next week?

  • Solve the issue with the outputs.
  • Figure out why the processAlgorithm is not being called.
  • Test the algorithms on python console and AlgorithmDialog.
  • Bug fixes.

Is there any blocking issue?

  • Problem loading the outputs from the algorithm.
  • Have some university deadlines that may affect my work time on the project.

 


Third report

What do I have completed this week?

  • Using signals from the GeoAlgorithm to print the progress on QGIS python console
  • Code refactoring
  • Debugging
  • Multithread when running the algorithm through the AlgorithmDialog

What am I going to achieve for the next week?

  • Finish the multithread on the AlgorithmDialog
  • Connect the progress signal to the progress bar
  • Fix a bug that makes QGIS crash (sometimes) after the first time we run the algorithm
  • Fix a bug that makes the algorithm return “None”

Is there any blocking issue?

Last week I had less time to work on the project due to my university exams and projects. I still have some university projects to finish till the end of the semester that may affect GSoC in the next week.


  • Page 1 of 1 ( 5 posts )
  • sem categoria

Back to Top

Sponsors