I was recently presented with a fantastic opportunity; my manager approached me and asked:

“Hey Ian, what do you think about leading a GeoNode training in the Caribbean?”

Without hesitation, or asking for details I said, “Sign me up!”  Though my manager’s smirk should have tipped me off I had no idea how challenging the assignment would be. Nor did I realize that I would find the trip rewarding in ways other than what one typically thinks when that sunny, sandy, pina colada filled, cerulean-hued region of the world is mentioned.

The training was a part of the OpenDRI initiative and took place Feb 18-23 at the St. Augustine Campus of the University of the West Indies (UWI) in Trinidad and Tobago. The event, co-sponsored by the World Bank, the Global Facility for Disaster Reduction and Recovery (GFDRR), and the University of West Indies, brought together 40 GIS specialists and developers from around the Caribbean to provide them with the skills needed to better use, integrate, and extend GeoNode as a component of their specific spatial data infrastructure.

I lead a developer workshop in which 13 participants learned to install and configure GeoNode, create a custom “project”, theme it, and add new functionality related to security. We also threw in an unexpected (read: bonus) section on virtual networking (we used a
VirtualBox appliance and ran into potential problems related to running a
server with a changing IP address). In addition to my inane jokes, I shared all of my bash shortcuts and Python programming tips.

In the evening, there were discussions and presentations on topics such as OpenStreetMap, OpenDataKit, and NASA’s Pilot DRM Program. I’ll miss all of the fantastic Trinidadian food (chokas, coconut bake, roti, buss-up-shut and saltfish to name a few), along with the great people I met. Unfortunately I didn’t allot enough time to enjoy much of island but will look back on my one free afternoon in Maracas Bay fondly.

My special thanks to the World Bank, the Global Facility for Disaster Reduction and Recovery (GFDRR), and the University of West Indies for bringing me down. If you’re interested in such a training, or just want to fly me to nice sunny places please let us know!

Here at OpenGeo, 2012 was an exciting year. We had major releases, components upgrades, a good deal of growth and more. While reviewing our 2012 blog posts, the sheer amount of news became abundantly clear to me. I decided to take a dive into the analytics and look for which posts you found the most interesting, which caused the greatest reaction and which were tweeted, shared, and commented on the most. With a little bit of effort, I was able to pull up the top posts of last year and compile them in the list below. Maybe you missed them the first time, or perhaps you’d like to give them another read.

1. OpenGeo Suite 3.0 Released!
   Coming in as the number one post of 2012 was the announcement of OpenGeo Suite 3.0. No surprises here as the 3.0 release brought a ton of exciting new features to the table, including server-side processing, security enhancements, and upgraded components.
2. Creating a GeoServer Split Polygon WPS Process (Part I)
   In the number two entry, Martin Davis lays out the steps on using WPS to split polygons in GeoServer.  It was a particularly compelling post at the time since WPS had just been introduced to GeoServer and was about to be added to the OpenGeo Suite. In case you were wondering, the follow up post was published one month later.
3. Visions for OpenLayers 3
   Last summer Tim Schaub, our CTO and OpenLayers PSC member, laid out a plan for OpenLayers 3. For more background information check out the follow up post Why OpenLayers 3.0?. After successfully raising funds, including a a great showing through the indiegogo campaign, the OpenLayers team has enough in their coffers to begin developing OpenLayers 3 and will be meeting in the spring of 2013 for a sprint. Our thanks to everyone supporting OpenLayers 3.
4. Adding Layers to GeoServer Using the REST API
   In this post Sam Smith, our support guru, offers detailed instructions on how using the REST API to add layers to GeoServer can save time and headaches.
5. PostGIS 2.0 Released
   It looks like many of you were excited as we were about Paul Ramsey’s announcement of the PostGIS 2.0 release.
6. PostGIS 2.0 New Features: Typmod
   In the sixth most popular post of 2012, Paul Ramsey is showed off new features that made it into PostGIS 2.0. Later he released a similar post called PostGIS 2.0 New Features: 3D/4D Indexing
7. Surface Interpolation in GeoServer
   At number seven, Martin Davis is showed off new processing features, specifically rendering transformations.
8. Distributed versioning for geospatial data
   In this post, Chris Holmes weighs in with his series of white papers exploring distributed versioning for geospatial data.
