Pinpointing Disasters with OpenGeo Suite

Boundless’ Victoria, British Columbia office sits at the southern tip of Vancouver Island, a region in which is used to mild earthquake activity. So when a colleague back east asked if we’d felt “the earthquake near Port Hardy”, we weren’t particularly surprised that there had been one or that it had gone unnoticed locally.

We were a little surprised, however, when we saw that the epicentre was well off the west coast of the island, while Port Hardy sits on the east coast. Looking more closely at the USGS map showing the location of the earthquake, one wonders why Port Hardy was chosen as a reference point in news reports and not say, Tofino, which is roughly due east of the epicentre.

Like many OpenGeo Suite users, PostGIS is my go-to tool for doing some quick spatial analysis, so I loaded up the Natural Earth populated places data set in to a fresh database and whipped up a quick query to see what was happening within 250 kilometres of the quake.

$ shp2pgsql -W LATIN1 -I -s 4326 ne_10m_populated_places.shp | psql earthquakes

WITH constants AS 
(SELECT ST_SetSRID(ST_MakePoint(-128.15, 49.42), 4326)::geography AS quake)
  SELECT name, pop_max, ST_Distance(geom::geography, quake) / 1000 AS distance
  FROM ne_10m_populated_places, constants
  WHERE ST_DWithin(quake, geom::geography, 250*1000)

And sure enough:

      name      | pop_max |     distance
 Port Hardy     |    2295 | 151.591959991648
 Tofino         |    1655 | 170.322296453086
 Campbell River |   33430 | 219.404018781354
 Courtenay      |   32793 | 229.792897985687

Port Hardy just edges out Tofino as the closest settlement in my data set. So do the USGS and other organisations simply use a naive algorithm to find a reference point for earthquakes? It sure looks like it!

[Note: if you’re wondering about the WITH clause above, that’s just an easy way to effectively define a constant that can be referenced throughout the main part of the query. Remember this syntax because we’ll be using it again below.]

Google went with Port Hardy, based on USGS data (although they calculate the distance differently that their source):

Natural Resources Canada’s website on the other hand referenced the small village of Port Alice, which is closer to the action but wouldn’t make the population threshold in most data sets:

Writing a better algorithm

If we agree that Port Hardy probably isn’t the best reference point for an event in the Pacific Ocean, then we are left with the question: can we design a better algorithm? A simple, but effective improvement would be to calculate the distance between nearby settlements but double the distance for the bits that cross over land.

So from Port Hardy to the epicentre is about 150 kilometres, but we’ll need to add about 75 km extra because about half of that is overland. From Tofino, however, it’s 170 km from point to point and only a smidgen extra for crossing Vargas Island on the way out to sea. That’s 225 km to 175: Tofino wins!


We’re going to build up our query in three parts, something which isn’t strictly necessary but it does make things a little easier to read and maintain.

The first step is to get a list of populated places that are within a reasonable range of the earthquake (we’ll use 250 km again) and which have more than 1000 inhabitants. Additionally, we’ll use PostGIS to create a line from that point out to the quake and pass up all this information to the next step in our query.

  name, pop_max, ST_MakeLine(geom, quake) AS line
FROM constants, ne_10m_populated_places
  pop_max > 1000 AND
  ST_DWithin(quake::geography, geom::geography, 250*1000)

The sub-query above will be referenced as the places table in the query below, which is where most of the hard work actually happens.

We take the results from the places query and join them to another Natural Earth data set which contains states, provinces and other subdivisions of countries around the world (you can load it with the same shp2pgsql command I used above). Basically, this new table tells us what parts of the world are covered by land and what parts are not. By finding the intersection between our line and any land polygons, we can calculate a new land_line geometry for each of the places we found above.

SELECT, places.pop_max, places.line,
  ST_Collect(ST_Intersection(places.line, land.geom)) AS line_land,
  ST_Length(line::geography) / 1000 AS distance
  ne_10m_admin_1_states_provinces_shp AS land, places
WHERE ST_Intersects(places.line, land.geom)
GROUP BY, places.pop_max, places.line

We’ll add this new geometry and its length to the data we’ve collected about each place and pass them all up to final part of our query, referring to this as the places_land table.

  distance + ST_Length(line_land::geography) / 1000 AS weighted_distance
FROM places_land
ORDER BY weighted_distance

This is where we wrap everything up by calculating the weighted_distance, which is just the regular distance plus the distance of the part that crossed over land (dividing by 1000 since the length of the PostGIS geography data type is measured in meters).

Pulling these together we get this final, three-step query:

