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:

time=1900-01-01T00:00:000Z/1950-12-31T23:59:999Z

Instead, you can just write:

time=1900/1950

(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:

http://localhost:8080/geoserver/time/wms?service=WMS&version=1.1.0&
request=GetMap&layers=time:StateJoined&styles=&bbox=-178.21759836236586,
18.92178634508703,-66.96927103600244,71.40623536725487&width=699&
height=330&srs=EPSG:4326&format=application/openlayers

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:

http://localhost:8080/geoserver/wms/reflect?layers=time:StateJoined&format=application/openlayers

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):

time=1780/1790

Thirteen original colonies

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

time=1700/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.

time=1861-04/1865-04

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:

time=P120Y/PRESENT

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, airport.name, city.population
FROM airports AS airport, cities AS city
WHERE airport.city = city.id

… 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:

…&VIEWPARAMS=type:hospital

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:

http://apps.opengeo.org/geoserver/wms?FORMAT=image/png&TRANSPARENT=TRUE&
LAYERS=opengeo:geonames,opengeo:geonames&
STYLES=point,heatmap&SERVICE=WMS&VERSION=1.1.1&
REQUEST=GetMap&SRS=EPSG:900913&
VIEWPARAMS=word:canyon&
BBOX=-16077730,2576500,-6186167,7155384&
WIDTH=2022&HEIGHT=936

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!

Security

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:

SELECT * FROM roads
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!

Caveats

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