9. Thematic map creation with SLD is now much easier
   No one ever said SLD was easy to learn. With new transformation functions, and this post, we hope to ease some of your pain.
10. Five things you didn’t know about GeoExplorer
    Rounding out the list is a great introduction to GeoExplorer, the map composition tool that comes bundled with the OpenGeo Suite.

That’s the top ten in 2012. As always, we appreciate your feedback. If you enjoyed something you read on our site or our blog please feel free to leave a comment or contact us at any time. Thanks for reading! We hope you stick around for 2013.

Following the success of the OpenGeo Suite 3.0 release, we’re proud to release 3.0.1. This release is primarily a maintenance and quality assurance release that contains several bug fixes, improved documentation, and component updates like GeoServer 2.2.1. OpenGeo Suite 3.0.1 is available for download free of charge with a 30-day trial of OpenGeo’s commercial support.

We’ve also introduced new offerings—Community One-Time and Enterprise Plus—to meet growing demand from smaller organizations seeking support for open source geospatial software. Community One-Time offers enterprise support to Community Edition users for one incident for up to 15 business days. Enterprise Plus provides a year of enterprise support for smaller production environments with straightforward support requirements, such as those publishing data from basic geospatial formats and serving a limited number of users.

More information is available in the release notes and our pricing page.

• Creating a GeoServer Split Polygon WPS Process (Part I): Martin explains the creation of a WPS process for splitting polygons using GeoServer’s Java API.
• Using GeoServer’s Split Polygon WPS Process (Part II): Tim follows up by describing how a web client can take advantage of this process to split polygons using utilities in available in OpenLayers.
• Surface Interpolation in GeoServer: Martin explains how NASA is using rendering transformations to display meteorological data collected from schools around the world.
• Managing fault tolerance in GeoServer metadata: David describes a new option in GeoServer allowing for increased robustness with lenient resource handling.
• INSPIRE View Service and GeoServer: Bart demonstrates progress towards INSPIRE compliance for European government agencies.
• Creating dynamic contour maps with server-side processing: Mike reviews how to create a dynamic contour map with GeoServer WPS.

Thanks again to everyone who helped test OpenGeo Suite 3.0-beta1!

As an avid cartophile and hiker, I’ve always enjoyed working with contour maps—vector maps in which lines circumscribe areas of similar or equal value—as they provide just the right amount of context for the vertical aspect of a trail. I routinely use contour maps when evaluating hikes, since being able to see the densely-spaced contour lines at given points is much more helpful than just knowing the total elevation gain of a trail.

So, when I learned that the OpenGeo Suite 3.0 contains a process to generate contour lines from raster data, I jumped at the opportunity to play with it. Neat, I can create my own contour maps! My thoughts turned to Mt. Rainier National Park, where I spent some time this past summer; I was eager to test the contour generation process on the largest eminence in the contiguous United States.

Mount Rainier (Wikipedia)

Mt. Rainier raster data in GeoExplorer

The first step was to acquire topological raster data. Despite a somewhat cumbersome download process I was able to obtain high-quality data via the National Elevation Dataset from the USGS, provided.  I eventually acquired a GeoTIFF with one arcsecond detail and loaded the data into GeoServer. While I could have taken advantage of new raster support in PostGIS 2.0, those features primarily support analysis, not visualization.

There are two ways of generating a contour map using the tools in the OpenGeo Suite: statically and dynamically.

I started out with the static case, processing the raster data and generating a vector layer of the contours using the Web Processing Service (WPS), which allows for server-side processing of data in GeoServer. With WPS, you can perform complex calculations and conversions, either by pulling from almost 100 built-in processes or by creating your own. For my case, the gs:Contourprocess was sufficient for my needs. While quite rudimentary, I used the WPS Request Builder in the GeoServer UI to generate my contour bands, since it’s more straightforward than having to generate the raw XML code for executing the process.

Contour process in WPS Request Builder

The data that I possessed had elevation data in meters, from a low of about 500 meters above sea level to Mt. Rainier’s peak at 4,392 meters. For a nice round number I chose 100 meter increments and then ran this through the WPS process,  piping the output back into GeoServer. In this case I saved the output as a shapefile and then imported the layer back into GeoServer, but I could just as easily have chained the output of gs:Contour to the input of gs:Import to accomplish the same thing.