WITH constants AS 
(SELECT ST_SetSRID(ST_MakePoint(-128.15, 49.42), 4326) AS quake)
    distance + ST_Length(line_land::geography) / 1000 AS weighted_distance
      ST_Collect(ST_Intersection(places.line, land.geom)) AS line_land,
      ST_Length(line::geography) / 1000 AS distance
      ne_10m_admin_1_states_provinces_shp AS land,
      name, pop_max, ST_MakeLine(geom, quake) AS line
    FROM constants, ne_10m_populated_places
      pop_max > 1000 AND
      ST_DWithin(quake::geography, geom::geography, 250*1000)
    ) AS places
    WHERE ST_Intersects(places.line, land.geom)
    GROUP BY, places.pop_max, places.line
  ) AS places_land
  ORDER BY weighted_distance

All that’s left is to run the query and see what we get:

      name      | pop_max |     distance     | weighted_distance
 Tofino         |    1655 | 170.322296453086 |  170.996532624216
 Port Hardy     |    2295 | 151.591959991648 |  213.424215448539
 Campbell River |   33430 | 219.404018781354 |  336.005258086551
 Courtenay      |   32793 | 229.792897985687 |  344.417265701763

It works: this earthquake is best described as being 170 km from Tofino by our reckoning!

The query above is only really suitable for points at sea, but you can adapt this code for cases where points are on land as well … and of course the exercise is not limited to earthquakes, but can be applied for any kind of disaster or event. With some additional creativity, we could  also tune our algorithm to prefer places with more inhabitants over those with fewer. And of course, you can always change the search radius of 250 km or the population threshold of 1000 inhabitants.

Finally, if you want to pack this all up and create an application with OpenGeo Suite, I suggest checking out our recent blog post on publishing SQL queries like this in GeoServer and passing parameters to make an interactive and dynamic layer to show on a map!


My First FOSS4G

A Whole New World

Being a new developer at Boundless, freshly out of university with my degree in Computer Science, I haven’t had much practical experience yet. While I have a decent understanding of programming and awareness of popular languages and frameworks, I am still building my knowledge of geospatial software while working at Boundless  on GeoServer. Also, open source communities were something I knew about, but I had never been a part of one.

So, with FOSS4G NA 2015, I was really diving into a whole new world. I didn’t know what to expect out of an open source conference, or if it would prove friendly to newbies.

Here is what I found.


Something that impressed me at the conference was the diversity. I found a wide range of people from varying backgrounds and levels of experience. Some were highly academic and studying sciences, while others were masterful cartographers. Then there were quite a few developers like myself who really weren’t veterans of geospatial. Notably, there were a sizable portion of women were at the conference, many of whom were presenters.

The topics were diverse too. The first day had some beginner-friendly sessions, including introductions to GeoServer and QGIS. Then there were “theme days”,  a concept I thought was awesome: Tuesday was PostgreSQL day, Wednesday was Big Data day, and Thursday was Web Mapping day. Other talks were going on, but I found the theme talks were especially popular. Plenty of beginner material was presented along with more advanced topics, so there was something for everyone.

Further, EclipseCon was hosted jointly with FOSS4G NA this year, providing even more diversity of people and backgrounds. Everyone who registered for one conference could attend sessions at the other. This allowed an interesting overlap of developers and scientists to mix and talk to each other. Seeing how people from different fields work differently can provide interesting insights and expand our knowledge.

Learning GIS and Software Development

Above all, my goal going into FOSS4G was to learn. A few sessions stood out in particular as great resources to me.

On the geospatial side, the list is too long to put everything here, but I’ll highlight the ones I found the most helpful and useful. For those interested in scripting with Python, the Intro to Spatial Data Analysis in Python by Jenny Palomino provided a lot of background on the many available libraries and frameworks for working with spatial data. Paul Ramsey’s PostGIS Feature Frenzy was great for introducing the power of PostGIS. There was also a whole educational “training academy” which was presented by Philip Davis in Building a Sustainable Open Source Training Academy Using QGIS. Finally, the Birds of a Feather session for GeoServer had the Boundless team as well as Andrea Aime from GeoSolutions there to answer questions and help people with GeoServer.

From the Eclipse side of things, I thought Shay Shmeltzer’s presentation on iOS Development with Eclipse and Java was particularly interesting, especially because a lot of people assumed that wasn’t possible! Another fascinating presentation was Think Before You Code by Lizzi Slivinski which promoted a good discussion about user experience (UX) and design in general. Finally, Katy DeCorah provided guidelines and considerations for writing in her presentation, Writing For Everyone.

Code Sprints and Hackathons

