Support Stories: Secure GeoServer connections to Postgres for Heroku

OpenGeo SuiteOne of our recent OpenGeo Suite support requests came from a customer exploring the use of Heroku, a cloud-based platform for database storage. Because Heroku sensibly requires that all connections use a secure SSL connection, their question involved making such a connection using GeoServer.

Some Background

While OpenGeo Suite installs GeoServer and Postgres on the same server by default, many production deployments require GeoServer and Postgres services to be split between two (or more) machines. When these computers are all on the same local area network, this usually doesn’t introduce any additional security considerations. However, when these computers need to communicate across the internet or any other unsecure network, then it is important to force the database traffic over an SSL connection.

JNDI

While GeoServer doesn’t offer an SSL connection to regular database stores, we can use a JNDI connection instead. JNDI, short for Java Naming and Directory Interface, is typically used to improve performance by providing connection pooling to databases, and it also serves our purpose by enabling secure connections.

Our Solution

To demonstrate how to secure data and improve integration with OpenGeo Suite, we will create a new JNDI resource — which we’ll arbitrarily call jdbc/heroku — that can be used in GeoServer.

Identify the Connection Parameters

The first step is to collect the connection parameters for our database. If you are using Heroku, these are on your database settings page:

Heroku Connection Settings

Update the Tomcat Context

Once we have this information, we can open /etc/tomcat6/context.xml for editing. Add the following block of code before the </Context> tag, replacing HOST, DATABASE, PORT, USER and PASSWORD based on the information from above:

<Resource
  name="jdbc/heroku"
  auth="Container"
  type="javax.sql.DataSource"
  driverClassName="org.postgresql.Driver" 
  url="jdbc:postgresql://HOST:PORT/DATABASE?ssl=true&amp;sslfactory=org.postgresql.ssl.NonValidatingFactory"
  username="USER"
  password="PASSWORD"
  maxActive="20"
  maxIdle="10" maxWait="-1"
/>

Note that, with the sslfactory=org.postgresql.ssl.NonValidatingFactory setting, the identity of the server will not be confirmed, which could compromise your security; if the host’s certificate is certified by a trusted authority or you have imported the certificate into Java’s keystore, then you should remove that connection parameter.

Update the GeoServer Configuration

The next step is to edit web.xml in /usr/share/opengeo/geoserver/WEB-INF and add the following just before the </web-app> line at the bottom of the file.

  <resource-ref>
    <description>Postgres Datasource</description>
    <res-ref-name>jdbc/heroku</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>

This gives GeoServer access to the JNDI resource. We can now restart the Tomcat application server.

Create the Secure Connection

Finally, add a new PostGIS JNDI store and set the jndiReferenceName to java:comp/env/jdbc/heroku (all other options are the same as a regular PostGIS store). Click Save and your secure connection is ready to use!

Learn more

More information on JNDI connections with Tomcat is available in the GeoServer documentation.

Benjamin Trigona-Harany leads our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

Creating a custom build of OpenLayers 3

OpenLayers

The OpenLayers 3 Beta 2 release provides a lot of integrated functionality out of the box. Since the library likely includes more than needed for any single application, it is important to know how to generate custom builds with just the relevant code. We’re currently working on making this process a whole lot simpler and easier, including developing a web-based build tool. In the meantime, this post describes how to generate a custom build.

No Irrelevant Code

OpenLayers 3 uses the Google Closure Compiler (in advanced mode) to create a custom build containing only the parts of the library needed for an application. To produce a minified version containing only the required parts of the API, the compiler removes all the irrelevant code. OpenLayers 3 currently uses Plovr to drive the Closure Compiler, though we anticipate this will change as the build process improves.

This post assumes that OpenLayers 3 is configured locally with a working build environment; if not, please check out the Developer Guide to setup a development environment. With that in mind, generating a custom build requires the creation of two files:

  1. a build configuration file (called my-config.json below)
  2. an exports file file (called my-exports.js below)

