Last update:
Mon Dec 23 19:30:28 2024
•
•
•
•
Today was the last day of the Vienna code sprint which brought together OSGeo developers from many projects. It’s been a great week thanks to organizers and sponsors!
The QGIS team was extremely busy working on the project’s web infrastructure (e.g. new plugins.qgis.org website) as well as hunting down and fixing bugs.
Check out some impressions on twitter.
More pictures on the official blog: vienna2014.sprint.osgeo.org
If you are looking for a tool to easily create 3D visualizations of your geodata, look no further! Qgis2threejs is a plugin by Minoru Akagi which exports terrain data combined with the map canvas image and optional vector data to an html file which can be viewed in 3D in any web browser which supports WebGL. To do that, this plugin uses the Three.js library.
This is the result of my first experiments with Qgis2threejs. In the following sections, I will show the steps to reproduce it.
click for the interactive version (requires WebGL-capable browser)
The building blocks of this visualization are:
Load all datasets into QGIS.
Qgis2threejs will overlay the map (as rendered in the QGIS map area) on top of the elevation model. You can combine any number of layers to create your map. I just loaded a basemap.at WMTS and a hillshade layer. To add a nice tree shadow effect, I also added the tree layer (dark grey, 50% transparency, multiply blending).
The vector features in the visualization are buildings and trees. The buildings are based on an OSM building layer. The trees are create from two point layers: one point layer to create the tree trunks (cylinder shape) and a duplicate of this point layer to create the tree crowns (sphere shape).
Load the data and choose the desired fill colors.
Now we can start Qgis2threejs. The first tab is used to configure the terrain. Just pick the correct elevation data layer. I didn’t modify any of the other default settings.
The second tab provides the settings for the vector data. As mentioned in the previous section, the trees are created from two point layers and the buildings are based on a polygon layer. The tree crowns are spheres with a radius size 3 and a z value of 5 above the surface. The tree trunks are cylinders. Finally, the buildings have a height of 10.
That’s it! Just press “run” and wait. When the export is finished, your default browser (or a different one, if you specify another one in the plugin settings) will open automatically and display the results.
The visualization is interactive. You can tilt the visualization using the left mouse button, pan using the right mouse button, and zoom using the mouse wheel. I found that Firefox used around 1.6 GB of RAM to render this example.
In the browser window, you will see where Qgis2threejs stored the html and associated Javascript files. To share your visualization, you just need to copy these files onto a webserver.
I would love to see what you come up with. Please share a link in the comments.
QGIS 2.2 is now available for Windows through OSGeo4W installer. Packages for other systems are being prepared by the package maintainers.
The Windows packages are currently marked experimental, so you have to use the advanced install in OSGeo4W and check the ‘Exp’ radio button on the top to install them.
As release manager Jürgen Fischer announced:
Please test and report problems, so that I can soon promote them to ‘curr’ent.
Once that has happend, I’ll proceed with turning them into standalone
installers.
QGIS 2.2 will be released tomorrow, February 21st. Following the release of 2.0, the QGIS project decided to move to a time-based release plan with releases every four months. This provides a clear framework for developers, translators and documenters which makes it possible to plan ahead and know when tasks have to be finished to be included in a release version.
Similar to the 2.0 release, the project has invested considerable resources to make 2.2 “Valmiera” a successful release. I have already blogged about some of the great new features. Thanks to the project donors and sponsors it was also possible to fund developer time for many important bug fixes.
One of the greatest resources of the QGIS project are its users. One group that deserves our special thanks is the Swiss QGIS User Group. They collect a modest annual membership fee which provides a steady and growing crowd-funding that can be used to positively influence the QGIS project. For example, they invested in bug fixing for 2.0 and they are co-funding work on multi-threaded rendering for QGIS 2.4.
With the rise of new QGIS user groups “QUGs” all around the world, e.g. in Australia, the UK, and the US, I hope these groups will find ways to bring users together and to positively influence the development of QGIS towards the next releases.
This weekend, I had the pleasure to join Tim Sutton for the second edition of the QGIS Podcast. Every episode, the podcast aims to summarize the latest mailing list discussions and greatest new features.
This episode’s topics include: new CAD tools, usability and the new UX mailing list, new QGIS user groups (QUGs), point cloud support plans, and QGIS design.
If you would like to ask a question or suggest a topic, you can write to [email protected].
With the major release of version 2.0, QGIS is once more returning to a fast release cycle. You can find the project road map on qgis.org. The QGIS 2.2 release is scheduled for Feb, 21st and we are already in feature freeze. This means that now is the time to get the nightly version, do some testing and report possible bugs before the new version is being shipped.
Like for version 2.0, the QGIS team has prepared a great visual change log listing many new features. For me, one of the feature highlights is the possibility to export maps with world files from Print Composer because it means that we can finally create high-resolution, georeferenced images comfortably from within the application.
Another feature which will help save a lot of time is the ability to invert color ramps. So far, we had to recreate the color ramp or use work-arounds involving expression-based color settings to achieve the same effect.
These are just my personal favorites. If you haven’t checked out the change log yet, I certainly encourage you to have a look and decide for yourself. Also, if you find the time, please help by testing and reporting any issues you encounter. This way, we can all help to make 2.2 another successful release.
OSM place search and osmSearch are two plugins for QGIS which use the Nominatim service to find addresses and places. They are both still marked as “experimental” plugins, so users are expected to expect the unexpected.
Once installed, both plugins look very similar: There is an input text field and a results list.
A simple search with street name and house number returns the expected results. Interacting with the result shows some differences:
Both plugins can deal with umlauts (ä,ö,ü) but only osmSearch works with háčeks.
A nice feature of osmSearch is that it remembers your previous searches and offers an auto-complete function.
OSM place search on the other hand offers a reverse “Where am I” function (the arrow pointing to the left” which tries to find a name for the current map center location. Additionally, there are functions to add the current object as a new layer or mask layer.
Both plugins have strong and weak points. Combined, they would make a really strong tool but then nothing prevents us from having them both and choosing the best one for the task at hand.
Profile Tool is a plugin for QGIS which makes it possible to generate (elevation) profiles for line features. The plugin is available through the default QGIS plugin repository. While testing the plugin, I found some aspects of using the tool might require additional instructions.
After installing and enabling the plugin, you will find the “Terrain profile” button in the plugin toolbar:
The basic use case is as follows:
If you want to add another raster layer to the plugin, you need to first select the raster layer in the QGIS layer list and then press the “Add Layer” button in the Profile Tool panel.
To generate the profile for an existing line feature, you need to change the selection mode from “Temporary polyline” to “Selected polyline”. Then you need to select the vector layer which contains the line feature you want to use in the QGIS layer list. Finally, you can click on the line feature in the map area to select it. (Note that this selection is independent of any selections you might have going on using the default QGIS feature selection tools.)
If you change from the Profile Tool to any other tool such as “Pan Map” or “Identify”, you have to click the “Terrain profile” button again to re-enable drawing/selection a line for the Profile Tool.
Due to a bug, it is currently not possible to export the profile graph. An alternative is to open the “Table” tab of the Profile Tool panel which provides access to the profile data and copy the data into your preferred graphing application such as Calc or Excel.
If you want to see the Profile Tool in action, I recommend watching the introduction video by Lene Fischer (University of Copenhagen).
Since I finally managed to download the elevation model of the city of Vienna, I thought I’d share some eye candy with you: The map uses layer blending to combine hillshade and elevation raster, and the elevation raster’s color ramp is a modified “garish14″ from QGIS’ cpt-city color ramp collection.
Update
Here is how you get access to the “garish14″ color ramp:
Start by selecting the “new color ramp” option in the raster’s style window.
Chose the “cpt-city” color ramp type.
In the “cpt-city color ramp” window, you will find lots of different premade color ramps. “garish14″ is part of the “Topography” collection.
In my previous post, I presented a Processing model to determine positional accuracy of street networks. Today, I’ll cover another very popular tool to assess OSM quality in a region: network length comparison. Here’s the corresponding slide from my FOSS4G presentation which shows an example of this approach applied to OSM and OS data in the UK:
One building block of this tool is the Total graph length model which calculates the length of a network within specified regions. Like the model for positional accuracy, this model includes reprojection steps to ensure all layers are in the same CRS before the actual geoprocessing starts:
The final Compare total graph length model combines two instances of “Total graph length” whose results are then joined to eventually calculate the length difference (lenDIFF).
As usual, you can find the models on Github. If you have any questions, don’t hesitate to ask in the comments and if you find any issues please report them on Github.
Over the last years, research on OpenStreetMap data quality has become increasingly popular. At this year’s FOSS4G, I had the honor to present some work we did at the AIT to assess OSM quality in Vienna, Austria. In the meantime, our paper “Towards an Open Source Analysis Toolbox for Street Network Comparison” has been published for early access. Thanks to the conference organizers who made this possible! I’ve implemented comparison tools found in related OSM literature as well as new tools for oneway street and turn restriction comparison using Sextante scripts and models for QGIS 1.8. All code is available on Github to enable collaboration. If you are interested in OSM data quality research, I’d like to invite you to give the tools a try.
Since most users probably don’t have access to QGIS 1.8 anymore, I’ll be updating the tools to QGIS 2.0 Processing. I’m starting today with the positional accuracy comparison tool. It is based on a method described by Goodchild & Hunter (1997). Here’s the corresponding slide from my FOSS4G presentation:
The basic idea is to evaluate the positional accuracy of a street graph by comparing it with a reference graph. To do that, we check how much of the graph lies within a certain tolerance (buffer) of the reference graph.
The processing model uses the following input: the two street graphs which should be compared, the size of the buffer (tolerance for positional accuracy), a polygon layer with analysis regions, and the field containing the region id. This is how the model looks in Processing modeler:
First, all layers are reprojected into a common CRS. This will have to be adjusted if the tool is used in other geographic regions. Then the reference graph is buffered and – since I found that dissolving buffers directly in the buffer tool can become very slow with big datasets – the faster difference tool is used to dissolve the buffers before we calculate the graph length inside the buffer (inbufLEN) as well as the total graph length in the analysis region (totalLEN). Finally, the two results are joined based on the region id field and the percentage of graph length within the buffered reference graph (inbufPERC) is calculated. A high percentage shows that both graphs agree very well geometrically.
The following image shows the tool applied to a sample of OpenStreetMap (red) and official data published by the city of Vienna (purple) at Wien Handelskai. OSM was used as a reference graph and the buffer size was set to 10 meters.
In general, both graphs agree quite well. The percentage of the official graph within 10 meters of the OSM graph is 93% in the 20th district. In the above image, we can see that links available in OSM are not contained in the official graph (mostly pedestrian/bike links) and there seem to be some connectivity issues as well in the upper right corner of the image.
In my opinion, Processing models are a great solution to document geoprocessing work flows and share them with others. If you want to collaborate on building more models for OSM-related analysis, just leave a comment bellow.
I’m very pleased to announce that Packt Publishing is organizing a giveaway contest for Learning QGIS 2.0. All you need to do is comment below the post and win a free copy of Learning QGIS 2.0. Read on for more details.
Amongst other topics, Learning QGIS 2.0 covers:
Simply post your expectations for this book in comments section below and you could be one of the lucky participants to win a copy.
DeadLine: The contest will close in 7 days on December, 12th 2013. Winners will be contacted by email, so be sure to use your real email address when you comment!
Please note: Winners residing in the USA and Europe will receive print copies. Others will be provided with eBook copies.
Processing has received a series of updates since the release of QGIS 2.0. (I’m currently running 2.0-20131120) One great addition I want to highlight today is the improved script editor and the help file editor.
The improved script editor features a toolbar with commonly used tools such as undo and redo, cut, copy and paste, save and save as …, as well as very useful run algorithm and edit script help buttons. It also shows the script line numbers which makes it easier to work with while debugging code.
The model editor has a similar toolbar now which allows to export the model representation as an image, run the model or edit the model help.
When you press the edit script help button, you get access to the new help editor. It’s easy to use: On the top, it displays the current content of the help file. On the bottom-left, it lists the different sections of the help file which can be filled with information. In the input parameters and outputs section, the help editor automatically lists the all parameters specified in the script code. Finally, in the bottom-right, you can enter the description. The resulting help file is saved in the same location as the original script under the name <scriptname>.py.help.
It has been a real pleasure to chat with Caitlin Dempsey at GIS Lounge about open source GIS and how I got hooked on QGIS.
In related news: It’s great to see the many great and creative contributions to the QGIS Map Showcase on Flickr! If you have some maps you are proud of, please share them with the community. If you would like to see your image reused on the QGIS website or in other QGIS marketing material, please choose an appropriate license for your image.
I’ve also started to work on a new Processing script that identifies similar line features. It currently uses a length comparison and the Hausdorff distance between two line features to calculate the similarity value, but more on that in a future post!
Did you know that there is a network analysis library in QGIS core? It’s well hidden so far, but at least it’s documented in the PyQGIS Cookbook. The code samples from the cookbook can be used in the QGIS Python console and you can play around to get a grip of what the different steps are doing.
As a first exercise, I’ve decided to write a Processing script which will use the network analysis library to create a network-based route layer from a point layer input. You can find the result on Github.
You can get a Spatialite file with testdata from Github as well. It contains a network and a routepoints1 layer:
The interface of the points_to_route tool is very simple. All it needs as an input is information about which layer should be used as a network and which layer contains the route points:
The input points are considered to be ordered. The tool always routes between consecutive points.
The result is a line layer with one line feature for each point pair:
The network analysis library is a really great new feature and I hope we will see a lot of tools built on top of it.
Yesterday, I received an interesting QGIS question:
is there a way to make road label font size depending on road lenght (with osm layer)?
Indeed, it could be interresting to see all roads, even the smallest, on a city map rendering.
Thanks to the data-defined labeling capabilities of the new QGIS version, we can!
Just click the slightly weird symbol right of the label text size and select Edit …
Since OSM data is in WGS84 by default, street length will be measured in degrees and therefore the values will be small. To get to a reasonable font size, I selected $length * 1000.
The second part of the question can be addressed using a setting in the Rendering section which is – very descriptively – called “Show all labels for this layer (including colliding labels)”.
While I doubt that this simple method alone will create a great road map, I think it’s still an interesting exercise with sometimes surprising results.
This post describes the three simple steps necessary to create a vintage-looking map using the blending feature in QGIS 2.0′s print composer. This is what we are aiming for:
1. Prepare the map
Like any other map, this one starts in the QGIS main window. Try to stick with earthy colors which will go well with the old paper look. For labels, try fonts which look like handwriting.
Once you are happy with your map
2. Prepare the composition background
To get that vintage feel, we need a background image with a great texture. You can find such textures on sites like lostandtaken.com. Download one you like and add it to an empty print composer. Make sure it covers the whole paper:
Lock the image by right-clicking it once – a small lock icon should appear in the upper left corner.
3. Finish the composition
The final step is to add the map on top of the background image. To make our nice background texture shine through, we enable the “multiply” blending mode in the map’s rendering options:
Feel free to add north arrows or drawings of dragons as finishing touches.
This post covers a simple approach to calculating isochrones in a public transport network using pgRouting and QGIS.
For this example, I’m using the public transport network of Vienna which is loaded into a pgRouting-enable database as network.publictransport. To create the routable network run:
select pgr_createTopology('network.publictransport', 0.0005, 'geom', 'id');
Note that the tolerance parameter 0.0005 (units are degrees) controls how far link start and end points can be apart and still be considered as the same topological network node.
To create a view with the network nodes run:
create or replace view network.publictransport_nodes as select id, st_centroid(st_collect(pt)) as geom from ( (select source as id, st_startpoint(geom) as pt from network.publictransport ) union (select target as id, st_endpoint(geom) as pt from network.publictransport ) ) as foo group by id;
To calculate isochrones, we need a cost attribute for our network links. To calculate travel times for each link, I used speed averages: 15 km/h for buses and trams and 32km/h for metro lines (similar to data published by the city of Vienna).
alter table network.publictransport add column length_m integer; update network.publictransport set length_m = st_length(st_transform(geom,31287)); alter table network.publictransport add column traveltime_min double precision; update network.publictransport set traveltime_min = length_m / 15000.0 * 60; -- average is 15 km/h update network.publictransport set traveltime_min = length_m / 32000.0 * 60 where "LTYP" = '4'; -- average metro is 32 km/h
That’s all the preparations we need. Next, we can already calculate our isochrone data using pgr_drivingdistance, e.g. for network node #1:
create or replace view network.temp as
SELECT seq, id1 AS node, id2 AS edge, cost, geom
FROM pgr_drivingdistance(
'SELECT id, source, target, traveltime_min as cost FROM network.publictransport',
1, 100000, false, false
) as di
JOIN network.publictransport_nodes pt
ON di.id1 = pt.id;
The resulting view contains all network nodes which are reachable within 100,000 cost units (which are minutes in our case).
Let’s load the view into QGIS to visualize the isochrones:
The trick is to use data-defined size to calculate the different walking circles around the public transport stops. For example, we can set up 10 minute isochrones which take into account how much time was used to travel by pubic transport and show how far we can get by walking in the time that is left:
1. We want to scale the circle radius to reflect the remaining time left to walk. Therefore, enable Scale diameter in Advanced | Size scale field:
2. In the Simple marker properties change size units to Map units.
3. Go to data defined properties to set up the dynamic circle size.
The expression makes sure that only nodes reachable within 10 minutes are displayed. Then it calculates the remaining time (10-"cost") and assumes that we can walk 100 meters per minute which is left. It additionally multiplies by 2 since we are scaling the diameter instead of the radius.
To calculate isochrones for different start nodes, we simply update the definition of the view network.temp.
While this approach certainly has it’s limitations, it’s a good place to start learning how to create isochrones. A better solution should take into account that it takes time to change between different lines. While preparing the network, more care should to be taken to ensure that possible exchange nodes are modeled correctly. Some network links might only be usable in one direction. Not to mention that there are time tables which could be accounted for ;)
As mentioned in my previous post, all plugins need an update to function in QGIS master – soon to be 2.0. The OpenLayers plugin is one of the most popular plugins but so far has not been updated by the developer. If you miss it, you can get a fixed version from qgis.nl Temporary Fix for OpenLayers Plugin thanks to Richard!
As I’m sure you have already heard, QGIS 2.0 will come with a new Python API including many improvements and a generally more pythonic way of doing things. But of course that comes with a price: Old plugins (pre 2.0) won’t work anymore unless they are updated to the new version. Therefore all plugin developers are encouraged to take the time and update their plugins. An overview of changes and howto for updates is available on the QGIS wiki.
TimeManager for QGIS 2.0 will be available from day 1 of the new release. I’ve tested the usual work flows but don’t hesitate to let me know if you find any problems. The whole update process took two to three hours … sooo many signals to update … but all in all, it was far less painful than expected, thanks to everyone who contributed to the wiki update instructions!