For the developers, there were plenty of opportunities to write some code and receive help from experienced members of the community. Tuesday night had a room dedicated for a hackathon, where I was able to meet with Andrea Aime to do some much needed bug fixing for GeoServer. Also, Boundless hosted an additional code sprint on Friday. Torben Barsballe, another new developer at Boundless working on GeoServer, and I got some help from Andrea to get started with CITE tests. The time went by really fast, but we got quite a bit done for only having a few hours. Thanks to the organizers for providing us a hackathon space, and to Boundless for the space for an additional code sprint.


FOSS4G really broadened my perspective. There are a lot of exciting things going on, especially with advances in web mapping and a greater desire to move to the cloud and process big data. It aligns well with what we’ve been working on for GeoServer and making sure it’s ready to scale up and out to meet client needs.

I think the best part about FOSS4G was that it felt welcoming. People were very open and friendly. Experts were happy to talk and share what they know, even with newbies. All the knowledge felt available for anyone who wished to pursue it. Regardless of who you are or where you stand, FOSS4G is a great experience.

Thank you to everyone who organized this year’s FOSS4G NA, and a big thanks to Boundless for sponsoring the event and giving me the opportunity to attend. Looking forward to next year.


Embarking on a Journey with FOSS4G-NA 2015

I’m relatively new to Boundless as I build my career as a Java Developer – so it was timely during the week of March 9 I was able to attend FOSS4G-NA in San Francisco. As someone new to software conferences like this, I’d like to offer some reflections to hopefully share how these events can be as positive an experience for the New Guy as they are for the veteran.

Here’s what I found – the conference schedule was well paced, with a good variety of presenters and presentations covering numerous topics in the FOSS4G space. There were also a number of events outside of the presentation schedule where I got to interact with other people who were here for the conference – in many ways, this was the most eye-opening part of the experience for me. Real work gets done at conferences outside of the sessions, not just sitting in the auditoriums.

As noted, I am a Java Developer, so I also felt lucky the event was co-located with EclipseCon. It gave me the opportunity to address multiple interests within one event, and I can only hope other conferences offer me this breadth of information.

Some of the highlights of my experiences at FOSS4G were:


PlanetLabs presented a number of talks about their project to image the entire planet at 3-5 m resolution using a fleet of satellites. These satellites are built in-house using an “agile aerospace” approach, which entails lots of small, cheap satellites with fast turnover. This is a novel change from the conventional monolithic aerospace development strategy, and allows PlanetLabs to deploy and test improvements and changes quickly and cheaply. Since each satellite is a relatively low investment it also means that individual failures are not catastrophic. PlanetLabs also hosted a social event at their office/lab, and showed us where they build and program their satellites and mapping software.

Mapping Drones

One of the themes of Wednesday was drones. I saw presentations on how to build your own drone, and on OpenDroneMap, a piece of software for rendering drone-collected imagery in three dimensions. I also attended a presentation about kites as an alternative to drones: they are stronger, cheaper, and can stay up for longer, and people don’t feel threatened by kites like they do drones. This is especially relevant with all the discussion about drones and privacy these days, and provides an interesting look into human psychology, and how we are more accepting of what is familiar than the what is new.

Java 9 and Beyond

As part of EclipseCon, I attended a keynote on upcoming Java features. This included a discussion of a major feature of Java 9, the modular JVM. Even more interesting were some of the plans for future Java releases. These include a “value” class, which is essentially a class that behaves like a primitive, as well as primitive support for Java Generics. These future additions have been a long time coming. Primitive support for generics will be especially nice as it will eliminate the need to null-check every simple list of numbers, and greatly enhance memory efficiency as well.


As most GIS people probably already know, Cesium is a JavaScript globe and mapping library. The Cesium team made a strong showing at FOSS4G with a demonstration of 3D temporal data visualization of GPS traces using Cesium. They also presented a number of cool demo applications (that you should totally check out), which are available online:

Overall, I found FOSS4G-NA to be a valuable experience, and I would be interested in attending future conferences if I were given the opportunity. For this FOSS4G, I tried to go to talks on a wide variety of topics to explore what sort of stuff was out there. While this was definitely valuable for me as a beginner, there were definitely some things that went over my head.  If I were to go to similar events in the future, I feel like I could focus more strongly on topics that would broaden and develop my skill-set as GIS Java Developer.

Using WMS time to explore your data

A feature of GeoServer that’s not very well known is that it can publish layers that contain a time component. Clients can request data for a specific date/time, a list of dates/times, or even over a range. This is built-in to the WMS protocol; no third-party requirements are necessary here.

This can of course be used to create animations (see the MapStory project for a high-profile example of this), but even simpler, it can be used to just highlight another dimension of a dataset in a useful way.