With this vector data published, I styled the output by adding rules to label the lines and draw the 500 meter interval lines thicker, all features one would expect from a contour map. I also optimized my cartography for the web by only drawing the 100 meter bands at certain zoom levels to keep the map from becoming too cluttered when zoomed out.

Contour map of Mt. Rainier

Once satisfied that my style worked with the generated vector output, I set about creating a contour map dynamically by utilizing new processing features in OpenGeo Suite 3.0.  Using rendering transformations eliminated the intermediate step of generating derivative data by instead applying the gs:Contour process directly to the raster data using the layer’s style. I only needed to specify the transformation in the SLD and associate it with my raster layer to get exactly the same output in real time—without generating any new vector layers!

Contour map of Mt. Rainier in GeoExplorer

Though I stopped at this point, there are other ways I could have improved this further. For example, instead of using the SLD to selectively display the 100 or 500 meter intervals, I could have tied the interval parameter to the scale denominator of the map. This way, I could zoom the map in all the way and have bands with, say, 10 meter intervals, and then zoom out and render bands with 1000 meter intervals. This would further improve the interactivity of the web map without adding much overhead.

Learn more about creating a dynamic contour map with GeoServer WPS, including the SLD code used in the creation of this map.

Have you tried using GeoServer WPS processes? What have you accomplished with them? Let us know about your experiences by commenting below. And, if you’re ever in Mt. Rainier, I highly recommend the Skyline Trail—just be sure to bring winter clothing, even in summer and at lower elevations there’s likely to be snow!

Last week we announced the release of OpenGeo Suite 3.0. The release notes cover the nuts and bolts, the components updated, and more. This week we want to explain why we’re excited about 3.0 and why you should be too.

This release is both a culmination of many efforts and a launching pad for things to come. OpenGeo Suite 3.0 brings together significant technical advances in the open source components, including GeoServer 2.2, PostGIS 2.0, and GeoWebCache 1.3. From the beginning, each of these tools was built for the web, resulting in a product that is scalable at a fraction of the cost of the alternatives. While spatial data may present some unique challenges, OpenGeo has the experts to ensure it need not be more complicated than other forms of specialized data.

While it’s well established that open source offers superior scalability and reliability, it may occasionally lack certain specialized features or functionality. Yet this story is changing as open source projects increasingly outpace their proprietary competition—largely thanks to adoption and investment by enterprises and government agencies both large and small. Many of the improvements leading to WPS support and server-side scripting result from a prototype built for the USGS National Hydrography, Dataset, which turns a six-hour workflow into an operation that takes a matter of minutes. Similarly, rendering transformations were developed in part for NASA’s GLOBE program for the dynamic presentation of interpolated surfaces derived from environmental measurements collected at schools around the world. Running the Suite in production has been made easier thanks to our clients at NOAA, who funded improvements to GeoServer’s security subsystem as well as multi-tenancy improvements enabling a single GeoServer instance to publish multiple service endpoints using virtual services. And thanks to support from IGN France and Géoportail, the addition of OGC Web Feature Service 2.0 (WFS) brings the Suite closer to INSPIRE compliance.

These clients have learned that, with commercial open source, their investment isn’t squandered on license fees but instead returns responsive support and improved functionality. OpenGeo sees itself as a beekeeper in Pentaho’s beekeeper model: although honey is mostly free for the taking, consumers are generally willing to pay a beekeeper to cultivate, package, and distribute honey rather than dealing directly with bees themselves. The OpenGeo Suite makes it easier for those enterprises that lack the internal resources to support or develop open source software on their own to procure our support and expertise.

Download OpenGeo Suite 3.0 to see all of this for yourself. We’re is interested in what you have to say, and learning more about how you’re using open source geospatial software; any feedback you provide will help us continue to make and support great software. Contact us to let us know what you think, or to find out how OpenGeo can help you achieve your goals.

The release of OpenGeo Suite 3.0 adds many new features and improvements that will greatly expand the capabilities of our flagship product and ease replacement of legacy software with a modern web-based solution. Below are some highlights of what you’ll find in OpenGeo Suite 3.0:

• Server-side processing
  • OGC Web Processing Service (WPS) provides a standard for inputs and outputs (requests and responses) for geospatial processing services such as polygon overlays, buffers, or custom processes.
  • Rendering transformations make processing operations easier in browser-based visualizations by enabling just-in-time use of any WPS process as part of any layer’s style.
  • Server-side scripting in Python and JavaScript allows users to easily deploy their own server-side processes using concise and straightforward APIs.
  • PostGIS 2.0 brings vector and raster analysis into the database.
• GeoServer security now supports user groups as well as a number of new authentication mechanisms including LDAP, digest and X.509 certificate authentication.
• Virtual services allow GeoServer to support multi-tenancy, enabling a single GeoServer instance to publish multiple service endpoints.
• A new caching configuration interface in GeoServer includes the ability to define new grid sets, specify which layers to cache, seed or truncate the cache, and more.
• OGC Web Feature Service 2.0 (WFS) adds some interesting new capabilities, including paging, stored queries, and extended operators.
• Upgraded components, including the adoption of GeoServer 2.2, PostGIS 2.0, and GeoWebCache 1.3

Download the 3.0 release to see for yourself. We strongly advise reading the upgrade instructions and backing up all data beforehand as this release requires a backwards-incompatible upgrade. Packages are available for most common operating systems:

• Download OpenGeo Suite 3.0 for Windows
• Download OpenGeo Suite 3.0 for Mac OS X
• Get OpenGeo Suite 3.0 for Linux (RPM
• Get OpenGeo Suite 3.0 for Linux (Debian)

Questions? Help us continue to make and support great software by providing feedback on our GetSatisfaction forum.

Next week we’ll review how the OpenGeo Suite is a step forward for commercial open source geospatial software. In the meantime, if want to know more about the features listed above, read on! Read the rest of this entry »

As Hurricane Isaac intensifies and approaches the Gulf Coast we hope that everyone who will be weathering the storm does so safely. Last week, Isaac hit Haiti and the Dominican Republic, leaving barren fields, flooding, and dozens dead. We send our condolences to the families of those who fell victim and those who are still missing are in our thoughts.

Natural disasters like Isaac are never easy to handle but if there’s anything we can take away from them it’s that planning and preparedness can save the lives of those risk. The World Bank and OpenGeo find themselves at the unique cross section of disaster management and enabling technology. Our software is built to share information on on the web, which is a critical component of any disaster management plan. Various implementations of our software have been used to facilitate strategic disaster management planning.

In 2010 we began work with World Bank to help solve problems around distributing geospatial data  for disaster management. Officials in the field often face the dual challenges of being in hard to reach places with intermittent internet access and of having their data in numerous formats. The result of working together to define system requirements was building out many of the features in GeoNode.

One result of that collaboration is Haitidata.org, a specific implementation of GeoNode, created and operated by the World Bank and the Humanitarian OpenStreetMap team. Haitidata.org is designed to facilitate access to important disaster planning data to emergency response teams and other key players. This data is critical for practitioners to understand the potential impacts of potential and impending disasters, such as Tropical Storm Isaac, and conduct response operations if needed.

As Isaac approached Haiti on Thursday, August 24 we received a support request from Robert Soden of the World Bank. Robert’s contacts in Haiti were concerned that Isaac, then a tropical storm, would intensify to a hurricane as it approached Haiti. They began preparing by pulling data from Haitidata.org. Unfortunately they hit a snag when attempting to download the largest GeoTiffs, all of the information was there but the system would hang when users tried to download data. To support our client, and more so because of the impending emergency, our support team got right to work with The World Bank to diagnose and solve the issue. Within two hours Rob Marianski from OpenGeo and Ariel Nunez from the World Bank were able to deliver the following fixes:

1. Enable WMS-C integration was not set to automatic. GeoWebCache was working for all the layers but the setting was incorrect and it was not being hit.
2. Increase GeoWebCache disk quota from 500mb to 20GB.
3. Switch Tomcat’s's memory settings to 6gb. The machine had enough ram but the maximum amount was set to 2gb.

The team was also able to suggest the following for future use, but have not yet tested the suggestions yet:

1. Use of GeoServer control flow module to try to limit the resources taken by each request.
2. Present a download link to the original file instead of the WCS service, along with the file size so users know what to expect.

It’s a sad fact that disasters cause so much devastation but an emergency preparedness plan with reliable access to data can lessen the blow. Our coordinated effort with the The World Bank enabled representatives on the field from OCHA and Humanitarian OpenStreetMap to access HaitiData.org for flood plane, natural hazard and other critical data. If you’re interested in finding out more about this project, and others like it OpenGeo will be attending the International Conference Crisis Mappers (ICCM) hosted by The World Bank, from October 11 to 14 in Washington DC.

*This post was co-authored by Galen Evans.

NASA’s Global Learning and Observations to Benefit the Environment (GLOBE) Program, a federally funded education initiative, collects meteorological data from schools around the world to create a database of environmental measurements. The data is  displayed using contour surfaces on the GLOBE website. Using the OpenGeo Suite, we’ve been working with GLOBE to help improve the functionality and usability of the GLOBE website by rebuilding the map to allow fast, dynamic presentation of surfaces for observations on any chosen day.

The surfaces are generated using Barnes Surface Interpolation,  a technique that computes a surface estimated from scattered data observations.  We implemented a version of this algorithm in Java and optimized it to provide the performance needed for dynamic web mapping applications.

The Barnes Surface Interpolation algorithm is accessed via a powerful new GeoServer feature called Rendering Transformations.  Rendering Transformations allow performing custom geoprocessing within the map rendering pipeline in a highly flexible way.  Transformations can change data representation from vector to raster or vice-versa, depending on the kind of visual effect required.

In this case, the output of the Barnes Surface transformation is a raster representing the interpolated surface.  The raster can be styled using GeoServer’s SLD styling language and the styled surface can be combined with other GeoServer layers to do things like display the observation data points or computed contour lines.  The final map image can then be displayed over any base map, resulting in a fast, informative display of the contoured surface.  The speed of display allows dynamic zooming and panning, as well as quick changes to map options including measurement type, date range, or even the surface interpolation parameters.

Having this capability available directly in the server provides access to many of the powerful features of GeoServer, such as tiling and time-based animations. Other kinds of interpolated surfaces (such as Inverse-Distance Weighting or Kriging) can be added easily.  In fact, we’re currently developing more Rendering Transformations for spatial visualization techniques, including heatmaps and point clustering.  If you have any ideas for spatial data visualization, leave a comment!

At OpenGeo, we get lots of questions regarding licensing. The truth is that open source licenses are varied, broad, sometimes confusing, and are definitely not all created equal. We’ve written about licensing before on this blog, but there is of course more to say.

One question we get often from both prospective and current clients is:
Can a company that does not want to open their source code use the OpenGeo Suite?

Short answer

Yes.

Longer answer

The OpenGeo Suite is licensed GPL v2. This license applies to all flavors of the OpenGeo Suite (Community, Enterprise, Cloud, etc.). The components of the OpenGeo Suite use the following licenses:

• PostGIS: GPL v2 (Source)
• GeoServer: GPL v2 (Source)
• GeoTools: LGPL (Source)
• GeoWebCache: LGPL (Source)
• OpenLayers: BSD (Source)
• GeoExt: BSD (Source)
• Ext JS: GPL v3 (Source) or Sencha commercial license.

With all of this in mind, it is possible to create closed-source applications that depend on the OpenGeo Suite without having to distribute the code. However, if you are making code-level changes to the OpenGeo Suite or its components, you are obligated to redistribute those changes if you redistribute the software. So, the obligation to open source applies to modifications of the source code, not to any applications that leverage the software. You are free to provide whatever licensing on your code that you deem is appropriate.

Many people ask about dual-licensing the OpenGeo Suite (much like how Sencha does with Ext JS). However, as we’re a true open source company, we don’t own all of the intellectual property for our source code and are just as obligated by the license to distribute modifications as anyone else is. So, dual-licensing just isn’t an option.

While we promote open source application development (and do so in house), we respect that everyone’s needs are different and strive to be as accommodating as possible to any organization that wishes to use the OpenGeo Suite.

Hopefully this will clear up some confusion surrounding licensing, but as always, if you have questions, please feel free to comment on this post, send us a message on Twitter, or even a private message through our contact form. Happy coding!