Tag Archives: openlayers

OpenLayers Map Centering and the International Date Line

I recently came across another piece of OpenLayers to be aware of when working with maps that wrap the International Date Line. I store the map extent throughout a user’s session so they can leave the map page, come back, and still see the same set of results as when they left. Unfortunately, the map was sometimes taking a stored location in the North Pacific and displaying Northern Africa instead! Obviously not what I want it to do…

» Continue Reading

How to Write an OpenLayers Plugin

Several weeks ago I gave an internal presentation to Azavea developers on the fundamentals of writing OpenLayers plugins.  I have modified that presentation to serve as a quick-start guide to writing your own plugins.

Understand JavaScript

OpenLayers is a JavaScript library.  If you do not have a sound understanding of JavaScript, do not pass Go and do not collect $200.  Instead, pick up Doug Crockford’s JavaScript: The Good Parts or Stoyan Stefanov’s Object-Oriented JavaScript.  Come back here when you’re done.  We’ll wait.

Check Out the Source

The OpenLayers source code is hosted in Subversion.  Check out the source to your development directory from:

http://svn.openlayers.org/trunk/openlayers/

Get Familiar with the Source

The most important thing you can do is invest some time familiarizing yourself with the JavaScript source code including the code structure, object inheritance, and components similar to the one you want to write.

Code Structure

OpenLayers is written to be object-oriented.  As such, the code is (mostly) structured such that the base objects are located in the root directory and any children of that object are in a sub-folder of the base object’s name. You can browse the source here.

Object Inheritance

OpenLayers object inheritance could be an article in and of itself, so we’ll just stick to the highlights.

All inheritance is done via the OpenLayers.Class function and supports multiple inheritance by augmenting any number of existing object definitions with your own object literal definition.  In real life, it looks like this:

OpenLayers.MyNewObj = OpenLayers.Class(OpenLayers.MyBaseObj, {
    prop1: 1,
    prop2: 2,
    doThis: function() {
        /* doing this */
    }
});

Check out the source code of OpenLayers.Class to really understand how OpenLayers implements object inheritance.

Dig Into a Component Similar to the One You Want to Write

Odds are that you are not setting out to write a completely unique component, but rather wish to build a specific implemention of something that already exists.  Most of my plugins have been tile-based layer plugins that get content from HTTP requests.  By looking through the examples, we know that OpenLayers already supports this type of functionality in OpenLayers.Layer.WMS and others.

We can discover what functionality OpenLayers already supports by digging into the WMS source code. Start by looking at the object definition and find its base object.  For example, the WMS layer extends OpenLayers.Layer.Grid.  The source for the base object will tell you which properties and functions you will have access to by default and if there are any functions you are required to override.  But don’t stop there!  Keep investigating base objects of the base objects until you get all the way up the chain.  For WMS, you will find OpenLayers.Layer.Grid, OpenLayers.Layer.HTTPRequest, and OpenLayers.Layer.  Understanding these objects will be invaluable when debugging.

Once you have an understanding of the base objects, and assuming they have the functionality you need, take another look at the WMS layer object.  Look at each property and try to understand why the author added it.  Also look at the functions.  Is it a new function?  Why was it added?  Is it an override? How is it different than the base functionality and why?  Answering these questions will enable you to pinpoint the functionality you will need to implement for your plugin.

Code!

You now know the way of the OpenLayers plugin, grasshopper.  Go and code.  But don’t forget the code conventions!

Azavea R&D: sourcemap.org

Azavea is a rare company. One of the benefits that we (full-time employees) earn is the ability to define our own research project after 6 months. There is a list of active research projects here. My personal interests took me to working with C. Dana Tomlin, and implementing a radial propagation tool for ArcToolbox. In addition, I wanted to collaborate with the MIT Media Lab’s Tangible Media Group on the project http://www.sourcemap.org/.

I won’t get into what sourcemap is (that’s already been done), but I thought it would be cool to mention some of the technical challenges that the project was/is facing, and what we’re doing about it.

» Continue Reading

OpenLayers with ArcGIS or ArcIMS

OpenLayers, an open source web mapping library for browsers, is 99% web mapping goodness.  We took a look at the library, and found that we could almost use it in our projects to provide a robust mapping interface.  The extra 1% that we really needed was support for ArcIMS and ArcGIS Server.

So we fixed it.

Jeff added support for ArcGIS Server, and I added support for ArcIMS (in addition to a subset of ArcXML).  These are tickets in the OpenLayers tracking system, under the monickers #1749 and #213, respectively.  ArcGIS Server has made it into the trunk, and we are anxiously awaiting the incorporation of ArcIMS/ArcXML support.  It looks like they are both on track to make it into OpenLayers v2.8, so we are excited.

We’ve been running production applications with the patches we’ve provided to the OpenLayers community for months now, so it’ll be wonderful to make it ‘official’.