With the release of GeoServer 2.7, the ability to request relative intervals has been added as well. Previously each request had to include absolute intervals, but now you can request data with parameters that include, for example, “<some date> and 30 days before it” or, more interestingly “10 years before <today>” where <today> is the server time.

So I thought it would be interesting to highlight this feature in GeoServer to give you some ideas and inspiration on how you can adapt this to your data.

The states and the union

First, let’s take a look at a dataset. One that I happen to have handy is the order in which the states of the USA joined the union. (Taken from MapStory.)

I’ve stripped down the style here to make comprehension easier. For each feature, there is an attribute called Date_of_St which is a timestamp accurate to the day.

For example, the value of the Date_of_St attribute for the feature representing Hawaii is listed as 1959-01-03T08:00:000Z This jives with the official date as listed on Wikipedia, though I suspect the hour may be one level of precision too ambitious.

We can set this attribute as a “special” time dimension in GeoServer. Once the layer is loaded, in the Edit Layer configuration area, the Dimensions tab contains the ability to link an attribute to the time dimension.


For our purposes, we really only care about the year. Luckily—and this is a big advantage of using WMS dimensions for this—requests need only be as precise as you want. So if you want to request a date range of 1900-1950, you don’t need to specify it as:


Instead, you can just write:


(Imagine trying to make this flexibility of input happen without this feature. Think of generating a text string search to match up the dates exactly. No fun at all.)

We’re going to make requests to GeoServer to find out which states joined at which times. The full WMS request, utilizing OpenLayers, is a mouthful:


But for tutorial purposes, I always prefer using the WMS Reflector, which makes reasonable assumptions about the request for the sake of brevity. That same request above can be shrunk to this:


Much better right? Except one little pitfall about enabling WMS time is that when not specifying any times, the map will only render features with the latest time, which leaves us sad little Hawaii (being the most recent state added):


But with this setup, it’s quite easy to make maps of states at certain times.

The states of the states

(The following code snippets need to be appended to the above request.)

The thirteen original colonies (1790):


Thirteen original colonies

The states as of the onset of the Civil War (1861):


Lots of independent territory still out there

The states that joined up during the Civil War. The US Civil War was fought from 1861-1865, but if we were to just use the string 1861/1865, we’d include Kansas, which just predates the Civil War (as seen above).

So we’ll need to get more precise, and add in the month: April 1861 to April 1865.


I did not know about Nevada joining during the Civil War, so I learned something here.

(Again, notice how easy this is with WMS dimensions; all of the work of interpreting the time is done for us.)

Finally, the states that were created in the last 120 years:


I believe the US stays at 50 states because it's such a nice round number...

This takes advantage of the new relative time support. This also means that the output of this request could itself change over time.

(The above image was reprojected to make Alaska look less huge. This is way easier using the WMS Reflector, as all you need to add is the srs parameter.)

More interactivity?

Now, it’s easy to envision a little app that takes as input Start and End dates and refreshes the map accordingly. And if people want to see that done (or anything else along that line), please leave a comment below.

And if you want to see this dataset animated, check it out over on MapStory.

No matter how long you’ve been working with GeoServer, there’s always more to be learned. Check out our Education Center to learn more!

Have you used the WMS time feature? Let us know how in the comments below!

Support story: Getting more out of SQL Views

Most GeoServer users know how to publish tables from a database such as PostgreSQL or Oracle as vector layers. More seasoned GeoServer users, however, also take advantage of SQL Views to publish those same tables with even greater control.

So what is an SQL View? A SQL View is a type of layer that is based on a database query that you write inside GeoServer itself. To the end user, it looks like a regular layer, but behind the curtain, you have all the power of spatial SQL at your fingertips to enrich the data that your users receive.

Uses of SQL Views

There are a number of different reasons to incorporate an SQL View into your application. For example, it’s possible to:

… only expose certain attributes to users:

SELECT geom, id, name FROM banks

… run spatial queries to do spatial computation or analysis:

SELECT *, ST_Area(geom) AS area FROM countries

… join two tables together:

SELECT airport.geom,, city.population
FROM airports AS airport, cities AS city

… convert data types that GeoServer doesn’t support:

SELECT id, name, geom, iwxxm::text FROM weather_stations

IWXXM data is stored in XML, which can be stored and validated natively by PostgreSQL (as can JSON, arrays and other types), but is not available in GeoServer. But by adding ::text, we convert it to text and expose it as a regular attribute in our layers.

Using view parameters

We can take these static SQL Views one step further by adding parameters to our SQL queries to make dynamic OGC requests based on user input. Boundless has some examples of using parameterized SQL Views in our various tutorials, including GeoNames Heat Map, Building a Census Map, and Building a Routing Application.

