Welcome to Planet OSGeo

October 21, 2014

Boundless Blog

QGIS Compared: Visualization

Gretchen PetersonAny GIS professional who’s been paying attention to the professional chatter in recent years will be wondering about QGIS and whether or not it might meet some or all of their needs. QGIS is open source, similar to proprietary GIS software, runs on a variety of operating systems, and has been steadily improving since its debut in 2002. With easy-to-install packages, OpenGeo Suite integration, and reliable support offerings, we obviously see QGIS as a viable alternative to proprietary desktop GIS software such as Esri’s ArcGIS for Desktop.

But will it work for you? The short answer is: most likely yes for visualization of most formats of spatial data, probably for analysis of raster and vector data, probably for geographic data editing, and probably for cartographic publishing.  Those are all very subjective assertions based on my personal experience using QGIS for the past seven months but I have been using proprietary GIS for over fourteen years as an analyst and cartographer and have written a couple of books on the subject.

By all means give QGIS a try: download and install it, drag-and-drop some data into it, and give it a spin. This is definitely a good time to evaluate it and consider adopting it across your organization.

Visualizing spatial data in QGIS

In this first post, I’m going to focus on visualizing spatial data in QGIS. These basic functions are straightforward and easy to do in QGIS:

  1. adding datasets

  2. moving datasets up and down in the layer hierarchy

  3. zooming around the map

  4. selecting features based on simple point-and-click

  5. selecting features based on complex selection criteria

  6. viewing attributes

  7. creating graduated color schemes


Strength: Versatile and efficient format support

In fact, QGIS is an effective means of viewing and exploring spatial data of almost any type. If you have complex data, you might be interested to hear that the newest release of QGIS boasts very fast, multi-threaded, rendering of spatial data that may even make it faster than leading competitors. When I began creating the map shown above, I accidentally added all of the Natural Earth 1:10m Cultural Vectors in triplicate to the project, causing some minor heart-palpitations as I realized it was going to try to render close to 100 vector layers all at once. However, my fears were unfounded as it took only a few seconds for them to render once they were all added. In the realm of visualization, it does most of the other tasks that a GIS professional would expect as well, including support for custom symbol sets (in SVG format). Adding GeoJSON data is simple, just drag a geojson file onto the Layers list. Here, we show a portion of James Fee’s GeoJSON repository of baseball stadiums:


Mixed results: Raster visualization

That said, raster visualization can yield unexpected results depending on what is desired. Some raster datasets have tables that associate bands with RGB values such that specific cell-types are rendered certain colors. Often, landcover datasets will have this kind of structure so that, for example, the raster is rendered with blue for water, green for grass, white for ice, and so on. Unfortunately, QGIS doesn’t yet support rendering based on associated table files for rasters. Another slight irritation is the continuing use of binary ARC/INFO GRID formats by some agencies who distribute raster data to the public. If you have one of these datasets, QGIS can open it but you must point to the w001001.adf file using the raster data import button.

Mixed results: On-the-fly reprojection

One of the most important ways to make GIS user-friendly is to support on-the-fly projection. I still remember when projecting on-the-fly became a part of the software that I used to use. It was the end of 1999, and life was so much easier when multiple datasets from multiple agencies in multiple projections could all be jammed together into a single project, producing a map where all the data layers were in the correct projected space. This was because reprojecting not only added extra steps requiring you to reproject everything into a common coordinate system even if all you wanted to do was visualize the data, it also meant maintaining multiple copies of the same dataset, which contributed to folder clutter and using up of valuable disk space. QGIS supports reprojection on-the-fly but it is an option that must be set in the project properties dialog. Some glitches with projections still seem to occur from time to time. Zooming in, for example, sometimes causes the map to zoom to a different place than expected. However, this unexpected behavior is inconsistent, not a showstopper, and may be fixed soon.


Hidden gem: Context

The other important aspect of visualizing data is having enough underlying context for the data. Country boundaries, city labels, roads, oceans, and other standard map data are crucial. Proprietary GIS software generally contains basemap layers that can easily be turned on and off to support visualization in this manner. QGIS also has this capability, in the form of the OpenLayers plugin, which serves up Google, OpenStreetMap, Bing, and Yahoo basemaps at the click of a button. The OpenLayers plugin is free and installs just like any other QGIS plugin—you search for it in the Plugins menu, press “install,” and make your basemap choice in the Web menu.



While QGIS may need a small amount of improvement when it comes to raster visualization and on-the-fly projection, these aren’t hindrances to a typical visualization workflow and are only mentioned here out of respect for a fair and balanced assessment. By and large, my testing has convinced me that the robust visualization capabilities that QGIS offers provide more than enough impetus for many organizations to make the switch to QGIS. In later posts, I’ll discuss how QGIS performs with respect to analysis, editing, and cartography.

The post QGIS Compared: Visualization appeared first on Boundless.

by Gretchen Peterson at October 21, 2014 03:22 PM

October 20, 2014

Peter Batty

Reaction to Apple Maps announcement

What they announced As predicted by the entire world, Apple announced their new maps application today as part of iOS 6. You can see the keynote presentation of the video here, and Apple's summary information about the Maps app here. Overall my predictions from last week were pretty spot on :) ... they announced that it would have turn by turn directions with voice guidance, real time

by Peter Batty (noreply@blogger.com) at October 20, 2014 05:16 PM

GeoTools Team

GeoTools 12.0 Released

The GeoTools team is happy to announce the release of version 12.0.
GeoTools now requires Java 7 and this is the first release tested with OpenJDK! Please ensure you are using JDK 1.7 or newer for GeoTools 12. Both Oracle Java 7 and OpenJDK 7 are supported, tested, release targets.

There are a number of new features in this release:
  • circular strings are now supported in Oracle data stores, thanks to GeoSolutions.it for the work.
  • The content datastore tutorial was updated by Jody and tested out by the FOSS4G workshop participants.
  • GeoTools Filter interfaces have been simplified (cleaning up technical debt from GeoTools 2.3)
  • The new wfs-ng datastore is now available as a drop in replacement for the old WFS datastore, The new store provides much better support for axis orders with servers that don't know what they are doing. In order to make wfs-ng a drop-in replacement (and respond to the same connection parameters) you are limited to only using one implementation of gt-wfs-ng or gt-wfs plugins in your application at a time.
  • New advanced raster reprojection, a lot of work has been put into improving the raster reprojection story for glitches around the date line and polar regions. To enable these options use the following rendering hints:
    rendererParams.put(StreamingRenderer.ADVANCED_PROJECTION_HANDLING_KEY, true);
    rendererParams.put(StreamingRenderer.CONTINUOUS_MAP_WRAPPING, true);
This release is made in conjunction with GeoServer 2.6.0 and is available from the OSGeo maven repository.

About GeoTools 12

by Ian Turton (noreply@blogger.com) at October 20, 2014 01:46 PM

Margherita Di Leo

Call For papers Geospatial devroom @FOSDEM

Please forward!

FOSDEM is a free open source event bringing together about 5000 developers in Brussels, Belgium. The goal is to provide open source software developers and communities a place to meet at. The next edition will take place the weekend 31/1 -> 1/2/2015. This year for the first time there will be a geospatial devroom on Sunday 1/2/2015!

Geospatial technology becomes more and more part of mainstream IT. The idea is to bring together people with different backgrounds to better explain and understand the opportunities Geospatial can offer. This devroom will host topics explaining the state of the art of geospatial technology, and how it can be used amongst other projects.

The geospatial devroom is the place to talk about open, geo-related data and software and their ecosystem. This includes standards and tools, e.g. for spatial databases, and online mapping, geospatial services, used for collecting, storing, delivering, analysing, and visualizing puposes. Typical topics that will be covered are:

  • Web and desktop GIS applications
  • Interoperable geospatial web services and specifications
  • Collection of data using sensors/drones/satellites
  • Open hardware for geospatial applications
  • Geo-analytic algorithms/libraries
  • Geospatial extensions for classical databases (indexes, operations)
  • Dedicated databases


Are you thrilled to present your work to other open source developers? Would you like to run a discussion? Any other ideas? Please submit your proposal at the Pentabarf event planning tool at:

When submitting your talk in Pentabarf, make sure to select the 'Geospatial devroom' as  'Track'. Please specify in the notes if you prefer for your presentation a short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes presentation + discussion).

The DEADLINE for submissions is **1st December 2014**

Should you have any questions, please do not hesitate to get in touch with the organisers of the devroom at fosdem-geospatial@gisky.be!

Johan Van de Wauw
Margherita Di Leo
Astrid Emde
Anne Ghisla
Julien Fastré
Martin Hammitzsch
Andy Petrella 
Dirk Frigne
Gael Musquet

by Margherita Di Leo (noreply@blogger.com) at October 20, 2014 12:21 PM

Jackie Ng

GovHack 2014 post-mortem

UPDATE 20 October 2014: After a bungle on my Amazon EC2 instance, the demo URL on our hackerspace project page is no longer active. I've resurrected this site on my demo server on Rackspace here. Ignore the link on the hackerspace page until that page gets updated (if it will get updated, because I can't do it)

Earlier this month, I attended the GovHack 2014 hackathon, along with thousands of other fellow hackers all across the country. This was my first GovHack, but not my first hackathon. My previous hackathon was RHoK and having no idea how GovHack would turn out, I entered the GovHack event with a RHoK-based mindset of how I would expect this hackathon to turn out.

Bad idea.

I learned very quickly there was a major difference between RHoK and GovHack. Going into RHoK, you have an idea about what solutions you will get to hack on over the weekend as problem owners are present to pitch their ideas to the audience of prospective hackers. With GovHack, you need an idea about what solution you want to hack on over the weekend, all they were going to provide was the various open data and APIs. What on earth are we going to build?

So after losing nearly half the weekend to analysis paralysis, our team (named CreativeDrought, wonder why?) agreed with my suggestion of just building a MapGuide-based mashup of various open datasets, most notably, the VicRoads Crash Stats dataset and related transportation data. I obviously knew MapGuide inside-and-out and its capabilities to have a level of confidence that with the remaining weekend we should still be able to crank out some sort of workable solution. At the very least, we'd have a functional interactive map with some open data on it.

And that's the story of our CrashTest solution in a nutshell. It's a Fusion application, packed to the gills with out-of-the-box functionality from its rich array of widgets (including Google StreetView integration). The main objective of this solution was to allow users to view and analyse crash data, sliced and diced along various age, gender, vehicle type and various socio-economic parameters.

MapGuide's rich out-of-the-box capabilities, Maestro's rapid authoring functionality and GDAL/OGR's ubiquitous data support greatly helped us. I knew with this trio of tools, that we could assemble an application together in the remaining day and a bit left that we had to actually "hack" on something.

Sadly, we only got as far as putting the data on the map for the most part. Our team spent more time frantically trying to massage various datasets via ogr2ogr/Excel/GoogleDocs into something more usable than actually writing lines of code! Seriously VicRoads? Pseudo-AMG? Thank goodness I found the necessary proj4 string for this cryptic coordinate system so that we could re-project a fair chunk of the VicRoads spatial data into a coordinate system that better reflects the world we want to mash this data up with!

