Tag Archives: arcgis

OpenLayers meet ArcGIS.com

“Hey guys, we can support ArcGIS online basemaps, right?”
“Oh yeah, definitely, we use OpenLayers, there must be a layer for that”

Azavea is no stranger to contributing to open source projects, so when we learned that OpenLayers was lacking full support for the newer ArcGIS basemaps, I knew I had a job to do. The community had been looking for this functionality for over 2 years, and still didn’t have a solution. You might say that developing tools for crime fighters would be exciting and rewarding, but it is also nice when something you wrote has the potential to be used everyday by a community you value.

We quickly discovered that a few partial solutions existed, but something was ever so slightly off, those layers weren’t performing in all the configurations we needed. We had a head scratching situation, we had tiles, we had a standard format, but it seemed like they wouldn’t let us get the calibration just right. Finally the eureka moment hit when we discovered that the server was not being entirely literal with it’s capabilities, and that they were actually subtly changing as the zoom level changed! Once we knew that, it was a simple matter of overriding some base code, recalibrating and extrapolating the extent, and we were set!

Fast forward to today, and we’ve peer-reviewed the layer internally, added documentation, multiple examples, and unit tests, and we submitted a patch to the community about a month ago. Although it isn’t officially in the trunk yet, we already have word from a new friend in Spain that the layer has helped him with a project!

I’m excited that this layer could help more developers and organizations take advantage of the great cartography offered by Esri while using the powerful OpenLayers platform. So please keep your fingers crossed while we go through the approval process once again, or checkout the patch and try it for yourself, and let us know what you think. It can support out of the box ArcGIS.com basemaps, local ArcGIS servers, and raw file caches produced by ArcGIS.

Thank you to those who helped (Jeff, Aaron, Zwarg, and Robert), and to those who helped online and in the community, Thanks! Also thanks to Esri, who just made their ArcGIS map tiles available for free to everyone!

Tricks & Woes w/ WMS GetFeatureInfo

Here’s a trick that could be useful if you’re writing a simple map application in JavaScript that interacts with a WMS map service that you control, and your application needs information about a feature that the user has clicked on.   Did you know that you can cajole your WMS server to directly produce JSON (which is a very convenient way to receive data in a JS application) with feature information as a response to a WMS request?  I found this trick useful in a recent application as a simple approach, if one doesn’t mind wrangling with server configuration.  Unfortunately, it involves using an under-specified part of the WMS standard, so this recipe is also a good illustration of where the OGC WMS standard could be improved.

In the WMS specification, OGC defined an “optional” GetFeatureInfo request that returns feature information based on a pixel from a map.  It’s both useful and limiting that the request is based on the pixel — it’s useful in that you can just pass along the pixel that the user clicked on, but you don’t have a lot of control (without other trickery I won’t go into here).  But here’s the catch: the output format isn’t defined in the standard.  But here the problem becomes the opportunity — most WMS servers allow you can define your own output format, which includes JSON.

But again the problem returns to the fact that there isn’t a standard in place here:  different mapservers handle the output format definition differently.  MapServer has a very straightforward method — it will respond to a “text/html” request with three templates you can define: you can define a header template, a content template (that is repeated for each feature), and a footer template.  It will replace any attribute name surrounded with brackets with the value of the attribute.  So if you create a header.html file with a single left bracket (‘[') and a footer.html with a single right bracket (']‘) and then a template.html file that is something like:

{
id: “[id]“,
attribute: “[attribute]“
}

you’ll get responses to your GetFeatureInfo request in proper JSON, e.g.:

“[ { id: "123", attribute: "foo" }, { id: "456", attribute: "bar" } ]“

GeoServer has a different structure for its GetFeatureInfo templates, which is described here but the same basic approach works, with the major difference being that you create a single template with header and footer sections.  I’m not sure how it’s done with ArcGIS Server, but with ArcIMS there are XSL files for each output format, and you could create one that generates JSON without too much trouble if you are familiar with XSL.  If someone figures out how to do this with ArcGIS Server, I’ve love to know.

Of course, what would really be fantastic would be if the OGC standard was extended to include a standard output format — I won’t even dare to dream for a standard way to define the output format.