The trick is to add parameters to the SQL View that can be specified during a WMS or a WFS request:

SELECT * FROM buildings WHERE type = '%type%'

When we make a WMS GetMap request, for example, we can add the following to the URL:


The result will be the execution of the following query on the database:

SELECT * FROM buildings WHERE type = 'hospital'

If you go to our Geonames Word Map demo and type “canyon” as the search term, you can see the following WMS request being sent to our server:

Buried in there is VIEWPARAMS=word:canyon, and if you open this URL in your browser, you’ll see the results of the query are taken by GeoServer to generate a heatmap.

Our routing application uses multiple parameters (source, target and cost) to generate the path between two points.

Once you’ve added them to your GeoServer toolkit, you’ll wonder how you ever did without SQL Views!


Allowing a GeoServer client to influence the SQL that will be executed on your database opens the door to an SQL injection attack. To prevent the client from running arbitrary SQL code, GeoServer comes with parameter validation using regular expressions. We know that regular expressions can have a steep learning curve, but let’s go over some easy examples.

We must consider what values we want to allow for each parameter as the first step to crafting a validation expression.

Take the following SQL query:

WHERE city = '%city%' AND population > %rank% AND type = '%type%'

In this example, we will accept any city name with alphabetic characters (A-z) and spaces (\s) giving a regular expression of ^[A-z\s]+$. Population is always a number (\d) so we can use ^\d+$. Finally, for the road type, we only want to accept one of the following: highway, primary, secondary and residential. This gives the following expression: ^(highway|primary|secondary|residential)$.

By default, GeoServer uses a slightly more permissive (but usually safe!) ^[\w\d\s]+$, which allows letters, numbers and spaces for all parameters.

With these controls, we have prevented a malicious client from crafting a SQL injection that could potentially destroy our data. If a client does attempt to use a parameter that fails the regular expression check (for example: VIEWPARAMS=city:London,rank:1,type:tertiary), GeoServer will return an error:

Invalid value for parameter name

More importantly the SQL will not be executed!


So what’s the catch? There are a few things we have to take into consideration when using SQL Views. The main points of attention are:

First, be aware of potential performance implications. If you write complex SQL queries, remember that each time you make a request, the query will be executed. If it’s a slow query, your users will be waiting that much longer for a response.

Second, layers built from SQL Views are read-only. This means that you can’t use WFS-T to write back to the layer, unlike regular layers that have been published from regular database tables.

More reading

The Boundless Workshops page is a great place to read about the practical use of SQL Views in applications.

For a thorough discussion, see the OpenGeo Suite User manual’s section on SQL Views.

OpenGeo Components vs. OpenGeo Suite


As a solution engineer for Boundless, I receive a lot of questions from users about how to best integrate the OpenGeo components to help solve a problem. But there is one question I get asked more than any other…what is the difference between OpenGeo Suite, and the individual software components that make it up? Sometimes asked differently, should I install GeoServer from the OpenGeo Suite or from the community download page? This is a great question and I hope this blog post helps to clear up some of the confusion around Suite and its component parts. Here goes…

OpenGeo Components

