Mapfish Appserver is a platform for building web mapping applications using OGC standards and the Mapfish REST protocol.

Slides from FOSSGIS 2013 in Rapperswil (in german).

Der GeoPackage-Standard ist im Januar 2013 vom OGC als Draft veröffentlicht worden. Er vereint die Speicherung von Vektor- und Rasterdaten im verbreiteten SQLite DB-Fileformat. Vektoren werden im SpatiaLite-Format und Rasterdaten wie MBTiles gespeichert.

Präsentation

Der GeoPackage-Standard ist im Januar 2013 vom OGC als Draft veröffentlicht worden. Er vereint die Speicherung von Vektor- und Rasterdaten im verbreiteten SQLite DB-Fileformat. Vektoren werden im SpatiaLite-Format und Rasterdaten wie MBTiles gespeichert.

Präsentation

QGIS 2.0 has under gone some radical changes for its upcoming release. Some of these major changes relate to the API, both C++ and Python. Something that always comes up when trying to improve an API is the chance that you might have to remove the old way of doing something so that things are cleaner and improved for the future. These changes will always break existing working code and can be a burden for a little while until everything is adjusted. A little pain for a lot of gain is the way I like to think about it. I will also add that breaking API so radically isn't something that we, as developers, like to do or take lightly, but sometimes it has to be done.

This post is a summary of some of the new APIs, what has changed, and what it means to you as a user.

New Vector API (Iterator pattern)

We would like to introduce multithreaded rendering in the future and the old API for getting a set of features from the provider wasn't going to cut it in a multithreaded environment. In order to allow something that will be more threadable then the old select model we changed to a iterator pattern.

The old used to look like this:

layer.select()
for feature in layer:
    print feature

select() wouldn't return anything rather it would tell the provider of the layer to get ready to return some features when asked e.g the for loop. Want to thread that? Nope. Not going to happen.

The solution:

Create a method that returns an iterator that each thread can loop over on their own without changing the result of the other.

features = layer.getFeatures()
for feature in features:
    print feature

if you look at layer.getFeatures() you can see it returns a QgsFeatureIterator

>>> layer.getFeatures()
<qgis.core.QgsFeatureIterator object at 0x1A05F810>

QgsFeatureIterator has a next() method, just like a normal Python iterator, which you can call to get the next feature, it will just serve them up as you need them.

>>> features = layer.getFeatures()
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062CD8>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C48>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C00>
>>> features.close()