Still, our "solution" should hopefully still open up a lot of "what if" scenarios. Imagine looking at a cluster of accident events, not being able to ascertain any real patterns or correlation and so you then fire up the StreetView widget and lo-and-behold, Google StreetView providing additional insights that a birds-eye view could not. Also imagine the various reporting and number crunching possibilities that are available by tapping into the MapGuide API. Imagine what other useful information you could derive if we had more time to put up additional useful datasets. We didn't get very far on any of the above ideas, so just imagine such possibilities if you will :)

So here's our entry page if you want to have a look. It includes a working demo URL to a Amazon EC2 hosted instance of MapGuide. Getting acquainted with Amazon Web Services and putting MapGuide up there was an interesting exercise and much easier than I thought it would be, though I didn't have enough time to use the AWS credits I redeemed over the weekend to momentarily lift this demo site out of the free usage tier range performance-wise. Still, the site seems to perform respectably well on the free usage tier.

Also on that page is a link to a short video where we talk about the hack. Please excuse the sloppy editing, it was obviously recorded in haste in a race against time. Like the solution and/or the possibilities it can offer? Be sure to vote on our entry page.

Despite the initial setbacks, I was happy with what we produced given the severely depleted time constraints imposed on us. I think we got some nice feedback demo-ing CrashTest in person at the post-mortem event several days later, which is always good to hear. Good job team!

So what do I think could be improved with GovHack?
  • Have a list of hack ideas (by participants who actually have some ideas) up some time before the hackathon starts. This would facilitate team building, letting participants with the skills, but without ideas easily gravitate towards people/teams with the ideas.
  • The mandatory video requirement for each hack entry just doesn't work in its current form. Asking teams to produce their own videos puts lots of unnecessary stress on teams, who not only have to come up with the content for their video, but have to also deal with the logistics of producing said video. I would strongly prefer that teams who can/want to make their own video do so, while other teams can just do a <= 3 minute presentation and have that be recorded by the GovHack organisers. Presentations also lets teams find out how other teams fared over the weekend. While everyone else in the ThoughtWorks Melbourne office was counting down to the end of the hackathon, I was still frantically trying to record my lines and trying not to flub them! I raided the office fridge for whatever free booze that remained just to calm myself down afterwards. I don't want to be in that situation ever again!
  • Finally, the data itself. So many "spatial" datasets as CSV files! So many datasets with no coordinates, but have addresses, horribly formatted addresses, adding even more hoops to geocode them. KML/KMZ may be a decent consumer format, but it is a terrible data source format. If ogr2ogr can't convert your dataset, and requires a manual intervention of QGIS to fix it, then perhaps it's better to use a different spatial data format. Despite my loathing of its limitations, SHP files would've been heavily preferred for all of the above cases. I've made my thoughts known on the GovHack DataRater about the quality of some of these datasets we had to deal with and got plenty of imaginary ponies in the process.
Despite the above points, the event as a whole was a lot of fun. Thanks to the team (Jackie and Felicity) for your data wrangling and video production efforts.

Also thanks to Jordan Wilson-Otto and his flickr photostream where I was able to get some of these photos for this particular post.

Would I be interested in attending the 2015 edition of GovHack? Given I am now armed with 20/20 hindsight, yes I would!

by Jackie Ng (noreply@blogger.com) at October 20, 2014 10:51 AM

Petr Pridal

IIIF for images in culture heritage