In order to clear up some common misconceptions, it’s important to understand the distinction between the components and Suite. As you no doubt already know, all of the components of the OpenGeo suite are open-source software projects with a community of developers behind them.

  • PostGIS – a spatial database extender for the PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL (
  • GeoServer – GeoServer is an open source server for sharing geospatial data (
  • GeoWebCache – a Java web application used to cache map tiles coming from a variety of sources such as OGC Web Map Service (
  • QGIS – a free and open source desktop Geographic Information System (
  • OpenLayers – A high-performance, feature-packed library for all your web mapping needs (

While the specific open-source license for each varies slightly, they are all considered Free and Open Source Software (FOSS) applications without any license fees or royalties. You can download the individual installers for various operating systems directly from the community websites listed above.


It is important to understand that the individual developer communities, not Boundless, officially control these individual software packages. This means that the communities themselves decide how and when bugs get fixed, what enhancements go into future releases, and even how often new versions are released. If you run into a problem or bug while using these community versions, users are typically pointed in the direction of community blogs, forums, and email list-serves to get the help you need. Documentation is usually provided on the community websites, but there aren’t too many training and certification pathways established by these communities at this time.

OpenGeo Suite

The OpenGeo Suite available on the Boundless website, builds upon the individual open source components by including maintenance installers, documentation, code samples, and more. Think of it as an easy way to kick start your geospatial project. One single install package for configuring all of the components at one time. Plus you get access to additional documentation, blog posts, and videos created by the Boundless team to help get you up and running quickly.


Another advantage of using the OpenGeo Suite is version control of the individual software components. You see, each version of the OpenGeo Suite has been tested and verified to work with a specific release of the open-source components that make it up. For instance, OpenGeo Suite 4.5 includes GeoServer 2.6, OpenLayers 3, etc. This makes upgrades within your organization very simple. Rather than trying to keep track of each component version as the community releases it, migrating Suite means you only have to keep track of one version number. That’s it! Upgrading made simple.

This means that it is possible for the community version of one of the components to be different than the version included in Suite. For example, the community may be ready to release GeoServer 2.7 (based on its release cycle), but we are still maintaining 2.6 in Suite (based on our release cycle). This is sometimes done in the interest of maximizing the stability and interoperability of Suite. But it helps to answer the question of are the versions in Suite and in the community the same. Sometimes they are, sometimes they aren’t. Either way, rest assured that as a Suite user the Boundless Support and Engineering teams will support you regardless of version number.

Side note: as an added bonus, for organizations which require all software to be certified, scanned, or approved before installing, using Suite means you are only scanning 1 software package, not 5, as you would using the community components.

OpenGeo Suite Enterprise

To truly maximize all that Boundless can offer, you will want to consider to OpenGeo Suite Enterprise. OpenGeo Suite Enterprise is known as Commercially Supported Open Source which means in addition to the community software, documentation and code samples from basic Suite, there is a full complement of expert support, training and professional services available to support robust enterprise installations. In fact, many government organizations will not allow open source software to exist inside their enterprise unless a support and/or maintenance package comes along with it. OpenGeo Suite Enterprise provides this capability.


For starters, OpenGeo Suite Enterprise comes with some extra software components that Boundless has created. Composer, a tool for creating, styling, and publishing maps, makes authoring and publishing maps to GeoServer vastly easier than ever before. It includes a simpler styling syntax, real-time feedback, and convenience features such as code-completion and sample code. Other software components produced by Boundless include the Boundless SDK, for building and deploying web mapping applications, as well as special offers for QGIS support.

Enterprise provides you full technical support to help you through any issues you might come across. If you think you might have run across a bug, simply call or email Technical Support and we can help track down what might be the issue. If the issue is discovered to be a bug, our engineering team can provide workarounds or patches to quickly resolve your issue and get you back working again. Also know that any bug fixes Boundless creates are offered back to the community for inclusion in the component software. New for 2015, we are working on consolidating a Knowledge Base for Enterprise customers, to enable a more self-service support mechanism should you prefer that method.

With Professional Services engagements, our expert technologists will work side-by-side with your team to guarantee that best practices are met at every phase of your project, helping you make the most of your investment in Boundless technologies. Professional Services engagements can be large or small, and can be customized to meet the needs of your organization. Our most popular engagements include:

  • Migration Assessment
  • OpenGeo Suite Pilot
  • Architecture & Design Review
  • Scale Up & Out
  • OpenGeo Suite Developer Support
  • Deployment Assurance Plan
  • Technical Account Management Plan

Boundless not only develops the best open source geospatial software, we also teach you how to use it. No matter your skill level, we have courses to suit your professional development needs. Start with our free tutorials or workshops then progress to our online training and our certification programs. For teams that need to get up to speed we also offer on-site courses customized for group settings. On-site courses are available in our Washington DC training center or, by special arrangement, at your facilities.

Finally, Boundless employs many of the same engineers who are contributors to the community open source projects. Working with Boundless through OpenGeo Suite Enterprise gives you direct access to those developers and the communities they support. This grants you the ability to provide feedback to the community about the direction you would like to see the software go. We have outstanding relationships with the communities behind OpenGeo Suite and are always working to positively shape the future of the components.


Hopefully this post helps to illustrate the difference between the open source components and the value of utilizing the OpenGeo Suite. Application Developers with a DIY spirit have found great success downloading the individual components and working with the open community to accomplish their projects. But organizations working through Boundless and the OpenGeo Suite have benefitted from access to enterprise grade technical support, training and professional services to get going. Plus the added benefit of additional software for monitoring your enterprise and sharing geospatial content.

So what are you waiting for? Get started now by downloading OpenGeo Suite from our website here:

OpenGeo Suite & Google Maps Engine

Google has made a well-publicized announcement that it is deprecating support for Google Maps Engine (“GME”) as of January 29, 2016. It’s for sure that Google’s not getting out of the Maps business – if anything, their announcement over the past weekend making Google Earth Pro free demonstrates a strong interest in growing the adoption of maps, which we can all get behind – but it does seem a rather clear statement of the level(s) Google wants to serve. There’s a gulf between the use cases more commonly associated with Google’s consumer-friendly mapping capabilities and the sophistication in location intelligence increasingly demanded by enterprise use.

If you are an organization currently leveraging GME for your commercial use case, we strongly encourage you to include OpenGeo Suite in your technology evaluations. As an open source technology stack with a robust community in place for a decade or more, OpenGeo Suite is a mature, powerful, yet cost-effective geospatial solution which can address a comprehensive variety of commercial use cases.

While on the topic of use cases – we’ll be the first to tell you that the focus of OpenGeo Suite is to create rich maps to fulfill enterprise needs. Organizations with few enterprise requirements and lightweight sets of data may find OpenGeo Suite more than they need if the intent is to simply recreate what exists with GME.  OpenGeo Suite is for organizations who meet one or more of the following criteria:

  1. You’re looking to step up your game without breaking the bank

You know that you’d like to unlock greater intelligence from your data and you think creating additional location-based visibility would help. You’ve made decisions in the past based on the constraints of GME, particularly around the data.  You think in general you could express more with the visualization of location-based information.

However, wanting to do more does not necessarily equate to having the funds in place to execute, so it is necessary to identify solutions that keep cost control in mind. You are likely sensitive to the costs and lock-in associated with proprietary GIS software. OpenGeo Suite, as open source software, is available to all for the construction of mapping resources. Boundless provides our customers with optional support and additional functionality – contact us if you’d like to learn more – but the base software is available to all on an open basis to provide a powerful geospatial platform with a wide variety of capabilities.

  1. You’d like more: More options, more control, more capabilities

OpenGeo Suite significantly expands the options available compared to GME. Data can be leveraged in virtually unlimited fashion from a variety of platforms, including native PostGIS, Oracle, Microsoft SQL, or even NoSQL databases such as MongoDB. OpenGeo Suite also leverages a much wider variety of standards-based web services to expand what information may be passed, while also providing web editing and drawing tools currently unavailable in GME.

  1. You’re looking to go beyond and think out of the box

GME provides a stock set of base maps, which works for a pre-defined set of visualization requirements. However, OpenGeo Suite enables organizations looking to think out of the box when looking to create beautiful maps via full customization of both look and feel as well as perspective. Organizations adopting OpenGeo Suite can tailor visualizations to best fit the human element of their organizations.

There’s a wealth of available information on OpenGeo Suite, both on this website as well as other community sites on the web. We challenge anybody who is looking to get more out of their location intelligence without breaking the bank to take a look, not just users migrating from GME.


Ann’s Thoughts for 2015

Ann JohnsonAs we mentioned in our recap of 2014 blog posts, the new year is a good opportunity to reflect for a moment on 2014 before looking forward to the great things we hope to accomplish in 2015. To name just a few: we shipped several releases of OpenGeo Suite, we launched the private beta for Versio, we grew our professional services offerings, and we’ve hired (and are still hiring!) many new and talented team members as well as investing in new offices in NYC and St. Louis to better serve our customers.

Looking forward to 2015, Boundless will maintain our core strategy to extend our lead as the world’s provider of Spatial IT. There are many great open source companies out there we can look to for examples and reference on how to become a leading provider of open source tools and services to further the cause of Spatial IT. Some are larger and more established, some are newer but highly disruptive – companies like Cloudera and MapR (Apache Hadoop), Acquia (Drupal), Canonical (Ubuntu), DataStax (Cassandra), Docker, Automattic (WordPress) and Pentaho, to name a few.

The hallmark of all of these companies is they have worked to build successful businesses around great open source software. Their success enables them to not only grow but to return investment back to the core software, to mature the code and functionality as well as promote continued adoption across an increasing number of organizations. This is an obligation for Boundless as well — to continue to increase our level of responsibility and involvement in components of OpenGeo Suite, it is also incumbent upon us to find the paths for the continued promotion and adoption of the technology. We are committing 10% of our developers’ time to allow for greater levels of contribution to various open source communities and projects including PostGIS, GeoServer, OpenLayers, QGIS, GeoGig and others. We will continue to support this effort over the long term as Boundless grows, thereby providing even more resources to the community.

In addition, Boundless will be focused on enhancing and growing our mobile and cloud-based service offerings as well as continuing to make open source tools more consumable for a broader audience by focusing on usability, scalability and a wide variety of professional services, training, and support offerings.

Boundless remains committed to being the preeminent provider of Spatial IT tools and a strong supporter of open source communities. We look forward to continuing our journey as the entire spatial software industry evolves and grows. The ability to provide software and services that are easily consumable across an entire customer enterprise and support our customers’ key business objectives are our primary drivers for the future of Boundless.

Happy New Year!

Best Posts of 2014

As we begin the new year, it is a good opportunity to reflect for a moment on 2014 before looking forward to the great things we hope to accomplish in 2015. To name just a few: we shipped several releases of OpenGeo Suite, we launched the private beta for Versio, we grew our professional services offerings, and we’ve hired (and are still hiring!) many new and talented team members.

We also posted dozens of blog posts over the course of 2014 and many of them proved quite popular:

  1. Going “Open” with Esri?
  2. GeoGig in Action: Distributed Versioning for Geospatial Data
  3. QGIS Compared: Visualization, Cartography, Analysis, Editing
  4. Introducing Versio: Distributed Version Control for Spatial Data
  5. OpenLayers 3.0 Released!
  6. Citi Bike Analysis and Automated Workflows with QGIS
  7. LIDAR Format Wars
  8. QGIS for the Bay Area Bike Share Open Data Challenge
  9. OpenGeo Suite 4.5 Released!
  10. Openwashing
  11. Mapping #WorldCup with OpenGeo Suite and MongoDB
  12. Support Stories: Labelling a MultiPoint geometry with WPS
  13. Recovering from Yolanda with help from OpenStreetMap and GeoGig
  14. PostGIS Training: Creating Overlays

Unsurprisingly, many of the most popular posts on our blog over the past year were also focused on OpenLayers 3 and several seemed worth at least an honorable mention:

Did one of your favorite blog posts not get mentioned in the list above? If so, let us know on Twitter!


Merry Christmas, nerds! Have you ever wanted to connect your PostGIS database directly to an existing GIS file or database and read from it without importing the data. I have good news, repeat after me: OGR FDW FTW!

(How did this happen? Boundless provides its engineers with “innovation time” to pursue personal technical projects, and this year I chose to blow all my time in one go on this project. Like the idea of innovation time? Join us!)

OGR, is the vector subsystem of the GDAL open source format library. The OGR API lets applications read and write to many different formats (Shapefile, Oracle, SDE, MapInfo, PostGIS, FGDB, GML, etc) without having to import them first.

FDW, is the PostgreSQL API for implementing “foreign data wrappers”: virtual tables in the database that are actually connections to remote data files, repositories and servers. There are FDW implementations to connect to MySQL, Oracle, SQLite, and even flat text files!

FTW, is “for the win”! Because the OGR API is a simple table-oriented read-write library that is practically begging to be hooked up to the PostgreSQL FDW system and expose OGR data sources as tables in PostgreSQL.

Here’s how it works.

First, go to the source code repository, build and install the ogr_fdw extension.

Next, create the ogr_fdw extension and the postgis extension.


Now create a “server”. For a database FDW, the server would be an actual database server somewhere. For the OGR FDW, a server is an OGR connection string: it could be a database server, a directory full of files, or (as in this case) a web service:

    datasource 'WFS:',
    format 'WFS' );

Now create a “foreign table”. This will look just like a table, to the database, but accessing it will actually create an access to the remote server.

  fid integer,
  geom geometry,
  gml_id varchar,
  state_name varchar,
  state_fips varchar,
  sub_region varchar,
  state_abbr varchar,
  land_km real,
  water_km real )
  SERVER opengeo
  OPTIONS ( layer 'topp:states' );

Now, treat the table like you would any other PostGIS table, and ask it a question in SQL:

SELECT st_area(geom::geography) 
FROM topp_states 
WHERE state_name = 'Missouri';

And the answer comes back: 180863 sq km.

How does it work? The PostgreSQL query fires off an OGR query to the server (in this case, the OpenGeo Suite demo server) which pulls the table down, and it is then filtered and calculated upon locally in PostgreSQL.

Could it be better? Sure!

It could push SQL restriction clauses down to the OGR driver, reducing the quantity of data returned to the server. For big tables, this will be very important.

It could restrict the number of columns it returns to just the ones needed for the query. This will make things a little faster.

It could allow read/write access to the table, so that INSERT, UPDATE and DELETE queries can also be run. This opens up a whole world of interoperability possibilities: imagine your database being able to directly edit a File Geodatabase on the file system? Or directly edit an ArcSDE server in a workgroup?

The biggest limitation of the PostgreSQL FDW system is that it requires a table definition before it can work, so you require a priori knowledge of the table structure to set up your tables. Because this just creates busywork, I’ve also bundled a utility program with the ogr_fdw extension: ogr_fdw_info. The utility will read an OGR data source and layer and return the SQL you need to create an FDW server and table for reading that layer.

Enjoy wrapping your foreign tables, and enjoy the holidays!