So in the future (you can't do this yet due to some other restrictions):

>>> features = layer.getFeatures()
>>> features2 = layer.getFeatures()
>>> features.next().id()
1L
>>> features.next().id()
2L
>>> features2.next().id()
1L

Nifty!

New Vector API (Fields)

Something else that changed was how attributes are accessed.

This is the old style:

>>> index = layer.fieldNameIndex("yourcolumn")
>>> feature.attributeMap()[index].toString()
"Hello World"

That is a big pain in the butt just to get a value from a field.

The new method now uses a list of attributes on the feature itself.

>>> feature[5]
"Hello World"
>>> feature["yourcolumn"]
"Hello World"

>>> feature.yourcolumn
"Hello World"

SIP API v2

This is the most recent change that has caused all of the 1.8 plugins to no longer work in 2.0. A bit of background: PyQt4 and pyqgis use sip to define their Python API. There are two versions of SIP V1 and V2. Using SIP V1 PyQt, and therefor pyqgis, will take and return QVariant and QString objects in Python.

So:

>>> feature["yourcolumn"]
<PyQt4.QtCore.QVariant object at 0x026AD5E0>

Well that is fine but to get a string value you had to do this:

>>> feature["yourcolumn"].toString()
"Hello World"

but that isn't a normal Python string. It's a QString. QStrings can't be used in normal Python methods so you have to do str(feature["yourcolumn"].toString()). Gross!

With the change to SIP V2 QVariant and QString are now auto converted to native Python types without any extra work.

>>> type(f["Name"])
<type 'unicode'>

Good stuff.

If you are looking for a conversion guide check out: http://hub.qgis.org/wiki/quantum-gis/PythonpluginAPIchangesfrom18to_20

The QGIS plugin repository can house both 1.8 and 2.0 plugins under the same plugin name, and the plugin installer will only download the version compatible with the QGIS version you are using.

The SIP version update was a hard one to make. On one hand we could just leave it the way it was with backwards compatibility and all the messy str(variant.toString()) stuff; OR we can make the switch now while everyone is migrating to the new vector API and have a cleaner API for the future. I picked the later. Once we switch to Python 3 at some stage in the future SIP v2 is the default so it would have broken all the plugins at that point anyway.

I can tell you that I did lose some sleep over if I should push the SIP update or not, wondering what impact it could have on plugin authors and the project in general. In the end I stand by our decision to make the update in QGIS 2.0.

Hopefully these API changes won't cause to much grief for plugin authors and the API is now better to work with.

Fine. But why I do care as a user?

All this means that when QGIS 2.0 comes out you may be missing some plugins that you used to have in 1.8 until all the plugins are migrated. If you have the skills to help updating a plugin please let the plugin author know so you can make their life easier. If you have the ability to fund a plugins update that would be excellent.

QGIS 2.0 has under gone some radical changes for its upcoming release. Some of these major changes relate to the API, both C++ and Python. Something that always comes up when trying to improve an API is the chance that you might have to remove the old way of doing something so that things are cleaner and improved for the future. These changes will always break existing working code and can be a burden for a little while until everything is adjusted. A little pain for a lot of gain is the way I like to think about it. I will also add that breaking API so radically isn't something that we, as developers, like to do or take lightly, but sometimes it has to be done.

This post is a summary of some of the new APIs, what has changed, and what it means to you as a user.

New Vector API (Iterator pattern)

We would like to introduce multithreaded rendering in the future and the old API for getting a set of features from the provider wasn't going to cut it in a multithreaded environment. In order to allow something that will be more threadable then the old select model we changed to a iterator pattern.

The old used to look like this:

layer.select()
for feature in layer:
    print feature

select() wouldn't return anything rather it would tell the provider of the layer to get ready to return some features when asked e.g the for loop. Want to thread that? Nope. Not going to happen.

The solution:

Create a method that returns an iterator that each thread can loop over on their own without changing the result of the other.

features = layer.getFeatures()
for feature in features:
    print feature

if you look at layer.getFeatures() you can see it returns a QgsFeatureIterator

>>> layer.getFeatures()
<qgis.core.QgsFeatureIterator object at 0x1A05F810>

QgsFeatureIterator has a next() method, just like a normal Python iterator, which you can call to get the next feature, it will just serve them up as you need them.

>>> features = layer.getFeatures()
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062CD8>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C48>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C00>
>>> features.close()

So in the future (you can't do this yet due to some other restrictions):

>>> features = layer.getFeatures()
>>> features2 = layer.getFeatures()
>>> features.next().id()
1L
>>> features.next().id()
2L
>>> features2.next().id()
1L

Nifty!

New Vector API (Fields)

Something else that changed was how attributes are accessed.

This is the old style:

>>> index = layer.fieldNameIndex("yourcolumn")
>>> feature.attributeMap()[index].toString()
"Hello World"

That is a big pain in the butt just to get a value from a field.

The new method now uses a list of attributes on the feature itself.

>>> feature[5]
"Hello World"
>>> feature["yourcolumn"]
"Hello World"

You can even access them like attributes.

>>> feature.yourcolumn
"Hello World"

Be careful with accessing fields via the attribute magic. If you have a id field feature.id will return the feature id method not the field named id. In fact any method with the same name as any QgsFeature methods will return the method rather then the field value. I like this magic but use it wisely.

SIP API v2

This is the most recent change that has caused all of the 1.8 plugins to no longer work in 2.0. A bit of background: PyQt4 and pyqgis use sip to define their Python API. There are two versions of SIP V1 and V2. Using SIP V1 PyQt, and therefor pyqgis, will take and return QVariant and QString objects in Python.

So:

>>> feature["yourcolumn"]
<PyQt4.QtCore.QVariant object at 0x026AD5E0>

Well that is fine but to get a string value you had to do this:

>>> feature["yourcolumn"].toString()
"Hello World"

but that isn't a normal Python string. It's a QString. QStrings can't be used in normal Python methods so you have to do str(feature["yourcolumn"].toString()). Gross!

With the change to SIP V2 QVariant and QString are now auto converted to native Python types without any extra work.

>>> type(f["Name"])
<type 'unicode'>

Good stuff.

If you are looking for a conversion guide check out: http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20

The QGIS plugin repository can house both 1.8 and 2.0 plugins under the same plugin name, and the plugin installer will only download the version compatible with the QGIS version you are using.

The SIP version update was a hard one to make. On one hand we could just leave it the way it was with backwards compatibility and all the messy str(variant.toString()) stuff; OR we can make the switch now while everyone is migrating to the new vector API and have a cleaner API for the future. I picked the later. Once we switch to Python 3 at some stage in the future SIP v2 is the default so it would have broken all the plugins at that point anyway.

I can tell you that I did lose some sleep over if I should push the SIP update or not, wondering what impact it could have on plugin authors and the project in general. In the end I stand by our decision to make the update in QGIS 2.0.

Hopefully these API changes won't cause to much grief for plugin authors and the API is now better to work with.

Fine. But why I do care as a user?

All this means that when QGIS 2.0 comes out you may be missing some plugins that you used to have in 1.8 until all the plugins are migrated. If you have the skills to help updating a plugin please let the plugin author know so you can make their life easier. If you have the ability to fund a plugins update that would be excellent.

QGIS 2.0 has under gone some radical changes for its upcoming release. Some of these major changes relate to the API, both C++ and Python. Something that always comes up when trying to improve an API is the chance that you might have to remove the old way of doing something so that things are cleaner and improved for the future. These changes will always break existing working code and can be a burden for a little while until everything is adjusted. A little pain for a lot of gain is the way I like to think about it. I will also add that breaking API so radically isn't something that we, as developers, like to do or take lightly, but sometimes it has to be done.

This post is a summary of some of the new APIs, what has changed, and what it means to you as a user.

New Vector API (Iterator pattern)

We would like to introduce multithreaded rendering in the future and the old API for getting a set of features from the provider wasn't going to cut it in a multithreaded environment. In order to allow something that will be more threadable then the old select model we changed to a iterator pattern.

The old used to look like this:

layer.select()
for feature in layer:
    print feature

select() wouldn't return anything rather it would tell the provider of the layer to get ready to return some features when asked e.g the for loop. Want to thread that? Nope. Not going to happen.

The solution:

Create a method that returns an iterator that each thread can loop over on their own without changing the result of the other.

features = layer.getFeatures()
for feature in features:
    print feature

if you look at layer.getFeatures() you can see it returns a QgsFeatureIterator

>>> layer.getFeatures()
<qgis.core.QgsFeatureIterator object at 0x1A05F810>

QgsFeatureIterator has a next() method, just like a normal Python iterator, which you can call to get the next feature, it will just serve them up as you need them.

>>> features = layer.getFeatures()
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062CD8>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C48>
>>> features.next()
<qgis.core.QgsFeature object at 0x1A062C00>
>>> features.close()

So in the future (you can't do this yet due to some other restrictions):

>>> features = layer.getFeatures()
>>> features2 = layer.getFeatures()
>>> features.next().id()
1L
>>> features.next().id()
2L
>>> features2.next().id()
1L

Nifty!

New Vector API (Fields)

Something else that changed was how attributes are accessed.

This is the old style:

>>> index = layer.fieldNameIndex("yourcolumn")
>>> feature.attributeMap()[index].toString()
"Hello World"

That is a big pain in the butt just to get a value from a field.

The new method now uses a list of attributes on the feature itself.

>>> feature[5]
"Hello World"
>>> feature["yourcolumn"]
"Hello World"

You can even access them like attributes.

>>> feature.yourcolumn
"Hello World"

Be careful with accessing fields via the attribute magic. If you have a id field feature.id will return the feature id method not the field named id. In fact any method with the same name as any QgsFeature methods will return the method rather then the field value. I like this magic but use it wisely.

SIP API v2

This is the most recent change that has caused all of the 1.8 plugins to no longer work in 2.0. A bit of background: PyQt4 and pyqgis use sip to define their Python API. There are two versions of SIP V1 and V2. Using SIP V1 PyQt, and therefor pyqgis, will take and return QVariant and QString objects in Python.

So:

>>> feature["yourcolumn"]
<PyQt4.QtCore.QVariant object at 0x026AD5E0>

Well that is fine but to get a string value you had to do this:

>>> feature["yourcolumn"].toString()
"Hello World"

but that isn't a normal Python string. It's a QString. QStrings can't be used in normal Python methods so you have to do str(feature["yourcolumn"].toString()). Gross!

With the change to SIP V2 QVariant and QString are now auto converted to native Python types without any extra work.

>>> type(f["Name"])
<type 'unicode'>

Good stuff.

If you are looking for a conversion guide check out: http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20

The QGIS plugin repository can house both 1.8 and 2.0 plugins under the same plugin name, and the plugin installer will only download the version compatible with the QGIS version you are using.

The SIP version update was a hard one to make. On one hand we could just leave it the way it was with backwards compatibility and all the messy str(variant.toString()) stuff; OR we can make the switch now while everyone is migrating to the new vector API and have a cleaner API for the future. I picked the later. Once we switch to Python 3 at some stage in the future SIP v2 is the default so it would have broken all the plugins at that point anyway.

I can tell you that I did lose some sleep over if I should push the SIP update or not, wondering what impact it could have on plugin authors and the project in general. In the end I stand by our decision to make the update in QGIS 2.0.

Hopefully these API changes won't cause to much grief for plugin authors and the API is now better to work with.

Fine. But why I do care as a user?

All this means that when QGIS 2.0 comes out you may be missing some plugins that you used to have in 1.8 until all the plugins are migrated. If you have the skills to help updating a plugin please let the plugin author know so you can make their life easier. If you have the ability to fund a plugins update that would be excellent.

Quantum QGIS, a user-friendly and full featured Open Source GIS suite, is used in a wide range of professional enterprise infrastructures. Sourcepole, located in Zurich, Switzerland, now fills the last gap, which has prevented many organizations from the use of QGIS in enterprise infrastructures so far - they offer professional support directly from QGIS core developers. With QGIS Enterprise long term support and maintenance, the customer gets a professionally supported and maintained GIS infrastructure based on QGIS.

QGIS is an official project of the Open Source Geospatial Foundation (OSGeo). It is developed since 2002 by a very active developer community and runs on Linux, Mac OSX, Windows and Android. It provides all features required for a desktop GIS in enterprise use. This includes interfaces to many data formats, extensive analysis functionality, support of main specifications of the Open Geospatial Consortium, numerous styling options, production of ready to print maps and extenddability via Python interface.

The upcoming QGIS Release 2.0 is the basis of the QGIS Enterprise Suite consisting of QGIS Desktop, QGIS Server and QGIS Web Client. These components are maintained by Sourcepole apart from the QGIS community project. Backward compatibility to QGIS 1.8 (Lisboa) plays a major role, because most existing plugins, will not be compatible with the upcoming QGIS community version 2. QGIS Enterprise is currently available for Ubuntu / Debian, RedHat 6, Windows 32bit and Windows 64bit.

Since 2003 Sourcepole is significantly involved in the development of QGIS and supports organizations from 2 to 140,000 employees in the use of QGIS. As an official committer to several OSGeo projects, Sourcepole is able to integrate customer specific extensions into the main software repositories. Improvements of QGIS Enterprise, if possible, will always go back into the QGIS community development.

www.qgisenterprise.com

Das benutzerfreundliche und funktionsreiche Quantum GIS (QGIS) bewährt sich seit mehreren Jahren im professionellen Einsatz. Die Firma Sourcepole aus Zürich füllt jetzt eine letzte Lücke, die Organisationen davon abgehalten hat QGIS in Unternehmens-Infrastrukturen einzusetzen – der professionelle Support direkt von den Kernentwicklern. Mit dem QGIS Enterprise Long Term Support- und Wartungsvertrag erhält der Kunde die Sicherheit, eine professionell unterstützte und betriebsbereite GIS Infrastruktur auf der Basis von QGIS zu betreiben.

QGIS ist ein Projekt der Open Source Geospatial Foundation (OSGeo). Es läuft unter Linux, Mac OSX, Windows und Android und unterstützt zahlreiche Vektor-, Raster- und Datenbankformate und Funktionen. QGIS wird seit 2002 von einer sehr aktiven Entwickler-Gemeinschaft entwickelt. Es verfügt über alle Funktionen, die ein Desktop GIS für den Unternehmenseinsatz benötigt. Dazu gehören Schnittstellen zu vielen Datenformaten, umfangreiche Analysefunktionen, Unterstützung der wichtigsten Spezifikationen des Open Geospatial Consortiums, vielfältige Darstellungsoptionen, die Produktion druckfertiger Karten und die Erweiterbarkeit über eine Python Schnittstelle.

Die Grundlage von QGIS Enterprise ist die QGIS Suite Version 2.0 bestehend aus QGIS Desktop, QGIS Server und QGIS Web Client. Diese Komponenten werden, unabhängig vom QGIS Community Projekt, durch die Sourcepole AG gepflegt, gewartet und erweitert. Dabei spielt die Kompatibilität zur QGIS Version 1.8 Lisboa eine grosse Rolle, denn eine Vielzahl Erweiterungen existieren, die mit der kommenden QGIS Version 2.0 der Community, nicht mehr betrieben werden können. QGIS Enterprise steht zur Zeit für Ubuntu/Debian, RedHat 6, Windows 32bit und Windows 64bit zur Verfügung.

Sourcepole ist seit 2003 an der Entwicklung von QGIS massgeblich beteiligt und betreut Organisationen von 2 bis 140’000 Mitarbeitern die QGIS im produktiven Einsatz betreiben. Als offizielle Committer in mehreren OSGeo-Projekten kann die Firma auch direkt in den Original-Code eingreifen und Kundenanforderungen flexibel erfüllen. Verbesserungen in QGIS Enterprise werden, wenn immer möglich, dem QGIS Community Projekt zur Verfügung gestellt.

www.qgisenterprise.com

Das benutzerfreundliche und funktionsreiche Quantum GIS (QGIS) bewährt sich seit mehreren Jahren im professionellen Einsatz. Die Firma Sourcepole aus Zürich füllt jetzt eine letzte Lücke, die Organisationen davon abgehalten hat QGIS in Unternehmens-Infrastrukturen einzusetzen – der professionelle Support direkt von den Kernentwicklern. Mit dem QGIS Enterprise Long Term Support- und Wartungsvertrag erhält der Kunde die Sicherheit, eine professionell unterstützte und betriebsbereite GIS Infrastruktur auf der Basis von QGIS zu betreiben.

QGIS ist ein Projekt der Open Source Geospatial Foundation (OSGeo). Es läuft unter Linux, Mac OSX, Windows und Android und unterstützt zahlreiche Vektor-, Raster- und Datenbankformate und Funktionen. QGIS wird seit 2002 von einer sehr aktiven Entwickler-Gemeinschaft entwickelt. Es verfügt über alle Funktionen, die ein Desktop GIS für den Unternehmenseinsatz benötigt. Dazu gehören Schnittstellen zu vielen Datenformaten, umfangreiche Analysefunktionen, Unterstützung der wichtigsten Spezifikationen des Open Geospatial Consortiums, vielfältige Darstellungsoptionen, die Produktion druckfertiger Karten und die Erweiterbarkeit über eine Python Schnittstelle.

Die Grundlage von QGIS Enterprise ist die QGIS Suite Version 2.0 bestehend aus QGIS Desktop, QGIS Server und QGIS Web Client. Diese Komponenten werden, unabhängig vom QGIS Community Projekt, durch die Sourcepole AG gepflegt, gewartet und erweitert. Dabei spielt die Kompatibilität zur QGIS Version 1.8 Lisboa eine grosse Rolle, denn eine Vielzahl Erweiterungen existieren, die mit der kommenden QGIS Version 2.0 der Community, nicht mehr betrieben werden können. QGIS Enterprise steht zur Zeit für Ubuntu/Debian, RedHat 6, Windows 32bit und Windows 64bit zur Verfügung.

Sourcepole ist seit 2003 an der Entwicklung von QGIS massgeblich beteiligt und betreut Organisationen von 2 bis 140’000 Mitarbeitern die QGIS im produktiven Einsatz betreiben. Als offizielle Committer in mehreren OSGeo-Projekten kann die Firma auch direkt in den Original-Code eingreifen und Kundenanforderungen flexibel erfüllen. Verbesserungen in QGIS Enterprise werden, wenn immer möglich, dem QGIS Community Projekt zur Verfügung gestellt.

www.qgisenterprise.com

The good old OGC WMS has many advantages compared to tiled maps:

• Continious zoom levels
• Support for different projections
• Combination of multiple layers in one request
• Higher resolutions for printing
• Better labelling
• No maintenance needed when updating data

Well known disadvantages are scalability issues for high-traffic sites and a slower response time for complex maps.

The second point can be significantly improved by using a technique known from the progressive JPEG format. Before loading a map with full resolution, a map image with a lower resolution is requested from the server. This results in a better response time, because rendering and transmitting of the low resolution image is significantly faster. The biggest effect on rendering time is in combination with raster layers, but also for vector layers the improvement can be substantial.

High resolution:

Low resolution:

The technique can be easily applied to any WMS using this basic OpenLayers implementation.

There is much room for improvements. The low resolution layer could be tiled, limited to certain zoom levels or having a larger extend for smoother panning.

QGISCloud has this optimization built into the QGIS Web-Client viewer, which helps collecting experience with a wide range of datasets.

The good old OGC WMS has many advantages compared to tiled maps:

• Continious zoom levels
• Support for different projections
• Combination of multiple layers in one request
• Higher resolutions for printing
• Better labelling
• No maintenance needed when updating data

Well known disadvantages are scalability issues for high-traffic sites and a slower response time for complex maps.

The second point can be significantly improved by using a technique known from the progressive JPEG format. Before loading a map with full resolution, a map image with a lower resolution is requested from the server. This results in a better response time, because rendering and transmitting of the low resolution image is significantly faster. The biggest effect on rendering time is in combination with raster layers, but also for vector layers the improvement can be substantial.

High resolution:

Low resolution:

The technique can be easily applied to any WMS using this basic OpenLayers implementation.

There is much room for improvements. The low resolution layer could be tiled, limited to certain zoom levels or having a larger extend for smoother panning.

QGISCloud has this optimization built into the QGIS Web-Client viewer, which helps collecting experience with a wide range of datasets.

In QGIS 2.0, the old “size scale” field has been replaced by data-defined properties which enable us to control many more properties than jut size and rotation. One of the often requested features – for example – is the possibility for data-defined colors:

Today’s example map visualizes a dataset of known meteorite landings published on http://visualizing.org/datasets/meteorite-landings. I didn’t clean the data, so there is quite a bunch of meteorites at 0/0.

To create the map, I used QGIS 2.0 feature blending mode “multiply” as well as data-defined size based on meteorite mass:

Background oceans and graticule by NaturalEarthData.

Today, I updated my QGIS Time Manager plugin to version 0.8. It now works with QGIS master and that means that we can take advantage of all the cool new features in our animations. The following quick example uses the “multiply” blend mode with the tweet sample data which is provided by default when you install the plugin:

(The video here is a little small. Watch it on Youtube to see the details.)

Here is a preview of a new cool feature coming in QGIS 2.0. Alpha channel in colour ramps.

Fancy!

The best part is it even works on raster layers.

How bloody awesome is that!

Mathieu Pellerin made a cool made showing of this new feature on our flickr map group

Here is a preview of a new cool feature coming in QGIS 2.0. Alpha channel in colour ramps.

Fancy!

The best part is it even works on raster layers.

How bloody awesome is that!

Mathieu Pellerin made a cool made showing of this new feature on our flickr map group

Here is a preview of a new cool feature coming in QGIS 2.0. Alpha channel in colour ramps.

Fancy!

The best part is it even works on raster layers.

How bloody awesome is that!

Mathieu Pellerin made a cool made showing of this new feature on our flickr map group

Continuing from last week’s post, I will show you how to use terrain analysis to calculate:-

• slope,
• aspect
• hillshade
• ruggedness index

Slope

Slope is calculated by comparing the pixel value at a particular location relative to the surrounding 8 pixel values. This gives the steepness of the slope.

The Slope dialogue box is very simple:-

Calculate slope dialogue box

• Select the elevation layer (this will be the DTM raster)
• Select the output layer
• I have left the Ouput format and Z factor as default. If the ground is very flat, then exaggerating the z factor might make the slopes easier to visualise.

Aspect

The aspect shows the compass bearing of the slope

The raster has been given values from 0-360 depending on the slope aspect. The darker areas with the lower values are the north to north east facing slopes; the lightest areas with the highest values are the west to north west facing slopes.

Aspect shading

Hillshade

This calculates the amount of sun or shade for a 3D surface. The dialogue box is similar to the previous ones, however there are new options for the sun angle:-

DEM hillshade dialogue box

This analysis uses a fixed location of the sun to accurately simulate the effects of bare hillside and shaded valleys. I positioned the sun to the south west (200 degrees), the east facing slopes around the River Medina estuary in the north of the island are very shaded, in contrast to the brightly lit west facing slopes on the other side of the river.

A DEM with hillshading

This is the most visually appealing and easily understood result and so it is often used as a backdrop for maps with other layers added.

Ruggedness Index

The ruggedness index value is calculated for every location, by summarizing the change in elevation within the 3×3 pixel grid.  Ruggedness index values are grouped into categories to describe the different types of terrain.  The classifications are as follows:

The dialogue box for the ruggedness Index is the same as it is for the other types of analysis mentioned above. The IOW is all categorized as level or nearly level in the ruggedness index. This is despite it being quite hilly! I used the Stretch to MinMx contrast enhancement on the layer properties box:-

A DEM with ruggedness index displayed

The result is quite different to the relief and hill shade raster’s. This is because, it doesn’t attempt to show actual slopes, rather it shows the change in elevation categorised as shown in the ruggedness index table. It is still easy to see the line of hills that cross east to west across the island.

Joining an open source project has been one of the best things I did for my career. To better myself in the process of improving QGIS. To grow as a GIS professional. To learn to be part of team and respect each others ideas even if don't agree. To be open to ideas that others have spent a lot of time on. To not just be single tool pusher and learn a wider range of toolkits. To work with people who you have never seen in person, or even talked to.

How did it feel to join an open source project? Scary but awesome I would say. Scary in that that everyone would read my code - my very amateur code. Scary in that I had never really joined an open source project before and wasn't sure what everyone would think of my work, or my ideas. Scary because there are so many people better at this than me and they might think I'm crap.

However all of this fear is outweighed by the awesome feeling of knowing that people benefit from the work you, and the rest of the team, put in. Sometimes even the small things can make a huge difference to what people can do with your software - and yes I did use "your software" on purpose. Contributing to open source means you, personally, are part of the software. Being a contributor, for me at least, gives you a deeper relationship with the project. The kind of relationship that sees you staying up at night when the rest of the family is in bed trying out a new idea, fixing some annoying bug, or writing a blog post about being an open source contributor. All for free! - well mostly. Some call it obsession I prefer passion.

It's not pretty roses all the time. Passion can lead to burnout. Trying to be involved in most of the major parts of the project can result in stretching yourself thin. A project that never sleeps makes this even harder. The wave of ideas can sometimes be a distraction from just getting stuff done. Rejection of your work can be hard to handle the first time, you just have to remember it's never personal. Most of these are just personal demons that need to be managed but they do sneak up if you enjoy what you do. Having a family - and an xbox - helps to ground you and make sure you don't spend all your free time on the computer hacking away.

Like I said, and despite personal demons, joining an open source project has been one of the best things I did. There is an emotional kick working on something and seeing it used by other people. I didn't expect my expression based labeling addition would get such good remarks but it did and that helped push me further into becoming a QGIS contributor.

Joining an open source project has been one of the best things I did for my career. To better myself in the process of improving QGIS. To grow as a GIS professional. To learn to be part of team and respect each others ideas even if don't agree. To be open to ideas that others have spent a lot of time on. To not just be single tool pusher and learn a wider range of toolkits. To work with people who you have never seen in person, or even talked to.

How did it feel to join an open source project? Scary but awesome I would say. Scary in that that everyone would read my code - my very amateur code. Scary in that I had never really joined an open source project before and wasn't sure what everyone would think of my work, or my ideas. Scary because there are so many people better at this than me and they might think I'm crap.

However all of this fear is outweighed by the awesome feeling of knowing that people benefit from the work you, and the rest of the team, put in. Sometimes even the small things can make a huge difference to what people can do with your software - and yes I did use "your software" on purpose. Contributing to open source means you, personally, are part of the software. Being a contributor, for me at least, gives you a deeper relationship with the project. The kind of relationship that sees you staying up at night when the rest of the family is in bed trying out a new idea, fixing some annoying bug, or writing a blog post about being an open source contributor. All for free! - well mostly. Some call it obsession I prefer passion.

It's not pretty roses all the time. Passion can lead to burnout. Trying to be involved in most of the major parts of the project can result in stretching yourself thin. A project that never sleeps makes this even harder. The wave of ideas can sometimes be a distraction from just getting stuff done. Rejection of your work can be hard to handle the first time, you just have to remember it's never personal. Most of these are just personal demons that need to be managed but they do sneak up if you enjoy what you do. Having a family - and an xbox - helps to ground you and make sure you don't spend all your free time on the computer hacking away.

Like I said, and despite personal demons, joining an open source project has been one of the best things I did. There is an emotional kick working on something and seeing it used by other people. I didn't expect my expression based labeling addition would get such good remarks but it did and that helped push me further into becoming a QGIS contributor.