Build Configuration File

The build configuration file sets some build flags and instructs Plovr which other files to use (see the Plovr documentation for more detail). In the buildcfg directory, create your my-config.json build configuration file. Use the content below as a starting point.

{
  "define": {
    "ol.ENABLE_DOM": false,
    "ol.ENABLE_WEBGL": false,
    "ol.ENABLE_PROJ4JS" : false,
    "ol.ENABLE_VECTOR": false,
    "goog.dom.ASSUME_STANDARDS_MODE": true,
    "goog.DEBUG": false
  },
  "inherits": "base.json",
  "inputs": ["my-exports.js"],
  "externs": [
    "//json.js",
    "../build/src/external/externs/types.js",
    "../externs/bingmaps.js",
    "../externs/geojson.js",
    "../externs/topojson.js",
    "../externs/oli.js",
    "../externs/proj4js.js",
    "../externs/tilejson.js",
    "../externs/closure-compiler.js"
  ],
  "paths": [
    "../src"
  ]
}

The define section of the build configuration file disables the DOM and the WebGL renderers,  specifying that we only need the Canvas renderer. In addition, support for vector data and Proj4JS is disabled, resulting in a smaller build size.

Exports File

The next file you need to create will contain export statements that essentially tell the compiler what methods and properties you’ll be using in your application. Create a file named my-exports.js in the buildcfg directory. You can start by adding the content in this complete exports file from GeoServer’s preview page.

Assuming you are using a MousePosition control in our application, a subset of your exports file would look like this:

goog.require('ol.control.MousePosition');
goog.exportSymbol(
  'ol.control.MousePosition',
  ol.control.MousePosition
);

Compiling

To build the compiled version of the library tailored to your application, run the following

./build.py build/src/external/externs/types.js
java -jar build/plovr-81ed862.jar build buildcfg/my-config.json > ol.min.js

The end result will be saved in ol.min.js. Given the exports for the GeoServer preview page, the resulting file is about 37 kB after GZIP compression.

Interested in using OpenLayers in your enterprise? Boundless provides support, training, and maintenance. Contact us to learn more.

GeoNYC: Student Showcase

This month, GeoNYC brought together graduate and undergraduate students from around the city to talk about their mapping projects. It was an exciting opportunity to see and hear from the next wave of talented thinkers from the New School, CUNY, Columbia, and Pratt.

If you could’t make it to the event and want to check out what you’ve missed visit the treasure trove of past presentations.  Use the hashtag #geonyc on Twitter to keep up to date on all GeoNYC news. Many thanks to Boundless, CartoDB, and Esri for supporting the event!

The students who presented at this month’s meetup were:

Toby Salinger presented his work to map the community building impact of former NYC Councilman Vito Lopez in his Brooklyn and Queens district.

Caroline Massa created a Shareabouts website entitled Natural Resource Recovery Status. The site collects user contributed information related to Hurricane Sandy impact and recovery efforts.

Victoria Vele looked into how different pedestrian areas were effected by air pollution while she was a student intern at the Health Department.

Laura GuzmanJesse Mae MettsCaitlin Charlet used maps as part of an interactive tool that allows users to visually investigate complex government information.

Troy Andrew Hallisey and his team worked to visualize the ever-shifting housing strain that results from speculation and redevelopment in the city’s neighborhoods.

Ross Condon worked on a project that tries to locate possible locations of residential buildings which could benefit from solar remodeling projects using tax lot information from the Pluto data set, building footprint outlines, the Brooklyn tree census, and  street network.

Dare Brawley presented his project, Pieces of the Housing Puzzle: Making Tangible the Intangible, that examines the housing landscape of New York City.

Chris Henrick discussed the evolution of cartography and in particular how the problems of bias and intentionality are relevant to maps in the digital era.

Join us on March 10th as we welcome some geospatial heavyweights — Paul Ramsey of Boundless and David Blackman of Foursquare!

Using OpenLayers 3 with Ember.js

