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.

OpenGeo Suite 4.5 Released!

Boundless is proud to announce the release of OpenGeo Suite 4.5! Each new version of OpenGeo Suite includes numerous fixes and component upgrades as well as bringing many new features and improvements to the platform, including:

composer1.png

Try it!

Download OpenGeo Suite 4.5 and try our census map tutorial or heat map tutorial to learn more. Details about this release are included in the release notes and, as always, we strongly advise you to read the updating instructions and backup your data before installing.

Want to try out new features like Composer? Interested in support and maintenance from the experts at Boundless? Contact us to learn more about our OpenGeo Suite Enterprise offerings!

Use promotional code suite45 for a discount of 45% on training for the next week.

Happy PostGIS Day!

PostGISYesterday was GIS Day, which means that today is PostGIS Day — get it? Post-GIS Day! To celebrate, we’re giving a 50% discount on online PostGIS training through the end of the week! Visit our training catalog and use promo code “postgis2014″ to take advantage of this offer.

A lot has happened since last year, when I joined Stephen Mather, Josh Berkus, and Bborie Park in a PostGIS all-star hangout with James Fee.

In case you missed them, here are some features from our blog and elsewhere that highlight what’s possible with PostGIS:

An, as always, be sure to check out our workshops for a slew of PostGIS-related courses, including Introduction to PostGIS and our Spatial Database Tips & Tricks.

Interested in learning about or deploying PostGIS? Boundless provides support, training, and maintenance for installations of PostGIS. Contact us to learn more.

Partner Profiles: Gaia3D

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

Gaia3DLong-time Boundless partner Gaia3D is a software development and system integration firm focused on solving spatial IT challenges for government and research institute clients across South Korea. Since Gaia3D founder Sanghee Shin was first exposed to open source geospatial solutions many years ago at a FOSS4G conference, he and the team at Gaia3D have been vocal advocates for open source. The company initially reached out to Boundless (then OpenGeo) for guidance as they worked to introduce open source geospatial to the burgeoning South Korean market. The enterprise OpenGeo Suite packaging and support enabled Gaia3D to foster adoption of these powerful new tools.

“OpenGeo Suite is equipped with everything we need,” said Gaia3D Director of Marketing Heegu Park.

Gaia3D’s recent development efforts include projects for the Korea Aerospace Research Institute, Korea Meteorological Administration and the Korean Ministry of Land, Infrastructure and Transportation. Their partnership with Boundless has provided essential tools and resources for giving their clients the best possible service. For the Ministry of Land, Infrastructure and Transportation, Gaia3D deployed OpenGeo Suite Enterprise to develop a mobile traffic information system, responsible for tracking traffic throughout the country during specific peak traffic times. As proof of the the outstanding performance OpenGeo Suite Enterprise delivers, this system is designed to handle over 100,000 concurrent connections at peak time and is capable of serving up to 1 million tiles per hour from a single cache server. The system generates 14 leveled image tiles after processing all traffic information from up to 240 thousands road links per minute.

As part of their strong commitment to open source, the company has been instrumental in translating open source GIS software and manuals to Korean, and they also recently played a pivotal role in winning the bid to host the 2015 FOSS4G Conference. So they hope to see us all in Seoul next year!

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