Online scans of culture heritage documents, such as old maps, books, photographs, etc. are being published by the galleries, libraries, archives and museums.  Until now there was no official standardisation activity in this area. This is now changing with the International Image Interoperability Framework IIIF (http://iiif.io/), which enables easy access to large raster images across institutions.

We are happy to announce a new Open Source IIIF viewer, with several useful features: 

- Rotation on client side  - pinch with fingers, Alt-Shift drag with the mouse
- Drawing tools - polygons, lines, markers - used to annotate parts of the pictures
- Color adjustments - saturation, lightness, etc

The viewer is pure Java Script, mobile optimised with almost native feeling for zoom and powered by OpenLayers V3 open-source project, where we are co-developers (see blog post).

Feel free to try at: http://klokantech.github.io/iiifviewer/

Source codes are available on GitHub: https://github.com/klokantech/iiifviewer/

This viewer is another important part of the mosaic of open source tools for publishing of large images and maps. Together with high-performance open-source JPEG2000 image server can be used to serve thousands of users in a very fast and efficient way.

The mentioned server providing IIIF endpoint for the JPEG2000 images was developed and released by Klokan Technologies in cooperation with the National Library of Austria and their Google Books scanning project, the Austrian Books in 2013. The documentation is available at: https://github.com/klokantech/iiifserver/

Server software runs under Linux, Mac OS X as well as Windows. There is even an easy to use installer.  It is powered by IIPImage server and our code has been recently refactored and merged back to the main IIPImage repository.

Support and maintenance for installation of this open-source software can be provided by Klokan as well as the access to JPEG2000 Kakadu license.

by Petr Pridal (noreply@blogger.com) at October 20, 2014 08:59 AM

October 19, 2014

Sean Gillies

Unix style spatial ETL with fio cat, collect, and load

Unix style spatial ETL with fio cat, collect, and load

In Fiona 1.4.0 I added a fio-cat command to the CLI which works much UNIX cat. It opens one or more vector datastets, concatenating their features and printing them to stdout as a sequence of GeoJSON features.

$ fio cat docs/data/test_uk.shp | head -n 2
{"geometry": {"coordinates": [...], "type": "Polygon"}, "id": "0", "properties": {"AREA": 244820.0, "CAT": 232.0, "CNTRY_NAME": "United Kingdom", "FIPS_CNTRY": "UK", "POP_CNTRY": 60270708.0}, "type": "Feature"}
{"geometry": {"coordinates": [...], "type": "Polygon"}, "id": "1", "properties": {"AREA": 244820.0, "CAT": 232.0, "CNTRY_NAME": "United Kingdom", "FIPS_CNTRY": "UK", "POP_CNTRY": 60270708.0}, "type": "Feature"}

I’ve replaced most of the coordinates with ellipses to save space in the code block above, something I’ll continue to do in examples below.

I said that fio-cat concatenates features of multiple files and you can see this by using wc -l.

$ fio cat docs/data/test_uk.shp | wc -l
$ fio cat docs/data/test_uk.shp docs/data/test_uk.shp | wc -l

If you look closely at the output, you’ll see that every GeoJSON feature is a standalone text and each is preceded by an ASCII RS (0x1E) control character. These allow you to cat pretty-printed GeoJSON (using the --indent option) containing newlines that can still be understood as a sequence of texts by other programs. Software like Python’s json module and Node’s underscore-cli will trip over unstripped RS, so you can disable the RS control characters and emit LF delimited sequences of GeoJSON (with no option to pretty print, of course) using --x-json-seq-no-rs.

To complement fio-cat I’ve written fio-load and fio-collect. They read features from a sequence (RS or LF delimited) and respectively write them to a formatted vector file (such as a Shapefile) or print them as a GeoJSON feature collection.

Here’s an example of using fio-cat and load together. You should tell fio-load what coordinate reference system to use when writing the output file because that information isn’t carried in the GeoJSON features written by fio-cat.

$ fio cat docs/data/test_uk.shp \
| fio load --driver Shapefile --dst_crs EPSG:4326 /tmp/test_uk.shp
$ ls -l /tmp/test_uk.*
-rw-r--r--  1 seang  wheel     10 Oct  5 10:09 /tmp/test_uk.cpg
-rw-r--r--  1 seang  wheel  11377 Oct  5 10:09 /tmp/test_uk.dbf
-rw-r--r--  1 seang  wheel    143 Oct  5 10:09 /tmp/test_uk.prj
-rw-r--r--  1 seang  wheel  65156 Oct  5 10:09 /tmp/test_uk.shp
-rw-r--r--  1 seang  wheel    484 Oct  5 10:09 /tmp/test_uk.shx

And here’s one of fio-cat and collect.

$ fio cat docs/data/test_uk.shp | fio collect --indent 4 | head
    "features": [
            "geometry": {
                "coordinates": [
$ fio cat docs/data/test_uk.shp | fio collect --indent 4 | tail
                "CAT": 232.0,
                "CNTRY_NAME": "United Kingdom",
                "FIPS_CNTRY": "UK",
                "POP_CNTRY": 60270708.0
            "type": "Feature"
    "type": "FeatureCollection"

Does it look like I’ve simply reinvented ogr2ogr? The difference is that with fio-cat and fio-load there’s space in between for programs that process features. The programs could be written in any language. They might use Shapely, they might use Turf. The only requirement is that they read and write sequences of GeoJSON features using stdin and stdout. A nice property of programs like these is that you can sometimes parallelize them cheaply using GNU parallel.

The fio-buffer program (unreleased) in the example below uses Shapely to calculate a 100 km buffer around features (in Web Mercator, I know!). Parallel doesn’t help in this example because the sequence of features from fio-cat is fairly small, but I want to show you how to tell parallel to watch for RS as a record separator.

$ fio cat docs/data/test_uk.shp --dst_crs EPSG:3857 \
> | parallel --pipe --recstart '\x1E' fio buffer 1E+5 \
> | fio collect --src_crs EPSG:3857 \
> | geojsonio

Here’s the result. Unix pipelines, still awesome at the age of 41!

The other point of this post is that, with the JSON Text Sequence draft apparently going to publication, sequences of GeoJSON features not collected into a GeoJSON feature collection are very close to being a real thing that developers should be supporting.

by Sean Gillies at October 19, 2014 02:46 PM

Jackie Ng

MapGuide tidbits: MapGuide Server daemon doesn't start after reboot

This one will be short and sweet.

If you have rebooted your Linux server, and for some reason you can no longer start the MapGuide Server as a daemon. You should check that the /var/lock/mgserver directory exists and create it if it doesn't.

The mgserver process will try to create and lock a file in this directory and will bail out if it can't. This directory is cleared when the Linux server is restarted (at least in my observations). None of the wrapper scripts (mgserver.sh or mgserverd.sh) actually check if the directory exists, so they blindly proceed as though this directory existed.

We'll patch the mgserverd.sh script to create this directory if it doesn't exist before running the mgserver daemon. In the meantime, you can edit the mgserverd.sh file in the MapGuide Linux installation yourself to create the /var/lock/mgserver directory before running the mgserver process.

by Jackie Ng (noreply@blogger.com) at October 19, 2014 01:33 PM

Bjorn Sandvik

Creating 3D terrains with Cesium

Previously, I’ve used three.js to create 3D terrain maps in the browser (1, 2, 3, 4, 5, 6). It worked great for smaller areas, but three.js doesn’t have built-in support for tiling and advanced LOD algorithms needed to render large terrains. So I decided to take Cesium for a spin.

Cesium is a JavaScript library for creating 3D globes and 2D maps in the browser without a plugin. Like three.js, it uses WebGL for hardware-accelerated graphics. Cesium allows you to add your own terrain data, and this blog post will show you how.

Compared to the dying Google Earth plugin, it's quite complicated to get started with Cesium. The source code is well documented and the live coding Sandcastle is great, but there is a lack of tutorials and my development slows down when I have to deal with a lot of math.

That said, I was able to create an app streaming my own terrain and imagery with a few lines of code. There is also WebGL Earth, a wrapper around Cesium giving you an API similar to well-known Leaflet. I expect to see more functions or wrappers to make stuff like camera positioning easier in the future.

How can you add your own terrain data to Cesium? 

First, you need to check if you really need it. You have the option to stream high-resolution terrain data directly from the servers at AGI. It's free to use on public sites under the terms of use. If you want to host the terrain data on your own servers, AGI provides a commercial product - the STK Terrain Server. Give it a try, if you have a budget!

I was looking for an open source solution, and found out that Cesium supports two terrain formats:
  1. heightmap
  2. quantized-mesh
The tiled heightmap format is similar to the one I used for three.js. Each tile contains 65 x 65 height values, which overlap their neighbors at their edges to create a seamless terrain. Cesium translates the heightmap tiles into a uniform triangle mesh, as I did in three.js. The downside of this format is the uniform grid, you use the same amount of data to represent both flat and hilly terrain.

The regular terrain mesh made from heightmap tiles. 

The quantized-mesh format follows the same tile structure as heightmap tiles, but each tile is better optimised for large-scale terrain rendering. Instead of creating a dense, uniform triangle mesh in the browser, an irregular triangle mesh is pre-rendered for each tile. It's a better representation of the landscape, having less detail in flat areas while increasing the density in steep terrain. The mesh terrain is also more memory efficient and renders faster.

The irregular terrain mesh from quantized-mesh tiles. Larger triangles have less height variation. 

Unfortunately, I haven't found any open source tools to create tiles in the quantized-mesh format - please notify me if you know how to do it!

You can generate heightmap tiles with Cesium Terrain Builder, a great command-line utility by Homme Zwaagstra at the GeoData Institute, University of Southampton.

I'm using the same elevation data as I did for my three.js maps, but this time in full 10 meter resolution. I'm just clipping the data to my focus area (Jotunheimen) using EPSG:4326, the World Geodetic System (WGS 84).

gdalwarp -t_srs EPSG:4326 -te 7.2 60.9 9.0 61.7 -co compress=lzw -r bilinear jotunheimen.vrt jotunheimen.tif

I went for the easy option, and installed Cesium Terrain Builder using the Docker image. First I installed Docker via Homebrew.  I was not able to mount my hard drive with this method, so I downloaded the elevation data from my public Dropbox folder:

wget https://dl.dropboxusercontent.com/u/1234567/jotunheimen.tif

I used the ctb-tile command to generate the tileset:

ctb-tile --output-dir ./tiles jotunheimen.tif

The command returned 65 000 tiles down to zoom level 15. I compressed the tiles into one file:

tar cvzf tiles.tar.gz tiles

and used the Dropbox uploader to get the tiles back to my hard drive:

./dropbox_uploader.sh upload tiles.tar.gz tiles.tar.gz

So I got 65 000 terrain tiles on my server, how can I see the beauty in Cesium? It required some extra work:
  1. First I had to add a missing top level tile that Cesium was expecting. 
  2. Cesium was also looking for a layer.json file which I had to create:

      "tilejson": "2.1.0",
      "format": "heightmap-1.0",
      "version": "1.0.0",
      "scheme": "tms",
      "tiles": ["{z}/{x}/{y}.terrain?v={version}"]

  3. Lastly, I added a .htaccess file to support CORS and gzipped terrain tiles: 

Then I was ready to go!

Beautiful terrain rendered with 10 m elevation data from the Norwegian Mapping Authority. Those who know Jotunheimen, will notice Skogadalsbøen by the river and Stølsnostind and Falketind surrounded by glaciers in the background.

The terrain is a bit blocky (see the mount Falketind to the left), but I'm not sure if this is happening in Cesium Terrain Builder or Cesium itself. The quantized-mesh tiles from AGI gives a better result. 

I'm not able so show an interactive version, as I'm using detailed aerial imagery from "Norge i bilder", which are not publicly available.

by Bjørn Sandvik (noreply@blogger.com) at October 19, 2014 10:01 AM

October 18, 2014

Gary Sherman

PyQGIS Resources

Here is a short list of resources available when writing Python code in QGIS. If you know of others, please leave a comment.


In alphabetical order:


Example Code

  • Existing plugins can be a great learning tool
  • Code Snippets in the PyQGIS Cookbook


  • Script Runner: Run scripts to automate QGIS tasks
  • Plugin Builder: Create a starter plugin that you can customize to complete your own plugin
  • pb_tool: Tool to compile and deploy your plugins


October 18, 2014 06:18 PM

Antonio Santiago

7 reasons to use Yeoman’s angular-fullstack generator

For my next project and, after looking for candidates and reading some hundreds of lines of documentation, I finally choose to work with the so called MEAN stack: mongodb, express, angular and node.

As with any other technology ecosystem, the great number of frameworks, libraries and tools can make our choice a challenge, and JavaScript is not an exception. But for JavaScript projects we have lot of help and I decide to use the awesome Yeoman tool. Yeoman combines the power of grunt, bower, npm and adds its own salt: the generators.

Yeoman generators are tasks responsible to build the initial project scaffolding.

Yeoman offers an extensive set of official generators oriented to create: webapps, backbone app, chrome extension, etc but we can also found a myriad of non oficial generators (yes, because anyone can create a new generator to satisfy his/her needs).

Within all the generators I chose angular-fullstack to create my MEAN project structure and next are my reasons:

1. Easy to install

You require to have node and npm installed on your system. Once you have them installYeoman and the angular-fullstack is as easy as:

$ npm install -g yo
$ npm install -g generator-angular-fullstack

Once installed the generator you simply need to create a new folder and initialise your project:

$ mkdir my-new-project && cd $_
$ yo angular-fullstack [app-name]

2. Creates both client and server scaffoldings

The generator generates the full stack of your project, both the client and server code. Your project will start well organised and prepared to create an awesome RIA application.

3. Introduces good practices in the generated code

Because the generated is made by experienced developers, they applies good practices in code organisation and style programming (like the environment configuration on the server side using node).

For me, this is one of the most important reasons to use this generator. Anybody knows starting with a new technology is always hard, but it is nothing when you start with four new technologies :)

4. Server side API prepared to use authentication

Following best practices the code is prepared so you can easily add security to you API via a node middleware so each request requires authentication of the client side.

5. Support HTML or jade templating on client side

You can use any template engine for client side but by default the generator works with HTML and Jade. I don’t really like Jade too much so I always try to use EJS or similar (Warning this last sentence is the author’s opinion).

6. Support for different CSS preprocessors

For different opinions there are different alternatives. This way angular-fullstack has support for plain CSS, Stylus, Sass or LESS pre-processors. Choose your preferred.

7. Commands to scaffold anything

With theangular-fullstack you can create new end points for the server side or client side components (like routes, controllers, services, filters, directives, …) with a sentences. So, next command:

yo angular-fullstack:endpoint message
[?] What will the url of your endpoint to be? /api/messages

will produce:

server/api/message/message.model.js  (optional)
server/api/message/message.socket.js (optional)


In my opnion, angular-fullstack is a really powerful tool that simplifies our day to day work.

As always it is not the panacea, it is simply a generic tool to automatize many common tasks. Because of this we can found situations it lacks some feature.

by asantiago at October 18, 2014 10:17 AM

October 17, 2014


Call For papers Geospatial devroom @FOSDEM

Please forward!

FOSDEM is a free open source event bringing together about 5000 developers in Brussels, Belgium. The goal is to provide open source software developers and communities a place to meet at. The next edition will take place the weekend 31/1 -> 1/2/2015. This year for the first time there will be a geospatial devroom on Sunday 1/2/2015!

Geospatial technology becomes more and more part of mainstream IT. The idea is to bring together people with different backgrounds to better explain and understand the opportunities Geospatial can offer. This devroom will host topics explaining the state of the art of geospatial technology, and how it can be used amongst other projects.

The geospatial devroom is the place to talk about open, geo-related data and software and their ecosystem. This includes standards and tools, e.g. for spatial databases, and online mapping, geospatial services, used for collecting, storing, delivering, analysing, and visualizing puposes. Typical topics that will be covered are:

  • Web and desktop GIS applications
  • Interoperable geospatial web services and specifications
  • Collection of data using sensors/drones/satellites
  • Open hardware for geospatial applications
  • Geo-analytic algorithms/libraries
  • Geospatial extensions for classical databases (indexes, operations)
  • Dedicated databases

Are you thrilled to present your work to other open source developers? Would you like to run a discussion? Any other ideas? Please submit your proposal at the Pentabarf event planning tool at:


When submitting your talk in Pentabarf, make sure to select the 'Geospatial devroom' as  'Track'. Please specify in the notes if you prefer for your presentation a short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes presentation + discussion).

The DEADLINE for submissions is **1st December 2014**

Should you have any questions, please do not hesitate to get in touch with the organisers of the devroom at fosdem-geospatial@gisky.be!

Johan Van de Wauw
Margherita Di Leo
Astrid Emde
Anne Ghisla
Julien Fastré
Martin Hammitzsch
Andy Petrella 
Dirk Frigne
Gael Musquet

A final note for everyone still hesitating to come: have a look at the accepted devrooms and other tracks for this year, I'm sure you will find other interesting topics that will make your trip to FOSDEM worthwile!

by Johan Van de Wauw (noreply@blogger.com) at October 17, 2014 07:36 AM

Just van den Broecke

Into the Weather – Part 1 – Exploring weewx


WMS Time Example with GeoServer in Heron

Tagging this post as “Part 1″  is ambitious. Beware: there is hardly any “geo” for now. In the coming time I hope to share some technical experiences with weather stations, weather software and ultimately exposing weather data via some open geospatial standards like OGC WMS(-Time) as in example image right, WFS and in particular SOS (Sensor Observation Service). The context is an exciting project with Geonovum in the Netherlands: to transform and expose (via web services and reporting) open/raw Air Quality data from RIVM , the  Dutch National Institute for Public Health and the Environment. The main link to this project is sensors.geonovum.nl. All software is developed as FOSS via a GitHub project. There are already some results there. I may post on these later.


Within a sub-project the aim is to expose measurements from a physical weather station via standardized OGC web services like WMS, WFS and SOS.  As a first step I dived into the world of weather hardware and software, in particular their vivid open source/open data communities. A whole new world expanded to me. To no surprise: Location and The Weather are part of everyday life since the beginnings of humanity. OpenWeatherMap and Weather Underground are just two of the many communities around open weather data. In addition there’s an abundance of FOSS weather software. Personal weather stations are measuring not just temperature but also pressure, humidity, rainfall, wind, up to UV radiation and are built homebrew or bought for as cheap as $50,-. 

Weather Hacking

Weather Hacking

Being a noob in weather soft/hardware technology I had to start somewhere and then go step-by-step. The overall “architecture” can be even depicted in text:

weather station --> soft/middleware --> web services + reporting
Davis Vantage Pro2 Weather Station

Davis Vantage Pro2 Weather Station

Being more of a software person, I decided to start with the weather soft/middleware. Also, since Geonovum already owns a Davis Vantage Pro2 Weather Station and the Raspberry Pi B+ I plan to use is still underway…

From what I gathered, weewx is the most widely used engine/framework within the weather FOSS community. Also the fact that it is written in Python with a very extensible architecture immediately settled my choice. Explaining weewx is a subject by itself but very well documented. I’ll try in a few sentences what weewx does:

  • collect current and archive weather station measurement data (drivers)
  • storing weather data (archive and statistics) in a database (SQLite or MySQL)
  • submitting data to weather community services like Weather Underground
  • creating formatted/templated reports for your local or remote website

Any of these functionalities is highly extensible through a configurable plugin architecture. The drivers support most common weather stations. Installing is a breeze, either in a local directory or via Linux package managers. Also note that weather data  have quite some different local units (Fahrenheit/Celsius, knots/meters etc). weewx will all take care of this.

So, not yet having access to a weather station, what could I do? One of the weather station drivers is the Simulator which intelligently generates weather data for testing.

openweathermapTrying to have some real-world data I set out on what appeared to be a two-hour hack: create a weather station driver that obtains its data from an open weather API. There are many off course. I choose the OpenWeatherMap API to get data in the area of our cabin in the woods near the place of Otterlo in the Netherlands. Writing this hard-coded driver took just a few line of Python. The source code can be found here.  To not overask the API, I’ve set the time interval to 2 minutes within the weewx configuration file. Also it would not be fair to report these values to any of the weather communities. If the weewx community is interested I can donate this software, with some generalization (e.g. URLvia config).

But all in all my first driver is still running fine in weewx. The main challenge was converting all the values between different metric systems. weewx allows and even encourages you to store all data in US metrics. All the reporting and conversion utilities will always allow you to show your local metric units.

otterlo-weewx-reportAs a Linux daemon now runs fine in our test system. It is time to show some results. weewx reporting is basically a website generated via Cheetah templates. The default template is basic white on black. I found a nice template called Byteweather. You can find my continuous weather report  here at sensors.geonovum.nl/weather. Measurements are now building up thanks to the weewx archive database. Values are mostly matching Dutch weather station data. Expect for the rainfall…Surely we have lots of rain but not that much…

Next posting I hope to tell more about deploying the Raspberry Pi and connecting to the Geonovum Davis Weather station. Then there will be also more “geo” in the post, I promise!


by Just van den Broecke at October 17, 2014 01:21 AM

October 16, 2014

Boundless Blog

Partner Profiles: Agrisoft

Boundless partners are an important part of spreading the depth and breadth of our software around the world. In this ongoing series, we will be featuring some of our partners and the ways they are expanding the reach of our Spatial IT solutions.

AgrisoftEstablished in 2002, Agrisoft is an Indonesian consulting firm specializing in integrated spatial solutions using open source software. Agrisoft offers consultancy, integration and training services, product development, and knowledge of clients’ business processes.

With a population of 250 million people and a booming business community, Indonesia has proved itself to be a growing market for Agrisoft and Boundless. While the market for spatial solutions is still young, Agrisoft encourages the use of spatial software for business by promoting its value and establishing it as a viable solution. OpenGeo Suite provides a complete set of tools for Agrisoft’s clients to build spatially-enabled applications and GeoServer, OpenLayers, and PostGIS have become the preferred solutions among Agrisoft’s clients.

SIH3: Sistem Informasi Hidrologi Hidrometeorologi & Hidrogeologi

Tools and expertise from Boundless have enabled Agrisoft to expand and improve on some of their largest projects and they count among their customers the Indonesian Geospatial Information Agency and the Republic of Indonesia Ministry of Agriculture. In a current project for the Republic of Indonesia Agency for Meteorology, Climatology and Geophysics, Agrisoft is working on the SIH3 Portal, an information system for hydrology, hydrometeorology and hydrogeology. This project makes use of applications built on OpenGeo Suite to browse and explore maps showing different information and Agrisoft is redesigning the graphical user interface using OpenLayers 3.

Agrisoft continually encourages the use of open source spatial software and looks to Boundless for industry best practices and guidance for their current and prospective customers.

If you’d like your company to be considered for our international network of partners, please contact us!

The post Partner Profiles: Agrisoft appeared first on Boundless.

by Camille Acey at October 16, 2014 02:29 PM

gvSIG Team

“Introduction to gvSIG 2.1″ workshop in English

A workshop about the new gvSIG 2.1 version was given in April at the 1st Mexican gvSIG Conference, and now it has been translated to English thanks to Elena Sánchez and
Francisco Solís.

This workshop shows the main gvSIG functionalities, and it includes the new
features that have been included in gvSIG 2.1.

You can download the workshop in pdf format, and the cartography, from [1].

We hope it’s useful for you!

[1] http://www.gvsig.org/plone/docusr/learning/gvsig-courses/gvsig_des_2.1_u_en/pub/documentation/

Filed under: community, english, events, gvSIG Desktop, training

by Mario at October 16, 2014 01:49 PM

Even Rouault

Warping, overviews and... warped overviews

The development version of GDAL has lately received a few long awaited improvements in the area of warping and overview computation.

For those non familiar with GDAL, warping is mainly used for reprojecting datasets from one source coordinate system to a target one, or to create a "north-up" image from a rotated image or an image that has ground control points. Overviews in GDAL are also called pyramids in other GIS software and are sub-sampled (i.e. with coarser resolution) versions of full-resolution datasets, that are mainly used for fast display in zooming out operations. Depending on the utility (warper or overview computation), different resampling methods are available : bilinear, cubic, cubicspline, lanczos, average, etc..

Cubic resampling

Up to now, the bi-cubic resampling algorithm used when computing warped images and overviews was a 4x4 convolution kernel. This was appropriate for warping, when the dimensions of the target dataset are of the same order as the source dataset. However if the target dataset was downsized (which is the nominal case of overview computation), the result was sub-optimal, not to say plainly bad, because not enough source pixels were captured, leading to a result close to what nearest neighbour would give. Now, the convolution kernel dynamically uses the subsampling ratio to take into account all source pixels that have an influence on each target pixel, so e.g 8x8 pixels if subsampling by a factor of 2.
Of course, this involves more computation and could be slower. Fortunately, for 64 bit builds, Intel SSE2 intrinsics are at the rescue to compute convolutions in a very efficient way.

For example in GDAL 2.0dev, computing 5 overview levels on a 10474x4951 RGB raster with cubic resampling takes 2.4 seconds on a Core i5-750, to be compared with 3.8s with GDAL 1.11

$ gdaladdo -ro -r cubic world_4326.tif 2 4 8 16 32

To compare both results, we can select the 5th overview level with the fresh new open option OVERVIEW_LEVEL=4 (index are 0 based)

$ gdal_translate world_4326.tif out.tif -oo OVERVIEW_LEVEL=4

5th overview generated by GDAL 2.0dev

5th overview generated by GDAL 1.11.1

So yes, faster (a bit) and better (a lot) !

Similar result can also be obtained with :

$ gdalwarp -r cubic world_4326.tif out.tif -ts 328 155

The "-oo OVERVIEW_LEVEL=xxx" option can be used with gdalinfo, gdal_translate and gdalwarp, or with the new GDALOpenEx() API.

Related work could involve adding resampling method selection in the RasterIO() API that currently only does nearest neighbour sampling. If that might interest you, please contact me.

Overviews in warping

Related to the OVERVIEW_LEVEL open option, another long due improvement was the selection of the appropriate overview level when warping. A typical use case is to start with a WMS or tiled dataset, e.g the OpenStreetMap tiles, and wanting to reproject full or partial extent to an image with reasonably small dimensions. Up to now, GDAL would alway use the most precision dataset (typically zoom level 18 for OpenStreetMap), which would make the operation terribly slow and unpractical.

Now, the following will run in just a few seconds :

$ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
  -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000

With the -ovr flag, you can modify the overview selection strategy, and for example specify you want to use the overview if the level immediately before the one that would have been automatically selected (i.e. with bigger dimensions, more precise)

$ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
  -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000 -ovr AUTO-1

You can also specify a precise overview level to control the level of details, which is particuarly relevant in the case of OSM since the rendering depends on the scale :

$ gdalwarp frmt_wms_openstreetmap_tms.xml out.tif -t_srs EPSG:4326 \
  -r cubic -te -10 35 10 55 -overwrite -ts 1000 1000 -ovr 9

(Note: -ovr 9 is equivalent to OSM zoom level 8, since GDAL_overview_level = OSM_max_zoom_level - 1 - OSM_level, 9 = 18 - 1 - 8. )

With -ovr 9 (zoom level 8)

With -ovr 10 (zoom level 7)

With -ovr 11 (zoom level 6) or without any -ovr parameter

With -ovr 12 (zoom level 5)
(All above images are © OpenStreetMap contributors)

Overviews in warped VRT

GDAL advanced users will perhaps know the Virtual Raster (.vrt) format. There are several flavors of VRT files, one of them is the so-called "warped VRT", which can be produced by "gdalwarp -of VRT". This is an XML file that captures the name of the source dataset being warped and the parameters of the warping: output resolution, extent, dimensions, transformer used, etc... This can be convenient to do on-the-fly reprojection without needing to store the result of the reprojection. Similarly to regular warping, warped VRT can now make use of overviews of the source dataset to expose "implicit" overviews in the warped VRT dataset. Which make it possible to use warped VRT in a GIS viewer ith decent performance when zooming out. Among others, this will be  beneficial to QGIS that use the "auto-warped-VRT" mechanism when opening a raster that is not a "north-up" dataset.

Still playing with our OpenStreetMap dataset, let's create a warped VRT around western Europe :

$ gdalwarp frmt_wms_openstreetmap_tms.xml out.vrt -t_srs EPSG:4326 \
  -r cubic -te -10 35 10 55 -overwrite -of VRT

We can see that the VRT now advertizes overviews :

$ gdalinfo out.vrt
Size is 4767192, 4767192
Band 1 Block=512x128 Type=Byte, ColorInterp=Red
  Overviews: 2383596x2383596, 1191798x1191798, 595899x595899,
             297950x297950, 148975x148975, 74487x74487,
             37244x37244, 18622x18622, 9311x9311, 4655x4655,
             2328x2328, 1164x1164, 582x582, 291x291, 145x145,
             73x73, 36x36, 18x18

I'd like to thank Koordinates and Land Information New Zealand for funding those improvements.

by Even Rouault (noreply@blogger.com) at October 16, 2014 01:19 PM

Slashgeo (FOSS Articles)

Versio: Distributed Version Control for Spatial Data, and GeoGig News (formerly GeoGit)

Spatial data versioning is important to lots of geospatial applications. We mentioned GeoGit (now named GeoGig) quite a few times since 2012. This week Boundless announced a private beta (you can request an invitation) of Versio, a website for distributed version control of spatial data.

First, you may want to see how GeoGig (formerly GeoGit) has matured, it’s open source and essentially “[w]ith GeoGig, users are able to import spatial data into a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories.”

Regarding Versio itself, “With Versio, we want to support as many editing workflows as possible, both online and offline. So we’ve made the platform client-agnostic to support traditional desktop GIS software as well as web, mobile, or custom applications built on the Versio API”.

The post Versio: Distributed Version Control for Spatial Data, and GeoGig News (formerly GeoGit) appeared first on Slashgeo.org.

by Alex at October 16, 2014 12:34 PM

Petr Pridal

Amazon S3 as a WMTS cloud hosting for maps

The current version of MapTiler (0.5.5) supports direct upload of map tiles to Amazon S3 or Google Cloud Storage. Such hosting is a robust and affordable way to publish your maps online.

Maps rendered with MapTiler or available as MBTiles file are after upload available in various viewers, such as Leaflet, OpenLayers, WebGL Earth, Google Maps API, MapBox.js, etc.

Thanks to the OGC WMTS standard the maps can be also directly opened in QGIS or ArcGIS for Desktop. Compared to the standard S3 utilities, uploading of map tiles is a way faster, especially for larger maps.

The workflow is as simple as few clicks. Watch our video tutorial:

by Hynek Přidal (noreply@blogger.com) at October 16, 2014 08:20 AM

gvSIG Team

Webinar sobre el modelizador de geoprocesos en gvSIG

Este viernes 17 de octubre tendremos un nuevo e interesante seminario online organizado por MundoGEO y Asociación gvSIG. En este caso aprenderemos sobre uno de los temas más desconocidos de gvSIG y que aporta grandes posibilidades a los usuarios: el modelizador de geoprocesos.

Este webinar forma parte de las (muchas y variadas) actividades que se están llevando a cabo en conmemoración de los 10 años de gvSIG.

Con inscripción gratuita, este evento online está dirigido a todas aquellas personas con conocimientos básicos de geoprocesamiento vectorial y raster.

El ponente será Gustavo Agüero Córdoba, profesor SIG de la EARTH University, la Universidad Técnica Nacional de Costa Rica, y profesor de los Cursos gvSIG y Geoprocesamiento Avanzado en la Asociación gvSIG.

Para inscribirse sigue el siguiente enlace: https://www2.gotomeeting.com/register/285059474


Filed under: events, gvSIG Desktop, spanish Tagged: geoprocesamiento, modelizador

by Alvaro at October 16, 2014 06:49 AM

October 15, 2014

gvSIG Team

Culminaron las 1as Jornadas de Tecnologías Libres de Información Geográfica y Datos Abiertos y 3as Jornadas de gvSIG Uruguay

Los pasados 2 y 3 de octubre tuvieron lugar las 1as Jornadas de Tecnologías Libres de Información Geográfica y Datos Abiertos y 3as Jornadas de gvSIG Uruguay. Este gran desafío que significó llegar a las 3as Jornadas podemos decir que se superó con creces: más de 140 asistentes a las ponencias (primer día) y 4 talleres totalmente desbordados (segundo día). Y esto en un pequeño país con poco más de tres millones de habitantes y con un público objetivo muy limitado pero que los hechos demuestras que está ávido de aprender, informarse y compartir.

_0002492 IMG_0417

Gracias al esfuerzo voluntario, honorario y desinteresado de un grupo de entusiastas y defensores del proyecto gvSIG y de la geomática libre en general, más la colaboración de instituciones y empresas que apoyan este proyecto solidario y colaborativo, podemos decir que fueron las mejores Jornadas ya organizadas por la Comunidad gvSIG Uruguay: un programa equilibrado e interesante, una oferta de talleres muy atractiva, una concurrencia atenta y respetuosa y todos los detalles cuidados con mucho esmero y dedicación (transmisión en vivo y en directo, instalaciones y servicios de primer nivel, cafetería, materiales entregados, etc.) hacen que los organizadores veamos con optimismo un futuro con más y mejores Jornadas.

Geoserver-_1070942 _1070914

Decíamos que estas Jornadas tenían un sabor especial debido a 4 factores:

  1. la reciente aprobación de la Ley de Software Libre y Formatos Abiertos en el Estado
  2. la creciente importancia de los Datos Abiertos a nivel nacional y mundial (se cumplen 6 años de aprobada la Ley de Acceso a la Información Pública en Uruguay)
  3. la nueva etapa que comienza a recorrer la IDEuy (Infraestructura de Datos Espaciales de Uruguay http://ide.uy/) a partir del 1o de enero pasado (ver ponencia al respecto)
  4. la conmemoración del 10mo. aniversario del software gvSIG

_1070918 _1070953

Gracias a todas y todos los que hicieron posible este evento que seguramente marcará un hito en la difusión de las Tecnologías Libres de Información Geográfica y Datos -espaciales- Abiertos en general y de gvSIG en particular. ¡Hasta la próxima!

Filed under: opinion

by Sergio Acosta y Lara at October 15, 2014 12:35 PM

Slashgeo (FOSS Articles)

Slashgeo is a proud media partner of FOSS4G-Asia 2014

We are happy to inform you that Slashgeo will be a proud media partner of the upcoming Free & Open Source Solutions for GIS (FOSS4G) – Asia conference held in Bangkok, Thailand, 2-5 December 2014!



FOSS4G-Asia 2014 aims to bring together FOSS4G users and developers worldwide and foster closer interactions with and amongst Asian communities in order to share ideas for improving software and applications. The Bangkok conference will cover all aspects of FOSS4G, Open Data and Open Standards, with a particular focus on exchanging experiences between FOSS4G users and developers and providing first-hand information on FOSS4G for developing national/local spatial data infrastructures in Asian countries. FOSS4G-Asia 2014 also commemorates ten years since the FOSS-GRASS User Conference was held at Faculty of Engineering, Chulalongkorn University, Thailand between 12-14 September 2004.

Workshops will also be offer on QGIS, ZOO project, MapMint, InaSafe, pgRouting, OpenStreetMap and OpenLayers 3.

Slashgeo will publish articles during and after the conference on what has been highlighted in presentation, workshop and innovative ideas on the geospatial open source, open data & open standard  front in Asia and elsewhere.

The post Slashgeo is a proud media partner of FOSS4G-Asia 2014 appeared first on Slashgeo.org.

by gignacnic at October 15, 2014 01:41 AM

October 14, 2014

Boundless Blog

Introducing Versio: Distributed Version Control for Spatial Data

Boundless is pleased to introduce Versio, our new data management and collaboration platform built specifically for spatial data. We’ve been working on Versio for over a year, extending the power of the GeoGig approach into an online platform that will transform the way organizations collaborate on, control, and share their spatial data.

Versio homepage

Versio is now available in private beta with select customers and community members. We expect to release the full platform in early 2015, but if you would like to get an early look and help us improve the product, please request an invitation at http://vers.io/request-invite.

The Problem

Spatial data is dynamic, and anyone who works with it knows that keeping it updated is a challenge. The larger the organization, the worse this problem gets. Increasing team sizes, field-based data collection, and integrated workflows that depend on the publishing of timely, updated datasets increases the complexity of managing spatial data. Too often this challenge is met by emailing shapefiles around, resulting in a file naming nightmare, and a labor-intensive process to merge data together. Alternatively, if you have the money, an expensive versioning database can be used, but even that suffers from potential centralized outages, file locks, and complex system administration.

The Solution

To solve this problem, we looked for a new model of collaboration – one that has revolutionized software development – distributed version control systems.  Boundless first introduced the distributed versioning concept to Spatial IT with GeoGig, an open source tool that draws inspiration from Git but adapts its core concepts specifically for spatial data. As GeoGig has matured, we built Versio to broaden the audience by including a high-performance server and easy-to-use web interface.

Versio’s distributed versioning model and repository data structure enables new approaches to collaboration and data management. On the collaboration side, data owners and GIS analysts determine specifically who they collaborate with, creating private data repositories and inviting others to join, or sharing a data repository for the
crowd to update. Changes to a dataset can be stored in a different “branch” of the repository, and data owners have explicit control over what changes are merged back into the core repository.

The repository data structure preserves the entire lineage of a dataset, allowing a user to track and visualize changes over time. Rather than relying on a central database, each individual’s working copy is a complete repository of the spatial data. Each “commit” to the repository is saved as a discrete version, yet also maintains its relationship to previous versions in the repository. This allows users to visualize the lineage of features across all versions, as well as the changes between different versions. Additionally, file sizes are minimized since only the changes between versions are stored (eliminating redundant data) and it is easy to rollback to a previous version of a dataset.

With Versio, we want to support as many editing workflows as possible, both online and offline. So we’ve made the platform client-agnostic to support traditional desktop GIS software as well as web, mobile, or custom applications built on the Versio API.

Request an invitation to the Versio private beta at http://vers.io/request-invite!

The post Introducing Versio: Distributed Version Control for Spatial Data appeared first on Boundless.

by Joshua Campbell at October 14, 2014 01:30 PM

Jackie Ng

Make that 3/3

Thanks to this thread, I was finally able to crack the missing piece of the CZML output puzzle for mapguide-rest, and we can now output point, line and polygon features as CZML to Cesium.

CZML is a representation of a Layer Definition in mapguide-rest, this means we will get pre-evaluated properties to play with such as:

We currently use this information as follows

Tooltips get written as the description property of each CZML packet, allowing such information to be displayed in the Cesium information window when the object is selected.

Now as the above screenshot shows, there's no real visual way to know what object you selected. I'm still figuring out if there's a way in CZML or the Cesium APIs to specify how a selected object looks so it can stand out.

If the Layer Definition has elevation/extrusion settings applied, that's when the fun stuff happens. We apply the extruded value in the CZML packet for each feature, giving us 2.5D features. This extrusion only applies for polygon features at the moment.

Oh, and did you know Cesium works pretty well on any WebGL capable mobile browser?

Pretty cool stuff. Now that we've nailed down the fundamentals, it's time to figure out how much visual fidelity we can preserve from MapGuide to CZML:

  • Can we transfer thematics?
  • Can we transfer labels?
  • Can we transfer patterns?
  • Others?
Fun times ahead!

by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

Jackie Ng

Making MBTiles databases with a little help from mapguide-rest

So allow me to explain what this screenshot represents

What you are looking at is tiles stored in a MBTiles database. The Android app in question is Locus Map, which supports MBTiles databases. MBTiles is an ideal format for delivering tiled maps to mobile devices. It's just a SQLite database that uses the same intuitive XYZ tiling scheme used by OpenStreetMap and friends.

This post will show you how to make such MBTiles databases with a little help from the mapguide-rest extension.

[NOTE: These instructions were used against the current master branch of mapguide-rest which supercedes the 0.8 release, and has several fixes for tile caching. These instructions may or may not work on the 0.8 release]

First thing you need is to download and install Portable Basemap Server.

In the directory where you installed Portable Basemap Server, edit the CustomOnlineMaps.xml and add a new map source to any XYZ tileset accessible from mapguide-rest

<name>mapguide-rest Sheboygan</name>
<url><![CDATA[http://localhost/mapguide/rest/library/Samples/Sheboygan/MapsTiled/SheboyganNoWatermark.MapDefinition/xyz/Base Layer Group/{$z}/{$x}/{$y}/tile.png]]></url>

Note the {$x}, {$y} and {$z} placeholder tokens in the URL. These placeholders are required and Portable Basemap Server will be replacing them with actual X, Y and Z values when fetching tiles.

Once you've edited and saved CustomOnlineMaps.xml, run the PortableBasemapServer.exe as an administrator.

What is unique about Portable Basemap Server (and something I could not find in any other free/OSS packages), is that Portable Basemap Server includes a convenient function to create an MBTiles database from any online tiled map (that presumably follows a XYZ tiling scheme). This function is accessible from the Format Convert menu.

In the Format Convert window, change the Data Source Type to the map source you registered in CustomOnlineMaps.xml. If your tiled map does not span the entire world, you may want to hone in to the specific region your tiled map is in with one of the existing map sources before switching over to your mapguide-rest map source.

Now do the following:

  • Specify the path of the MBTiles database you want to create
  • Trace a box around the area you want to fetch the tiles for
  • Tick the Download Levels (aka. Zoom levels) you want to fetch tiles for. The map preview shows the current zoom level, so generally you want to tick that level and every level above that.
  • Tick Compact? to optimize storage of redundant tiles

Once you are satisfied with the settings, click Start to initiate the tile seeding process. Portable Basemap Server will spit out lots of useful progress information while building the MBTiles database.

Once the tile seeding process is complete, you can now transfer this MBTiles database file to your mobile device and load it into your MBTiles supported app.

As a bonus, the actual process of building an MBTiles database also seeds the XYZ tile cache on the server-side. So this process can also serve as a XYZ tile cache seeder if you have no use for MBTiles.

If you're interested in what platforms support MBTiles, check out the MBTiles wiki.

by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

Jackie Ng

Announcing: mapguide-rest 0.9

Here's a new release of mapguide-rest, packed with some new toys.

PDF Support

The existing URL routes for DWF plotting now also support PDF output.

For example, a DWF plot URL like this:


Can be turned into a PDF plot like this just by replacing the .dwf in the URL to .pdf:


When plotting from a session-based runtime map, you also have the option of producing a layered PDF. To produce a layered PDF, simply append layeredpdf=1 to a PDF plot URL on a session-based runtime map. This takes longer to plot than a normal PDF, but the resulting PDF will have a toggle-able layer structure

Queryable Layer Definitions

The existing URL routes to query feature data from Feature Sources can now also be applied to Layer Definitions.

For example, suppose you originally were querying Parcels from its Feature Source

GET http://localhost/mapguide/rest/library/Samples/Sheboygan/Data/Parcels.FeatureSource/features.xml/SHP_Schema/Parcels?maxfeatures=500

You can now also query the same data via a Layer Definition that points to it

GET http://localhost/mapguide/rest/library/Samples/Sheboygan/Layers/Parcels.LayerDefinition/features.xml?maxfeatures=500

You'll notice that querying via Layer Definitions means you don't have to include the fully-qualified FDO class name in the URL as that will be inferred from the Layer Definition document. Also when querying via Layer Definitions, it will also include evaluated tooltip and hyperlink expressions for each feature (as MG_TOOLTIP and MG_HYPERLINK properties)

The Layer Definition query route supports the same parameters as the Feature Source one and supports GeoJSON output as well.

New Samples

We've added a new OpenLayers 3 example, demonstrating how to consume dynamic GeoJSON vector layers from the REST API

And a new Cesium example, also consuming GeoJSON from the REST API

Other Changes

  • GeoJSON features now include id attributes containing the identity property value. Previously the identity property value was written out as a regular feature property.
  • Improved XYZ tile cache resiliency
  • Feature query routes (ie. selecting features) no longer require an authentication challenge and can be done anonymously.
  • Feature query responses are no longer internally buffered, reducing response wait times.


by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

Jackie Ng


After lots of trial and error, I am finally able to output features from MapGuide as CZML to Cesium via mapguide-rest

However, only 2 out of the 3 geometry types are working (points and polygons). I'm still trying to figure out:
  • How to properly output CZML for line features
  • How best to apply Z extrusion where it is defined in the Layer Definition
  • What parts of a Layer Definition are transferable/translatable to CZML? Doesn't have to be 1:1. KML-level visual/information fidelity would suffice here.
If only there were more comprehensive CZML examples I could refer to that would make implementing this stuff much easier! All the examples I could find try to demonstrate every bell and whistle when all I want to know is where do I stick the lat/lon/elevation coordinates from my source geometries? Their CZML documentation could do with some improvement, a single-page document is terribly hard to navigate and without reference examples it's amazing I was even able to get this far!

But in the end, all this pain and struggle will be worth it because Cesium is just plain awesome! I truly believe that Cesium will be to 3D maps what OpenLayers is to 2D maps: A powerful web-based map viewing platform that is rich in features and support for many different vector and raster data sources.

by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

Jackie Ng

Announcing: mapguide-rest 0.10

Nope, this isn't a 1.0 release. Not only are we not using decimal release numbers, but there's still plenty of things to explore and refine before we can put the 1.0 stamp on this thing. Here's what's new and changed in this release.

(Experimental) Cesium CZML support

We now have support for outputting feature data as CZML for consumption inside the Cesium 3D web viewer. Support for CZML is made available as a representation of a given Layer Definition.

For example, the following route will return data from the trees layer as CZML:


We've included a CZML example in this release that demonstrates the level of support that has been implemented for this release.

When selecting an object, its tooltip data will be shown in Cesium's information window if available.

Note the object itself has no selection indicator unless the object is a point. Still trying to figure out if we can apply a different style for selected lines and polygons.

If your Layer Definition has elevation settings applied, they be extruded if they're polygons

Now if the (experimental) tag didn't stand out, here's the current limitations with this implementation:
  • The following properties are preserved when converted to CZML, anything not listed can be assumed lost in translation:
    • Point styles: Point color is preserved. The point size in CZML is the average of the height/width of the point as defined in the Layer Definition.
    • Line styles: Line color
    • Area/Polygon styles: Fill color. Outline color
  • If a Layer Definition has multiple scale ranges defined, mapguide-rest will only consider the first scale range when outputting CZML
  • If a given point/area/line style is themed, the default rule (the one without a filter) is ignored
Data publishing improvements

The restcfg.json now lets you specify a Layer Definition as the data source instead of a Feature Source and Feature Class name.

Also, when using a Layer Definition as a data source, you'll get tooltip, hyperlink and elevation FDO expression pre-evaluated, allowing you to use such computed properties within your templates.

You can find a new example that uses the building footprints from the Melbourne dataset.

File download support

Most GET routes can now prompt for downloads by appending download=1 to the query string of the URL.

XYZ tile improvements

Vector tiles can now be for a base layer group or for a layer within the base layer group.

Just to recap, this URL route fetches a vector tile for a given base layer group in a Map Definition


If you want vector tiles for a specific layer within that group, you can use this new URL route


You can find a new Leaflet example that uses the single-layer vector tiles.

Other changes

  • Fixed bad download links in the resource data list HTML representation
  • Fixed invalid chunked file transfer behavior under certain conditions
  • Samples updated to use OpenLayers 3 final and Cesium 1.1

by Jackie Ng (noreply@blogger.com) at October 14, 2014 02:28 AM

October 13, 2014

gvSIG Team

História, geotecnologias livres e os 10 anos do gvSIG.

No âmbito das comemorações dos 10 anos do gvSIG, o Grupo Hímaco promove um evento no dia 15 outubro que celebra  o aniversário do software no Arquivo Público do Estado de São Paulo.

O evento terá a participação dos membros do Hímaco e abordará os seguintes temas:
1) Software livre, sua história e seu lugar no presenteLuis Ferla
2) O que é SIG Histórico e o trabalho do Hímaco - Delphine Lacroix, Maíra Rosin e Orlando Guarnier

Serão disponibilizadas 35 vagas e as inscrições devem ser feitas através do formulário disponível em: http://goo.gl/2j3qzw

A inscrição será confirmada em mensagem posterior.
A entrada é gratuita e serão fornecidos certificados.
Publico alvo: Alunos e professores de história e geografia e profissionais da área de geotecnologias.

15/10/2014 (quarta-feira)
Das 14 às 18h
Arquivo Público do Estado de São Paulo – Rua Voluntários da Pátria, 596 (perto do Metrô Tietê)

Arquivo Público do Estado de São Paulo
Comunidade gvSIG
Grupo Hímaco

Filed under: community, events, portuguese

by Alvaro at October 13, 2014 11:44 AM

Just van den Broecke

Unlocking the amazing OpenTopo.nl Maps

The essence of this post is to illustrate via some web-apps the great topographic mapping done by Jan-Willem van Aalst using Dutch free geo-data. The summary/TL;DR is:

The longer post here below…

04461The Netherlands and Belgium have produced some influential mapmakers throughout history. Up to the 20th century the “Low Countries” were part of empires that ruled at the time. Mapmakers could be found in cities like Antwerp, Ghent and Amsterdam. I found an overview here, but there may be more authoritative sources. Mercator, was one of them, unaware  probably of the later Google Mercator ;-).

Map-making has moved into the digital era. Anyone can render maps from source data, using attributed polygons, lines and points with some styling. Hmm, but there is more to the picture than meets the eye: maps have and always will be a combination of art, science and technology.

ot1Every mapmaker, now and back then, is dependent on (accurate) map-data. Within the Netherlands we have been fortunate by having multiple free geo-data sources: OpenStreetMap (with several imports) and since 2012 Dutch topographic and cadastral geospatial data sources via PDOK, plus many others.  These data-sources can all be combined, but this endeavour still requires a true mapmaker…



Combining data source in OpenTopo (img by JW van Aalst)

Combining data source in OpenTopo (img by JW van Aalst)

Jan-Willem van Aalst, via his website OpenTopo, tastefully combines Dutch open geo-data sources like OpenStreetMap, Dutch public data sources like: BRT (topography), Buildings (BAG) and “AHN”, Dutch height data (yes, we are not that flat!) into detailed and attractive topographic maps. His main editing tool is QGIS. Producing several resolutions up to 800 pixels/kilometer, the output is rendered as a series of straight TIFF files in various resolutions (up to 800px/km).



But how to make Jan-Willem’s results (TIFFs) available online? The NLExtract project aims to convert Dutch Open Geo-Data to manageable formats by providing tools and other services. For example the raw downloaded GML data for Dutch Address and Building Data (BAG) and the  BRT Top10NL Topography data were first converted to PostGIS tables using the NLExtract ETL tools for use by Jan-Willem in QGIS.

In addition NLExtract provides downloads of converted and TIFF data and some apps to demonstrate transformation results.

In order to make the OpenTopo maps of Jan-Willem more widely available, I have provided both a tiling (TMS/WMTS) service for the maps plus some simple apps for browsers and mobile devices (tables/smartphones/phablets). These can be found at:  app.nlextract.nl/ot, in particular the OpenTopoMap tiled in Dutch Projection. Thanks to Bart van den Eijnden for the Leaflet-Proj4s integration.

The following steps and technologies have been used within NLExtract to unlock JW’s raw TIFFs into tiled web services and demo-apps:

The source code for the above is mostly on GitHub. In a next blog I will dive deeper into the ETL/transformation processes, introducing Stetl, a generic ETL framework in Python.

by Just van den Broecke at October 13, 2014 01:08 AM

October 12, 2014

OSGeo News

University of Colorado Denver's FOSS4G Lab

by aghisla at October 12, 2014 08:10 AM

October 11, 2014

Sean Gillies

Rasterio 0.15 and a cheat sheet

Rasterio 0.15 and a cheat sheet

Here is what’s new in Rasterio 0.15. The biggest changes are the ones under the hood to permit opening non-TIFF formats in ‘r+’ and ‘w’ modes. The one API change was made to align better with Numpy: any output keyword args are superceded by out and we warn you about future removal of output. In the command line programs we’re adding -f and --format as preferred aliases for the older --driver option. We’re closing in on the programming and command line interfaces that will be finalized in 1.0.

Inspired by Derek Watkins, I’ve begun a Fiona/Rasterio/Shapely cheat sheet modeled after his popular GDAL/OGR command line cheat sheet. It’s been a great rubric for identifying the key features that should be in the Fiona and Rasterio CLIs. It also has fun examples of using fio and rio with GNU Parallel, jq, and geojsonio-cli.

$ fio cat input.shp --x-json-seq-no-rs \
> | parallel --pipe "jq -c 'select(.id==\"10\")'" \
> | fio collect \
> | geojsonio

0.15 features in the cheat sheet include version inspection,

$ rio --version

format driver enumeration,

$ rio env --formats
AAIGrid: Arc/Info ASCII Grid
ADRG: ARC Digitized Raster Graphics
AIG: Arc/Info Binary Grid
ARG: Azavea Raster Grid format
AirSAR: AirSAR Polarimetric Image
ZMap: ZMap Plus Grid

and stacking raster bands to produce new multiband datasets.

$ rio stack tests/data/RGB.byte.tif --bidx 1..3 -o stacked.jpg -f JPEG

by Sean Gillies at October 11, 2014 07:35 PM

October 10, 2014

Slashgeo (FOSS Articles)

map.geo.admin.ch wins prize for the use of open source software

Out of 23 applicants map.geo.admin.ch received the Open Source Software Award 2014. The prize was awarded by the Swiss Open Systems User Group / ch / open on October 8, 2014.

The implementation of the geoinformation act based on the consequent adoption of open source software, open standards and cloud was rewarded. The innovative use of currently available technical possibilities was thus appreciated. For the implementation of the new version of the map viewer map.geo.admin.ch latest web standards (HTML5, CSS3, WebGL) were used in combination with open source software components (OpenLayers3, AngularJS, bootstrap). This choice makes it possible simplify the use, optimize the performance and operating costs of the application.

The Open Source Software Awards honor companies, public entities, open source communities and individuals who have acted boldly and in an innovative way by developing or using open source software in a variety of ways.

Usage and exchange of geodata is fostered by geo.admin.ch in a significant way. The Federal geoportal is operated by the Federal Office of Topography, swisstopo, on behalf of the coordinating body for Federal geographical information (GSG) with the aim to implement the Geoinformation Act (GeoIG). The purpose of this Act is to ensure that geodata relating to the territory of the Swiss Confederation is made available to the Federal, Cantonal and municipal authorities, to industry and commerce, to academic and scientific institutions and to society at large, for the broadest possible use, in a sustainable, up-to-date, rapid and easy way, with the required quality and at reasonable cost (GeoIG Art. 1).

More info:


The post map.geo.admin.ch wins prize for the use of open source software appeared first on Slashgeo.org.

by David Oesch at October 10, 2014 12:00 PM

Gary Sherman

A Quick Guide to Getting Started with PyQGIS on Windows

Getting started with Python and QGIS can be a bit overwhelming. In this post we give you a quick start to get you up and running and maybe make your PyQGIS life a little easier.

There are likely many ways to setup a working PyQGIS development environment—this one works pretty well.



  • OSGeo4W Advanced Install of QGIS
  • pip (for installing/managing Python packages)
  • pb_tool (cross-platform tool for compiling/deploying/distributing QGIS plugin)
  • A customized startup script to set the environment (pyqgis.cmd)
  • IDE (optional)
  • Vim (just kidding)

We’ll start with the installs.


Almost everything we need can be installed using the OSGeo4W installer available on the QGIS website.


From the QGIS website, download the appropriate network installer (32 or 64 bit)

  • Run the installer and choose the Advanced Install option
  • Install from Internet
  • Choose a directory for the install—I prefer a path without spaces such as C:\OSGeo4W
  • Accept default for local package directory and Start menu name
  • Tweak network connection option if needed on the Select Your Internet Connection screen
  • Accept default download site location
  • From the Select packages screen, select the following for installation:
    • Desktop -> qgis: QGIS Desktop
    • Libs -> qt4-devel (needed for lrelease/translations)
    • Libs -> setuptools (needed for installing pip)

When you click Next a bunch of additional packages will be suggested—just accept them and continue the install.

Once complete you will have a functioning QGIS install along with the other parts we need. If you want to work with the nightly build of QGIS, choose Desktop -> qgis-dev instead.

If you’ve already installed QGIS using the OSGeo4W installer, just install the qt4-devel and setutools packages. If you installed QGIS using the standalone installer, the easiest option is to remove it and install from OSGeo4W. You can run both the standalone and OSGeo4W versions on the same machine, but you need to be extra careful not to mix up the environment.

Setting the Environment

To continue with the setup, we need to set the environment by creating a .cmd script. The following is adapted from several sources, and trimmed down to the minimum. Copy and paste it into a file named pyqgis.cmd and save it to a convenient location (like your HOME directory).

@echo off
call "%OSGEO4W_ROOT%"\bin\o4w_env.bat
call "%OSGEO4W_ROOT%"\apps\grass\grass-6.4.3\etc\env.bat
@echo off
path %PATH%;%OSGEO4W_ROOT%\apps\qgis\bin
path %PATH%;%OSGEO4W_ROOT%\apps\grass\grass-6.4.3\lib

set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\qgis\python;
set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\Python27\Lib\site-packages
set PATH=C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Vim\vim74;%PATH%
cd %HOMEPATH%\development

You should customize the set PATH statement to add any paths you want available when working from the command line. I added paths to my git and vim installs.

The cd %HOMEPATH%\development statement starts the shell in my normal working directory—customize or remove as you see fit.

The last line starts a cmd shell with the settings specified above it. We’ll see an example of starting an IDE in a bit.

You can test to make sure all is well by double-clicking on our pyqgis.cmd script, then starting Python and attempting to import one of the QGIS modules:

Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win
Type "help", "copyright", "credits" or "license" for more information.
>>> import qgis.core

If you don’t get any complaints on import, things are looking good.

Python Packages

We need a couple of Python packages as well.


There are several ways to install pip, but since we installed setuptools we can use easy_install:

easy_install pip

Make sure to issue this command from your customized shell (double-click on pyqgis.cmd to start it).


With pip installed we can use it to install pb_tool:

pip install pb_tool

More information on using pb_tool is available on the project website.

Working on the Command Line

Just double-click on your pyqgis.cmd script from the Explorer or a desktop shortcut to start a cmd shell. From here you can use Python interactively and also use pb_tool to compile and deploy your plugin for testing.

IDE Example

With slight modification, we can start our IDE with the proper settings to recognize the QGIS libraries:

@echo off
call "%OSGEO4W_ROOT%"\bin\o4w_env.bat
call "%OSGEO4W_ROOT%"\apps\grass\grass-6.4.3\etc\env.bat
@echo off
path %PATH%;%OSGEO4W_ROOT%\apps\qgis\bin
path %PATH%;%OSGEO4W_ROOT%\apps\grass\grass-6.4.3\lib

set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\qgis\python;
set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\Python27\Lib\site-packages
set PATH=C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Vim\vim74;%PATH%
cd %HOMEPATH%\development
start "PyCharm aware of Quantum GIS" /B "C:\Program Files (x86)\JetBrains\PyCharm 3.4.1\bin\pycharm.exe" %*

We only changed the last line, adding the start statement with the path to the IDE (PyCharm). If you save this to something like pycharm.cmd, you can double-click on it to start PyCharm. The same method works for other IDEs, such as PyDev.

Within your IDE settings, point it to use the Python interpreter included with OSGeo4W—typically at: %OSGEO4W_ROOT%\bin\python.exe. This will make it pick up all the QGIS goodies needed for development, completion, and debugging. In my case OSGEO4W_ROOT is C:\OSGeo4W, so in the IDE, the path to the correct Python interpreter would be: C:\OSGeo4W\bin\python.exe.

Make sure you adjust the paths in your .cmd scripts to match your system and software locations.


Here is an example of a workflow you can use once you’re setup for development.

Creating a New Plugin

  1. Use the Plugin Builder plugin to create a starting point [1]
  2. Start your pyqgis.cmd shell
  3. Use pb_tool to compile and deploy the plugin (pb_tool deploy will do it all in one pass)
  4. Activate it in QGIS and test it out
  5. Add code, deploy, test, repeat

Working with Existing Plugin Code

The steps are basically the same was creating a new plugin, except we start by using pb_tool to create a new config file:

  1. Start your pyqgis.cmd shell
  2. Change to the directory containing your plugin code
  3. Use pb_tool create to create a config file
  4. Edit pb_tool.cfg to adjust/add things create may have missed
  5. Start at step 3 in Creating a New Plugin and press on


Assuming you have things properly installed, trouble usually stems from an incorrect environment.

  • Make sure QGIS runs and the Python console is available and working
  • Check all the paths in your pygis.cmd or your custom IDE cmd script
  • Make sure your IDE is using the Python interpreter that comes with OSGeo4W

[1] Plugin Builder 2.6 will support generation of a pb_tool config file

October 10, 2014 12:55 AM

October 09, 2014

Gary Sherman

QGIS Development with Plugin Builder and pb_tool

The Plugin Builder is a great tool for generating a working plugin project that you can customize.

One of the main tasks in the development cycle is deploying the plugin to the QGIS plugin directory for testing. Plugin Builder comes with a Makefile that can be used on Linux and OS X to aid in development. Depending on your configuration, the Makefile may work on Windows.

To help in managing development of your projects, we’ve come up with another option—a Python tool called pb_tool, which works anywhere QGIS runs.

Here’s what it provides:

Usage: pb_tool [OPTIONS] COMMAND [ARGS]...

  Simple Python tool to compile and deploy a QGIS plugin. For help on a
  command use --help after the command: pb_tool deploy --help.

  pb_tool requires a configuration file (default: pb_tool.cfg) that declares
  the files and resources used in your plugin. Plugin Builder 2.6.0 creates
  a config file when you generate a new plugin template.

  See http://g-sherman.github.io/plugin_build_tool for for an example config
  file. You can also use the create command to generate a best-guess config
  file for an existing project, then tweak as needed.

  --help  Show this message and exit.

  clean       Remove compiled resource and ui files
  clean_docs  Remove the built HTML help files from the...
  compile     Compile the resource and ui files
  create      Create a config file based on source files in...
  dclean      Remove the deployed plugin from the...
  deploy      Deploy the plugin to QGIS plugin directory...
  doc         Build HTML version of the help files using...
  list        List the contents of the configuration file
  translate   Build translations using lrelease.
  validate    Check the pb_tool.cfg file for mandatory...
  version     Return the version of pb_tool and exit
  zip         Package the plugin into a zip file suitable...

In the command summary, a description ending in … means there is more to see using the help switch:

pb_tool zip --help
Usage: pb_tool zip [OPTIONS]

  Package the plugin into a zip file suitable for uploading to the QGIS
  plugin repository

  --config TEXT  Name of the config file to use if other than pb_tool.cfg
  --help         Show this message and exit.

The Configuration File

pb_tool relies on a configuration file to do its work. Here’s a sample pb_tool.cfg file:

# Configuration file for plugin builder tool
# Sane defaults for your plugin generated by the Plugin Builder are
# already set below.
# Name of the plugin. This is the name of the directory that will
# be created in .qgis2/python/plugins
name: TestPlugin

# Python  files that should be deployed with the plugin
python_files: __init__.py test_plugin.py test_plugin_dialog.py

# The main dialog file that is loaded (not compiled)
main_dialog: test_plugin_dialog_base.ui

# Other ui files for dialogs you create (these will be compiled)
compiled_ui_files: foo.ui

# Resource file(s) that will be compiled
resource_files: resources.qrc

# Other files required for the plugin
extras: icon.png metadata.txt

# Other directories to be deployed with the plugin.
# These must be subdirectories under the plugin directory

# ISO code(s) for any locales (translations), separated by spaces.
# Corresponding .ts files must exist in the i18n directory
locales: af

# the built help directory that should be deployed with the plugin
dir: help/build/html
# the name of the directory to target in the deployed plugin
target: help

The configuration file is pretty much self-explanatory and represents that generated by Plugin Builder 2.6 for a new plugin. As you develop your code, you simply add the file names to the appropriate sections.

Plugin Builder 2.6 will be available the week of the QGIS 2.6 release. In the meantime, you can use pb_tool create to create a config file. See the pb_tool website for more information.


Here’s what a deployment looks like with pb_tool:

$ pb_tool deploy
Deploying will:
            * Remove your currently deployed version
            * Compile the ui and resource files
            * Build the help docs
            * Copy everything to your .qgis2/python/plugins directory

Proceed? [y/N]: y
Removing plugin from /Users/gsherman/.qgis2/python/plugins/TestPlugin
Deploying to /Users/gsherman/.qgis2/python/plugins/TestPlugin
Compiling to make sure install is clean
Skipping foo.ui (unchanged)
Compiled 0 UI files
Skipping resources.qrc (unchanged)
Compiled 0 resource files
Building the help documentation
sphinx-build -b html -d build/doctrees   source build/html
Running Sphinx v1.2b1
loading pickled environment... done
building [html]: targets for 0 source files that are out of date
updating environment: 0 added, 0 changed, 0 removed
looking for now-outdated files... none found
no targets are out of date.

Build finished. The HTML pages are in build/html.
Copying __init__.py
Copying test_plugin.py
Copying test_plugin_dialog.py
Copying test_plugin_dialog_base.ui
Copying foo.py
Copying resources_rc.py
Copying icon.png
Copying metadata.txt
Copying help/build/html to /Users/gsherman/.qgis2/python/plugins/TestPlugin/help

Getting Started

For details on installing and using pb_tool, see: http://g-sherman.github.io/plugin_build_tool

October 09, 2014 05:50 PM


FOSS4G NA 2015 Call for Speakers now Open

FOSS4G NA 2015 (Free and Open Source Geospatial North America conference) will be running March 9th-12th 2015 In Burlingame, California (Hyatt, San Francisco Airport). Call for talks and workshops is now open and we've already got some submissions to review. Deadline for submission is November 17th 2014. Presenters including (workshop and those giving 35-minute standard talk) get to attend the 3-days general sessions for free. The conference consists of one day of workshops and three days of general sessions, with lightning talks on some or all of of the general session days.

Details about presentations here: CFP details. The FOSS4G NA 2015 is a collaborative event co-sponsored by OSGeo and LocationTech

FOSS4G NA 2015 will be co-hosted with EclipseCon North America 2015. Admission to FOSS4G NA 2015 gives you admission to EclipseCon NA 2015. So get 2 conferences for the price of one and go conference hopping.

For PostgreSQL and PostGIS folks there is a likely chance that there will be a PostgreSQL day at the same venue during the same period. So we might have a very special PostGIS / PostgreSQL day. I'll update as more details of that surface.

by Regina Obe (nospam@example.com) at October 09, 2014 03:02 AM

October 08, 2014

Stefano Costa

Targhe delle strade di Genova. Tipografia della lettera A

Da qualche settimana ho iniziato a collezionare lettere A. Le prendo dalle targhe delle strade di Genova e sto cercando di farmi guidare da queste “prime della classe” per prendere confidenza con la storia tipografica delle targhe, soprattutto di quelle più antiche ‒ approssimativamente datate prima del 1945. C’è qualcosa di affascinante nell’idea che queste targhe siano un unico smisurato testo steso per tutta la città, un palinsesto scritto in momenti diversi ma fatto per essere letto oggi.

Da questa serie si notano alcuni elementi interessanti, soprattutto il passaggio dalla A con testa piatta a quella acuta. Le datazioni che ho abbozzato per ora sono poco più che ipotetiche, così come le riproduzioni dei caratteri che ho raccolto (da vero neofita della tipografia). È certamente possibile che ci siano ampie sovrapposizioni di tipi nel tempo, anche se  chiaramente ci sono stati dei momenti di impulso ordinatore e omologatore. Il mio tipo preferito è di gran lunga il secondo nell’immagine sotto, il più diffuso nel centro storico.

La forma della lettera ALa forma della lettera A

Non so se esistano dei lavori dedicati a questo argomento, finora non ne ho trovati. Sto procedendo con metodo stratigrafico (poteva essere altrimenti?) e questo è naturalmente frustrante perché non permette datazioni precise se non avendo a disposizione una discreta quantità di dati, che non ho ancora. Mi sono sembrate molto interessanti quelle strade in cui in punti diversi si trovano targhe con tipi diversi (es. via Corsica e via San Vincenzo, entrambe interessate dalla costruzione di via XX Settembre).

  1. Se un tipo è usato su una targa dedicata a una persona morta
    nell’anno X, il tipo va considerato in uso dopo quella data e non a
    quella data esatta.
  2. Se un tipo è usato su una targa di una strada costruita nell’anno X,
    il tipo va considerato in uso dopo quella data.
  3. Se un tipo non compare su targhe databili dopo l’anno X,
    probabilmente è andato fuori uso intorno all’anno X.
  4. Se un tipo compare su un edificio costruito nell’anno X, non possiamo trarne alcuna informazione, in mancanza di indicazioni più precise.

Tra gli eventi più significativi per l’urbanistica e la toponomastica di Genova sono certamente le due espansioni del 1873 e del 1926 ‒ sulla base di quelle è possibile ad esempio osservare i quartieri di Marassi e Staglieno (annessi nel 1873), Molassana  (annesso nel 1926). Girare per le strade, fotografare, prendere appunti… tutte cose non veloci. Ad un certo punto farò anche due passi a Staglieno, ovviamente.

by Stefano Costa at October 08, 2014 05:32 PM

Antonio Santiago

The Book of OpenLayers 3, released !!!

Finally I completed most of the chapters I had thought for the book. Although two chapters remains to be written, I think the current content is extensive enough to help anybody interested to lean this great new version of the OpenLayers project.

The current chapters explains:
– The map and the view
– Layers
– Data sources and formats
– Vector layers
– Events, listeners and properties

The two remaining chapters I have in mind are:
– Controls and interaction
– Overlays

Hope, this book help you to introduce to the OpenLayers version 3.

Remember, thanks to the LeanPub platform, when you buy the book you can get any later update I make on it. In addition, you have 45 days for refund if you think the book does not cover your expectations. In addition, don’t hesitate to contact me for any errors, misspelled words or sentences, etc.

Remember, this is a self-published book. No main company is behind it and no great marketing campaign is prepared. Any help from you, talking about the book at any forum or social network will be appreciated.

Finally, I would like to thank my wife, Pilar, for her understanding and almost infinite patience for my job, hobby and profession, the computer science.

by asantiago at October 08, 2014 05:31 PM

Boundless Blog

GeoGig Grows Up, Contributed to LocationTech


We’re proud to announce that GeoGig is approaching its first major release and we’re contributing the project to the LocationTech working group at the Eclipse Foundation.

For those not familiar with the project, GeoGig is an open source tool that draws inspiration from Git (hence why it was previously called GeoGit) but adapts its core concepts to handle distributed versioning of spatial data. With GeoGig, users are able to import spatial data into a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories.

Learn more about GeoGig and how to use it with these posts and videos:

As one of the founding members of the LocationTech initiative,  we’ve given several talks at LocationTech events and look forward to continuing to participate in the LocationTech Tour. Join us at the events in New York on December 9th and Washington DC on December 11th.

The post GeoGig Grows Up, Contributed to LocationTech appeared first on Boundless.

by Rolando Peñate at October 08, 2014 03:40 PM

October 07, 2014

Paul Ramsey

Failure never smelled so sweet

Politics/IT crossover moment! In his Globe & Mail column today, Gary Mason has this to say about the negotiations underway to bring LNG terminals to the BC coast:

Quick primer for the IT audience: in the last election the government promised 100s of thousands of jobs and 100s of billions of revenue (and amazingly, I'm not exaggerating those figures) should BC successfully seed an LNG "industry" on our coast. It was basically all they talked about in the campaign. Unsurprisingly, having placed all their political eggs in the LNG basket, the government is now at the mercy of the companies that are supposed to bring us this windfall, as Mason notes below.

There is an enormous amount at stake for the Premier and her government. From the outside, it appears B.C. needs Petronas and the others more than they need B.C. Ms. Clark comes out the loser if those companies walk away and her LNG dream evaporates. She can also lose if her government signs desperate deals [emphasis mine] that are deemed to be so slanted in favour of the project promoter that the province becomes a global laughingstock.

Actually no, as anyone on a failed IT project knows, after a desperate deal is signed, both the LNG proponent (vendor) and government (manager) will get together and sing the praises of the finished deal.

"It's a world class deal, and it was a tough negotiation, but we did it", the government will say.

"They drove a hard bargain, but we think we can make it work", the proponent will say.

The media at best will run a he said/she said with the government's claims against the opposition's analysis, and we'll all move on. The government won't be the loser in the case of a bad, desperate deal, the people of BC will.

Just as, when a vendor and a dependent manager deliver a shitty IT project and declare it the best thing since sliced chips, it's the users who suffer in the end.

by Paul Ramsey (noreply@blogger.com) at October 07, 2014 04:19 PM

Slashgeo (FOSS Articles)

Batch Geonews: Book of OpenLayers 3, 30m Worldwide DEM, U.N. Guide to GeoStandards, and much more

Here’s the recent geonews in batch mode, covering most of September up to today.

On the open source / open data front:

On the Esri front:

Geospatial stories discussed over Slashdot:

In the everything-else category:

In the maps category:

The post Batch Geonews: Book of OpenLayers 3, 30m Worldwide DEM, U.N. Guide to GeoStandards, and much more appeared first on Slashgeo.org.

by Alex at October 07, 2014 01:32 PM