OpenLayersLast week we announced the release of OpenLayers 3 Beta 2, so this week I wanted to share some recent experiments combining OpenLayers 3 and Ember.js to create a LayerSwitcher that supports grouping and overlays as well as base layers.

This was my first attempt to use Ember.js, an open-source client-side JavaScript web application framework based on the model-view-controller (MVC) software architecture pattern. It uses the Handlebars library for its templates.

Some of my takeaways from this exercise were:

  • Ember seems powerful, and easy to learn. However, it’s sometimes hard to scrape together all the resources needed to learn and extend the framework.
  • Components are pretty new to Ember and I couldn’t figure out how to properly define a component in a different namespace and use it in the application template (this is why I needed to use a workaround).
  • OpenLayers 3 also has observable properties, which makes it easier to integrate the two.

Using Ember

I initially created the application using the Ember starter kit. In the HTML page, I created a template for the layer switcher component. Components in Ember have an id that starts with components followed by a hyphenated component name:

<script type="text/x-handlebars" id="components/layer-switcher">
    <ul><h4>{{group}}</h4>
    {{#each item in model}}
      <li>
        {{#if item.exclusive}}
        <label>{{view Ember.RadioButton name=group
            selectionBinding="selected" valueBinding="item.title"
            checkedBinding="item.visible"}} {{item.title}}</label>
        {{else}}
        {{view Ember.Checkbox checkedBinding="item.visible"}} {{item.title}}
        <button class="btn btn-default btn-xs" 
          {{action "removeSelected" item}}>
          <span class="glyphicon glyphicon-trash"></span>
        </button>
        {{/if}}
      </li>
    {{/each}}
    </ul>
</script>

Close-up of layer switcher component
As shown in the image at right, this template shows a radio button if the layer’s group is exclusive, otherwise it shows a checkbox and a remove button. If the selected radio button is changed, the value of the selected property is changed to the title of the selected item. If an item is visible in the exclusive group, it will initially be checked. In the index template, this component is then used per group.

Grouping layers

I used the Ember.GroupableMixin extension to group the layers array based on an object property. All of the OpenLayers.Layer objects were created with a group property that groups them together in the layer switcher. The groupable mixin is then used in an Ember.ArrayController where also the name of the property to use for grouping is specified.

The model for the application uses a utility function defined in a separate namespace (Boundless). This function simply turns the OpenLayers.Layer objects into corresponding Ember objects. The definition of those Ember objects can be found in the Boundless.MapLayer object.

Two-way binding

This is a two-way binding, so if the visibility of the layer is changed by OpenLayers then the Ember object will be updated automatically:

layer.on('change:visible', function(evt) {
    this.set('visible', evt.target.get('visible'));
}, this);

Where this is the Ember MapLayer object.

If the visible property is changed by Ember, the OpenLayers state will be changed as well:

this.addObserver('visible', layer, function(evt) {
    this.set('visible', evt.get('visible'));
});

Where this is the OpenLayers.Layer object. As you can see, having the mechanism of observable properties on both sides of the equation is extremely powerful.

Exclusive layers and the remove button

The LayerSwitcher component code handles the selection of the radio group for exclusive layers. Please note that exclusive is not a property of a layer defined by OpenLayers, but defined by this application. However, the OpenLayers.Layer object can take additional observable properties, which is convenient here. The same applies to group. Also, if somebody removes an item from the layers collection in OpenLayers, our Ember view needs to be updated, this is handled by the component code as well.

this.map.getLayers().on('remove', function(evt) {
  var el = evt.getElement();
  this.model.removeObject(this.model.findBy('title', el.get('title')));
}, this);

Lastly, to remove an overlay layer from the map, the component defines an action that is tied to a button. In this case the object needs to be removed from the OpenLayers.Map as well.

Results!

A live version of this application can be found here.

Screen shot of the layer switcher application

Interested in using OpenLayers in your enterprise? Boundless provides support, training, and maintenance. Contact us to learn more.

OpenLayers 3 Is Coming

OpenLayers

Beta 2 Is Here

OpenLayers 3 has been a long time in the making. With the library stabilizing and becoming more feature complete, we’re excited that our efforts are finally coming to fruition. Today we’re cutting a Beta 2 release as another milestone toward the 3.0 final. There are a ton of new features to check out in the release. Here are a couple that I think are particularly cool.

Vector Rendering

vector rendering

The vector layer example above shows a rotated map centered on Italy. Drawing vector and raster data in OpenLayers 3 is handled by one of several renderers. For example, rendering might be done in WebGL, with the Canvas 2d context, or using traditional DOM element composition depending on device capabilities. This vector layer is using the Canvas renderer. When the map is panned, zoomed, or rotated, instead of simply applying a transform to the Canvas element, the map is re-rendered with each transition, so things like label rotation, icon rotation, and stroke width can remain fixed during the transitions. Batches of drawing instructions are cached and replayed during transitions to achieve higher performance while rendering.

Using Canvas and WebGL instead of SVG makes it possible to render and interact with very large numbers of vector features without the extra overhead of creating a DOM element for each feature.

Image Manipulation

layer spy

Rendering with Canvas allows you to leverage other basic image manipulation techniques. The layer spy example demonstrates creating a “spyglass” to view imagery from one layer superimposed on another while moving your pointer around the map.

This example takes advantage of “precompose” and “postcompose” rendering events. Listeners for these events get access to the Canvas rendering context and perform any manipulation that the Canvas API allows. The layer swipe example is another using this technique to provide a basic swipe control for viewing changes in vector or raster data. Stay tuned for a very cool heatmap layer that builds on the same rendering event technique.

The Road to 3.0 Final

There are a few areas of the OpenLayers 3 API that we’re still working to stabilize. Beyond that we have documentation work to do to let everyone know how to use all these great features. Notably we need to make it easy to generate small builds of the library. With Closure Compiler in advanced mode, very compact profiles of the library can be built with just the functionality you need. We’re currently working on easing the build configuration and putting together a hosted build tool. More details on this coming soon.

We’re planning on one more beta release with new features that are nearing completion. After stabilizing the remaining bits of the API we’ll get into a release candidate cycle. In the meantime, try out the Beta 2 release and let us know what you think!

OpenGeo Suite: How It’s Made


Michael Weisman

For the OpenGeo Suite 4.0 release, we revisited how our installers are built and used. Part of that effort meant improving how you can develop on OS X and deploy on Windows, but we also put a lot of effort into improving our build process based on what we’ve learned over the past four years. It’s no small feat to assemble and support a complete geospatial platform so, if you’re curious about how it’s made, here is a presentation that explains how we build OpenGeo Suite for various operating systems.

Support Stories: Labelling a MultiPoint geometry with WPS

MassGISMassGIS, the Commonwealth’s Office of Geographic and Environmental Information, is the official Massachusetts state agency assigned to the collection, storage and dissemination of geographic data. Since 2006, MassGIS has effectively provided much of its geospatial data via OGC standards using GeoServer with support from Boundless.  They are one of our oldest clients, so we figured this issue would be a great way to launch a new recurring feature on our blog that highlights real questions, their solutions, and the value of our support.

The Issue

Not long ago, they asked an interesting question about how to properly label features, specifically multipoint geometries. Our solution involved using Web Processing Service to find and label the centroids using rendering transformations in SLD.

Some Background

Features in GeoServer will often be a single point, linestring, or polygon but they can also be a more complex multipoint, multistring, or multipolygon. Representing a country or another administrative area as a polygon may make sense if it is one contiguous landmass, but most countries are not: they have islands, are split by bodies of water, or might even have an exclave. Thus, it is common to use a single multipolygon geometry to represent all the parts that make up a single administrative area.

Labelling multipolygons

GeoServer employs an algorithm to determine where to place a label on the multipolygon: it will place the label at the centre of the largest polygon in the visible area. You can see this algorithm in action on a default installation of OpenGeo Suite.

Multipolygon

Depending on which of Indonesia’s many islands are visible, the label will “jump” around as we zoom and pan so that it remains on the largest visible landmass.

 Multipolygon

Labelling multipoints

It is relatively easy to find the most “important” polygon, since polygons have areas that we can compare. Points, however, prove more challenging as GeoServer has no metric to determine which is the “largest”. Therefore, when we assign a label to a multipoint, GeoServer will simply attach the label to the first visible point in the set.

alpha = MULTIPOINT(0 10,10 10,10 0,0 0)

beta  = MULTIPOINT(25 10,30 0,20 0)

If we have the two multipoints above, GeoServer will label them as follows:

 Multipoint

You can download multipoint.zip to try the same layer on GeoServer.

Our Solution

This default label placement may be desirable in certain circumstances, but MassGIS was interested in a solution for placing the label in a more natural position: the geographic centre of all the points in each feature.

Finding the centroid with Web Processing Service

We have previously explored using WPS, but it’s always interesting to find new applications for server-side processing. OpenGeo Suite ships with a WPS extension for GeoServer that comes with gs:Centroid, a handy process that will calculate the centroid of a geometry. Using the WPS request builder in GeoServer, we can quickly check that it works:

WPS request builder

When executing this process, we should get back the following GeoJSON, which shows the two centroids with the same attributes as the multipoints they were derived from:

{
   "type":"FeatureCollection",
   "features":[
      {
         "type":"Feature",
         "geometry":{
            "type":"Point",
            "coordinates":[
               5,
               5
            ]
         },
         "properties":{
            "name":"alpha"
         },
         "id":"multipoint.1"
      },
      {
         "type":"Feature",
         "geometry":{
            "type":"Point",
            "coordinates":[
               25,
               3.3333
            ]
         },
         "properties":{
            "name":"beta"
         },
         "id":"multipoint.2"
      }
   ]
}

We now know we can easily get the centroid for our two features using WPS, but what is great to remember is that we can call these processes from an SLD. We’ll use this trick to style our multipoint features with a label at the positions calculated above.

Using Rendering Transforms

To call gs:Centroid from our SLD, we simply need to add the following XML block:

<Transformation>
  <ogc:Function name="gs:Centroid">
    <ogc:Function name="parameter">
      <ogc:Literal>features</ogc:Literal>
    </ogc:Function>
  </ogc:Function>
</Transformation>

This will call gs:Centroid with the input parameter named features (we can see the name of the parameter using the WPS request builder). The transformed features, which will each be a single point, can now be styled with a label as normal.

This is almost enough, but we want both the original multipoint feature as well as the transformed centroid to be drawn. We can accomplish this by providing two <FeatureTypeStyle> blocks in our SLD.

The final product is this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<StyledLayerDescriptor version="1.0.0" 
xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd" 
xmlns="http://www.opengis.net/sld" 
xmlns:ogc="http://www.opengis.net/ogc" 
xmlns:xlink="http://www.w3.org/1999/xlink" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <NamedLayer>
    <Name>multipoint</Name>
    <UserStyle>
      <Title>Multipoint with labelled centroid</Title>
      <FeatureTypeStyle>
        <Rule>
          <Name>rule1</Name>
          <Title>Red Square</Title>
          <Abstract>A 6 pixel red square</Abstract>
          <PointSymbolizer>
            <Graphic>
              <Mark>
                <WellKnownName>square</WellKnownName>
                <Fill>
                  <CssParameter name="fill">#FF0000</CssParameter>
                </Fill>
              </Mark>
              <Size>6</Size>
            </Graphic>
          </PointSymbolizer>
        </Rule>
      </FeatureTypeStyle>              
      <FeatureTypeStyle>
        <Transformation>
          <ogc:Function name="gs:Centroid">
            <ogc:Function name="parameter">
              <ogc:Literal>features</ogc:Literal>
            </ogc:Function>
          </ogc:Function>
        </Transformation>
        <Rule>
          <Name>rule2</Name>
          <Title>Label</Title>
          <Label>
            <ogc:PropertyName>name</ogc:PropertyName>
          </Label>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Multipoint

This is just one example of using a WPS in an SLD. OpenGeo Suite ships with a large number of similar processes which could be used to style our output. In an upcoming post from the support team, we will look at an even more powerful way of controlling the rendering process using GeoScript.

Benjamin Trigona-Harany leads our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

 

Boundless Connections: Welcome Leandro Collares!

Leandro Collares de Oliveira!In addition to Soumya Sengupta, last week we also had the pleasure of welcoming Leandro Collares as our Open Source Development Intern. Leandro will be working on our Support team to develop a better understanding of our stack of open source geospatial software. In the process, he’ll increase our capacity to support, document, and test our products.

Welcome Leandro! We are excited to have you join the team.  What will you be working on here at Boundless?

I was hired primarily to work with the Support team to solve client’s issues quickly and to contribute to our documentation. As an intern, I will have the chance to improve my knowledge about OpenGeo Suite, Mapmeter, and GIS in general.

What’s your background?

I received my Bachelor’s of Science in electrical engineering from the Universidade Federal de Minas Gerais in Brazil and worked as a telecommunications engineer for several years. I then attended the University of Victoria, where I received my Master’s in Computer Science.

Have you done much open source development?

I have been a Linux user for a long time and used several open source tools during my academic life. My Master’s thesis project utilized an open source framework called Marsyas.  I’m also a huge fan of LaTeX! I’m excited that I now have the opportunity to contribute back to the open source community by joining Boundless as an intern.

What’s your experience with OpenGeo Suite or the components of it?

I am still scratching the surface of OpenGeo Suite. Mapmeter was the first thing I noticed about Boundless. I really liked the way it displays information as I am definitely drawn to informative and aesthetically appealing interfaces. I have lots to learn about all aspects of OpenGeo Suite!

Your last job was at Insatiable Genius, whose main product is Comic Tycoon. What were you doing there?

My job was to make sure Comic Tycoon was bug-free and aesthetically coherent. I would play the role of a user who tries to break the app and check the interface for inconsistencies. I would describe the steps necessary to break it and send those to the developers. After the bugs were supposedly fixed, I would try to break the app again! In the end, it was gratifying to see that my work helped to make the app more robust and beautiful.

What project have you worked on that you are most proud of?

I would say SoundAnchoring, a visual map of a user’s music collection. Instead of displaying the music collection as a sortable list, it creates visual groupings of songs containing acoustically similar tracks.

I also worked as an English-as-a-Second-Language teacher for underprivileged teens in Brazil as a volunteer. Some of them were able to get jobs after the classes.  I am glad I could contribute to their lives.

SoundAnchoring features a UI without text, relying instead on images to convey information. You seem to have a strong handle on creating interfaces that can be quite effective without using text.

Thanks! I’m really interested in the relationship between people and technology and finding novel ways to visualize information. Interfaces that aid in non-verbal communication also appeal to me. Recently, I’ve been working as a volunteer on a project for children on the autism spectrum to overcome difficulties they may have memorizing faces and recognizing emotions.

Tell us more about this app for people on the autism spectrum.

The idea is that the games can help children build robust representations of a person or an emotion. The app takes pictures or records videos of family and friends. Children can assign labels to pictures and videos, which then builds material for memory games. For example, we could take pictures of your face in different angles and assign the label “Anthony.” The game would show your pictures to the player, who has to guess the right label. Information on the player’s accuracy and response time is collected. The development team is in the process of polishing the games and will try them with children on the spectrum to see if they are actually effective. Hopefully we will have good results and then might consider launching it in an app store.

It seems that you have a really strong education streak.

At the beginning of my career I was really close to the core of systems as a telecommunications engineer. Since then, my attention has shifted to the interaction between people and technology. I really like being in touch with people, either as an apprentice or as an advanced learner able to share knowledge with others. Languages are an abiding passion of mine: I’m fluent in Portuguese and English, have advanced communication skills in German, basic skills in Japanese and French, and I also understand Italian and Spanish.

We usually end interviews by asking for a fun fact, but you’ve given plenty already. What’s a good thing for the world to know about you?

I tend to pick up languages quite easily and I am quite successful at mimicking native speakers’ accents when greeting people. Also, I don’t usually forget faces or names — I am really good at associating people’s names and faces — that has made some people uncomfortable at times. (laughs) I think it’s partly that my face is too common and they don’t recognize me when I address them by using their name!

Leandro Collares joins our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

LIDAR Format Wars: Towards an Open Future

The only certainty in the world of technology is that things are going to change. Managing and adapting to change, rather than resisting it, is the best strategy. In two previous posts we looked at how the LIDAR industry faces a choice for advanced formats and reviewed how open formats can offer significant advantages over a proprietary vendor path.

LIDAR data of Haiti

We know that the world of LIDAR is going to change over the next few years, in some predictable ways:

  • ever-growing network bandwidth and client device capability will make streaming LIDAR visualization a commonplace application

  • more sophisticated sensors will gather more and different information (like waveform data) into pointclouds

  • data volumes under management will only grow as repeated surveys and higher resolution sensors come on stream

And those are just the predictable changes we can expect in the near future. In order to respond to those changes, we know that as an industry we will need:

  • standard protocols for streaming LIDAR and negotiating level-of-detail between clients and servers

  • standard interchange formats that include very high levels of compression

  • standard working formats that include random access and level of detail

Towards Better LIDAR Standards

Everyone can move ahead individually, and develop their own solutions, both open source and proprietary, but our industry is small enough that everyone going alone will result in slower overall progress than working together.

The Open Geospatial Consortium (OGC) has attempted to bring together users and vendors over the years, but with a few notable exceptions, their process has been sufficiently slow that it generally trails the leading edge of development, resulting in lifeless specifications. However, the OGC template still has merit: users, vendors, and open source communities all hold different and important parts of the solution and working together can lay out a roadmap that will help everyone.

Once a roadmap is understood, the basic principles of internet engineering can be applied: rough consensus and working code.

Coming soon…

Boundless is willing to be a convener, or to work with OGC as a convener, to bring together a summit of users, vendors and open source developers to hammer out an understanding of the best way to meet the future needs of the LIDAR community, without duplicating and wasting effort reinventing the same wheels individually. Look for a meeting announcement from us in the near future.

We have only so much time on this earth, let’s use ours doing interesting things that matter, not competing on building data plumbing.

OpenGeo Suite 4.0 supports many LIDAR formats, including LAS, LASzip, Oracle Pointcloud, PostgreSQL Pointcloud and more.

You’re invited to the LocationTech Birthday Blast!

LocationTechIt’s been one year since Boundless joined with the Eclipse Foundation, Oracle, IBM, and Actuate in founding the LocationTech initiative to raise the profile for location awareness in enterprise IT. Over the last year, LocationTech expanded from four members to a dozen, formally incubated four projects, and is evaluating ten more.

To celebrate this first anniversary, the initiative is throwing a party at the Boundless offices in Arlington on February 13th. It’ll be a great chance chance to mingle with entrepreneurs, software developers, geospatial professionals, LocationTech members, and the community.

We hope you’ll join us!

The party is open to all but registration is required.

Date & Time

February 13th at 6:30pm

Location

1400 Key Boulevard, Level A
(Entrance on North Oak Street)
Rosslyn, Arlington, VA 22209

Presentations

Along with opportunities to eat, drink, and mingle there will also be updates from:

  • Andrew Ross of LocationTech
  • Anthony Fox of CCRi about GeoMesa
  • Robert Cheetham of Azavea about GeoTrellis
  • Juan Marin of Boundless about GeoGit

Continue reading