suite-enterprise

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 (http://postgis.net/).
  • GeoServer – GeoServer is an open source server for sharing geospatial data (http://geoserver.org/).
  • GeoWebCache – a Java web application used to cache map tiles coming from a variety of sources such as OGC Web Map Service (http://geowebcache.org/).
  • QGIS – a free and open source desktop Geographic Information System (http://www2.qgis.org/en/site/)
  • OpenLayers – A high-performance, feature-packed library for all your web mapping needs (http://openlayers.org/)

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.

components

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.

suite

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.

components-vs-suite

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.

Summary

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: http://boundlessgeo.com/solutions/opengeo-suite.

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!

OGR FDW FTW!

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.

CREATE EXTENSION postgis;
CREATE EXTENSION ogr_fdw;

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:

CREATE SERVER opengeo
  FOREIGN DATA WRAPPER ogr_fdw
  OPTIONS (
    datasource 'WFS:http://demo.opengeo.org/geoserver/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.

CREATE FOREIGN TABLE topp_states (
  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!

OL3-Cesium brings 3D to OpenGeo Suite web apps

OpenLayersWith the news the Google Earth API has been deprecated, what is the best way to add a 3D globe to your mapping application? Thanks to advances in browser technology such as WebGL, which allows web applications to use the device’s graphics processor (GPU) for hardware accelerated rendering, OpenLayers 3 and Cesium can dynamically visualize data on 2D maps and 3D globes without the need for any plugins.

Wouldn’t it be nice to be able to just switch to a 3D globe view from an OpenLayers 3 map, much like how GeoExplorer can switch between OpenLayers 2 and Google Earth? Alongside Klokan Technologies and camptocamp, we helped create OL3-Cesium and recently included it in OpenGeo Suite 4.5 to achieve just this.

Visualizing GPS tracks in OL3-Cesium

In this post, I will show how to add a 3D globe view to a mapping application using the Boundless SDK and OL3-Cesium. As an example, I created an app that allows me to drag and drop GPS tracks on a map, then switch to 3D and explore. I enjoy mountain biking in my free time, because it challenges completely different regions of the brain than writing software, and in August I succeeded in riding my steepest descent so far, the famous nose trail north of Vienna.  See how this looks with the GPS track of my nose trail adventure:

GPS Track Viewer in Action from Andreas Hocevar on Vimeo.

As you can see, OpenLayers reads 3D coordinates from the GPX file I dragged on the map, but the third dimension is only visible as I switch to the globe view and tilt the map. Obviously the elevation reported by my GPS does not match the elevation model that I use for the globe view, so my track is quite a bit above the surface. Anyway, you get the picture.

Now let’s take a look at what I did so that my app can provide a globe view. Initially, I created my application with

$ suite-sdk create ol3-cesium-demo ol3view

I made a few tweaks to the layout, removed the States layer and the layer control, and I added a ol.interaction.DragAndDrop. For the globe view itself, the first thing to do is to create an olcs.OLCesium instance, connect it with the map and add an elevation model (known as terrain in Cesium). I did this in src/app.js, right after the code that creates the ol.Map instance:

var ol3d = new olcs.OLCesium(map); // map is the ol.Map instance
var scene = ol3d.getCesiumScene();
var terrainProvider = new Cesium.CesiumTerrainProvider({
  url: '//cesiumjs.org/stk-terrain/tilesets/world/tiles'
});
scene.terrainProvider = terrainProvider;

To add a “Toggle globe view” menu item, I added a list item to the dropdown-menu list:

<li><a href="#" data-toggle="collapse" data-target=".navbar-collapse.in" id="toggle-globe"><i class="fa fa-globe"></i>&nbsp;&nbsp;Toggle globe view</a></li>

Finally, at the bottom of my src/app.js file, I added a handler for the “Toggle globe view” menu item:

$('#toggle-globe').click(function() {
  ol3d.setEnabled(!ol3d.getEnabled());
});

That’s it!

Drag in your GPS tracks!

You can try the demo live at http://ahocevar.github.io/ol3-cesium-demo/ and view the source code or fork it on GitHub.

New in OpenGeo Suite 4.5: Style maps more easily with YSLD

Some years ago, I gave a talk at FOSS4G entitled “Styled Layer Descriptor, or How I Learned To Stop Worrying and Love XML.” Designed to appease the skeptical audience, I described some of the more nifty features of the SLD syntax that GeoServer uses to style its maps and layers. You could have been excused for not sharing in my enthusiasm and Dr. Strangelove fans may notice that I was equating XML with a nuclear bomb, so the point was never lost on me either.

For example:

<Rule>
  <PointSymbolizer>
    <Graphic>
      <Mark>
        <WellKnownName>circle</WellKnownName>
        <Fill>
          <CssParameter name="fill">#ff0000</CssParameter>
        </Fill>
        <Stroke>
          <CssParameter name="stroke">#000000</CssParameter>
          <CssParameter name="stroke-width">2</CssParameter>
        </Stroke>
      </Mark>
      <Size>8</Size>
    </Graphic>
  </PointSymbolizer>
</Rule>

That’s a lot of markup just to create red points with a black outline. Can’t we do better? Indeed we can.

Maps are not web pages, alas

There have been a few efforts over the years to make improvements to how users style layers in GeoServer. One such notable attempt was to adapt the usage of CSS in web page design to the task of map making. At first blush, this seems like a perfect fit: web-based maps can use web-based design! And in truth, the CSS styling extension for GeoServer is a powerful tool for converting CSS-like markup to SLD.

There are issues, though. CSS uses a fundamentally different painting model from SLD, so it is not possible to convert freely back and forth between CSS and SLD. Generated SLDs typically have many more rules than the CSS rules, so a reverse converter would need to identify the redundancies and eliminate them. Because the underlying rendering engine was built on the SLD model, this was problematic, and rewriting the engine wasn’t feasible.

So then the question became: is there a way to simplify the syntax, while still remaining true to the underlying rendering model?

Y not?

Frustrated from working with SLD, one of my former colleagues came up with an idea: why not adapt an existing markup language? He was familiar with YAML, which we had used internally in our work with map printing. It was pleasantly terse and seemed suited to the task. This idea percolated for a while, and months later, has emerged as a central component of OpenGeo Suite Composer: YSLD.

Remember that SLD example above? Here it is as YSLD:

point:
  size: 8
  symbols:
  - mark:
  	shape: circle
  	fill-color: '#FF0000'
  	stroke-color: '#000000'
  	stroke-width: 2

Much better isn’t it? Easier to read and more compact — and with many fewer brackets, that’s for sure.

There are other advantages to YSLD as well. Unlike XML, YSLD is schema-less, so ordering of components is not important. And for the first time, you can now define markup that is repeated throughout the document with a variable, so you can define it once and reuse it all over.

And, since YSLD uses the same underlying model as SLD, you can translate back and forth as you wish, making it completely interchangeable and compliant with OGC standards.

Get started with YSLD!

YSLD and OpenGeo Suite Composer are available exclusively to our enterprise customers. If you needed another reason to get OpenGeo Suite Enterprise, aside from proven on-demand support and maintenance, assistance with upgrades, and advice direct from the software developers, how about we add one more: a better way to style maps.

YSLD example

Have you checked out YSLD and Composer yet? Contact us to learn more or evaluate the tools.

New in OpenGeo Suite 4.5: Build maps with Composer

With the release of OpenGeo Suite 4.5, we’re proud to introduce OpenGeo Suite Composer, a tool for creating, styling, and publishing maps that is currently available exclusively to our enterprise customers. By focusing on the user experience, Composer makes authoring and publishing maps to GeoServer vastly easier than ever before with a simpler styling syntax, real-time feedback, and convenience features such as code-completion and sample code. Getting started is quick and straightforward.

Map styling is easy with YSLD

YSLD example

A typical workflow in OpenGeo Suite Composer starts with creating a new map, adding layers to it, tweaking the sample code provided for the layers, and saving the map. The new YSLD styling syntax is shorter and easier to write and, while still remaining compliant with OGC standards, represents a significant departure from the SLD syntax that was the main method for styling data layers in OpenGeo Suite. Thanks to its terse notation, a YSLD code block for styling a data layer might be 12 lines whereas its exact SLD counterpart could easily be 40 or more lines.

See the map as you edit

This new syntax combined with the ability to view changes in real-time enables cartographers to improve the quality of their maps, thus speeding up the styling process. Taking a look at the Composer interface, shown in the video above, we can see that the map takes up a large portion of the interface and is zoomable (a), that the data layer list is accessible via a re-sizable column in the center (b), and that the code for the selected layer is editable on the right-hand side (c).

intro1.png

Productivity boosters

To further enhance productivity, we’ve introduced a number of convenience features. For example, the ability to set zoom levels in the code for styles that change by zoom. In the above example, for the layer “natural,” zooms 7 and higher will display with the fill color, stroke color (i.e., outline color), and stroke width specified. Other zoom levels will not display that data layer. Previously, it was necessary to provide minimum and maximum zoom levels by source-scale denominator, and while that is still an option in YSLD, it can be difficult and verbose. Other features include:

  • Colors can be chosen via a color wheel interface or specified by color name (e.g., “green,” “blue”)
  • Any number of rules can be provided for a data layer
  • The order in which the code specifies things like filters and symbolizers is flexible
  • Code autocomplete is provided via keyboard shortcuts
  • See attributes for each data layer so they can be used in styling rules (e.g., features of type=park are green while type=hospital are pink)
  • Pan and zoom the map to determine which data layers should appear at which zoom levels

Less hassle means more designing

OpenGeo Suite Composer is not just an improved alternative to SLD, it is a significant interface overhaul that enables cartographers to make maps in a way that provides instant visual feedback and a much gentler learning curve. With Composer, a cartographer’s emphasis is primarily oriented toward the design of sophisticated cartographic compositions—a welcome sight.

A Composer-built map example

This example map, best viewed at zooms 4-10, was designed in OpenGeo Suite Composer, employing many Natural Earth datasets as well as a high-resolution land boundary built from OpenStreetMap polygons. Additionally, a high-resolution OpenStreetMap natural area dataset is visible in Canada at the higher zoom levels.

Try OpenGeo Suite Composer!

OpenGeo Suite Composer is available exclusively to our enterprise customers. Contact us to learn more or evaluate the tool.