Technical Ramblings

From the mailing list:

Tomorrow Ordnance Survey (Britain’s national mapping agency) is letting a group of developers preview a new mapping API named OS OpenSpace. We aim to launch this to the public in January. We have used OpenLayers as a base for the API and have really enjoyed the opportunity to work with such a comprehensive library.

The email goes on to say that they’ve added a number of features to OpenLayers… but offers no indication that there is likely to be any likelihood of sharing the changes back with the OpenLayers community.

Of course, this doesn’t really come as surprising: a number of aspects of the effort are somewhat misguided. Very low request limits, “we own all your derivative work”, etc. However, there is one thing that is interesting, brought up on the OpenStreetMap Mailing List:

4.4 In the event that you or any User creates Derived Data, such Derived Data shall be owned by us, save that if any Derived Data is created which is a severable improvement (as defined by Commission Regulation (EC) No 772/2004, known as the Technology Transfer Block Exemption) of the Ordnance Survey Data then such Derived Data shall be owned by the person or entity creating the same.

The interesting bit is the “severable improvements” bit, which Richard Fairhurst (a member of the OSM Foundation) delves into a little deeper:

In practice, then, I read that to mean that if you use the Sustrans webmapping to find out where the routes go, this information is solely copyright Sustrans (who might be more willing to give permission) and not OS, even though it’s delivered through the medium of a derived work. So, if you had the wiggly lines already (whether mapped by GPS or NPE), you could tag them as NCN routes if Sustrans were ok with that.

Certainly brings an interesting development into the world of ‘derived works’ based on OS Mapping for the free data crowd.

Regardless, I must admit some level of frustration with users who bother to email and say “Thank you”, but not to contribute any effort into further development of the software they’re using. I suppose it’s better than ignoring the project entirely, but some of the things mentioned in the email are things I would love to have in the trunk — and there wasn’t even a consideration given to the mailing list as to whether we were working on some of these things.

I wonder if the OpenLayers community is scary in some way. We really do try to be open and welcoming. Maybe I’m just too much of an ass to people on the mailing list, but I try not to do that to people who actually want to help…

San Diego Wildfires 2007

Lots of different data here:

• Landsat7: i-Cubed processed landsat7 WMS hosted by Telascience.
• USGS Urban Orthos, hosted by Telascience.
• 2006 DigitalGlobe imagery of the area, hosted by Telascience — built last night specifically for this project
• MODIS fire map (last 7 days), hosted by Telascience, put together by Martin Spott
• OpenStreetMap Hybrid tiles built by me and hosted by TelaScience
• Destroyed houses: WFS served by FeatureServer, initial population from KML file
• 2 KML files, from Google MyMaps: KPBS and LA Times
• Geotagged Photos tagged ‘wildfires’ from Flickr, converted to WFS by FeatureServer.

The WPServer demo is more complete now: WPServer Demo.

New functionality:

• More operations
• Control over size of buffer
• Control over tolerance of simplify
• Ability to select specific features to operate on
• More complete set of OpenLayers Feature editing tools

Note that everything here is included in the stock version of what will be OpenLayers 2.5. All the code that you need to set the client up is displayed in the web page — there’s no magic behind it.

There is one additional thing to note: The demo now has the ability to load features from the FeatureServer demo. This is one of the most important things about working over the web: the various pieces of data that exist in disparate data sources can be integrated.

Unfortunately, this is made harder than it should be because of the limitations of the browser. For security reasons, it is not possible to load data from any URL on the web: in this case, the WPServer ‘noop’ (no operation) is used essentially as a GeoJSON proxy, fetching the features from FeatureServer to bring them into the local javascript domain, where we can fetch them. However, once that proxy is set up, we can fetch data from multiple locations, and put it together on the client, creating new features from the old, and taking them out to put them wherever we like.

Note that although this demo uses GeoJSON extensively — it’s the only language WPServer speaks at the moment — there’s no reason for that to be the case. OpenLayers has the ability to load data from WFS, as well as the ability to load other things like KML documents. You can load these datasources into the same layer, and use the WPServer functionality to put things together.

Want your shapefiles on a map? Use FeatureServer. Want to buffer each of the points in your FeatureServer-served data? Serialize them, and pass them up to WPServer, then display the data that comes back. Want to mix in KML data, to see the intersections? Add a KML layer to OpenLayers, and use WPServer to do the intersections.

… Crap. I think what OpenLayers can do now might actually be something people would refer to as GIS.

There’s a couple of different efforts going on to do web processing over the web — in an effort to understand what it’s all about, I put together a little web processing server and a demo to go along with it.

WPServer Demo

Using OGR and the GEOS operators built into it, it allows one to do operations I’m told are common: buffering, centroid, convex hull, and dissolve.

The source for these operations is simple: as few as 8 lines to define your own operation, as the OGRGeos operators and the Shapely buffer operation show.

The Boston Routing Demo is also now using WPServer to do its routing, via the PGrouting action.

Although WPServer shares an acronym with OGC’s WPS, it doesn’t yet implement WPS — however, like FeatureServer, it has a pluggable frontend architecture for determining the types of actions to perform… but only REST + GeoJSON are supported so far

I think it’s a pretty looking demo, even if I’m not sure if it’s useful at all.

I’m curious about how others store/evaluate SLD rules/filters. At the moment, in OpenLayers SLD rendering, we have an ‘applies’, which is a string something like:

“feature['attributename'] == ‘foo’ || feature.fid == 1″

Which we eval. Yuck, I know.

But how else do you do it? What’s the internal storage look like?

I originally thought of something like a set of tuples:

(’operation’, ‘value’, ‘type’, ‘extra’):

• (’equals’, ‘foo’, ‘attribute’, ‘attributename’)
• (’equals’, 1, ‘fid’)

But then Andreas pointed out that these are not just ‘and’ or ‘or’, but either of the two, and can also be nested… it seems like it quickly goes complex enough that we would need to implement a full boolean logic thingy of some kind, and it seems like the wrong way to go… but then again, so does eval.

Would love to have advice from someone else as to how they implement SLD filters and their application.

For the record, from the OpenLayers IRC:

The Satellite tiles from Google Maps appear to be dead. This is not a OpenLayers problem — This is also happening on Google Maps homepage.

So don’t blame me!

So, one of the things I learned on Monday here at FOSS4G was how to set up pgRouting. pgRouting is a Postgres-based routing engine, originally developed by those wonderful Camptocamp folks, and since taken over by Orkney. The workshop showed us how to do routing with OpenLayers and pgRouting over Google Maps with free Canadian data.

With some urging from Erik, I put together a demo of this functionality — but of course, I couldn’t stop at just that, and instead had to go farther and do on-the-fly routing as you drag:

View the Demo on another page

Or, if you’ve got an SVG/VML supporting browser (Almost all of them, these days), check out the live demo of Boston.

OpenLayers talk bursting at the seams. Went well, though Tim rushed it at the end so there weren’t as many questions asked as I had hoped there would be. I’m thinking that the ordering process from votes wasn’t really informative enough for making room decisions — some of them seemed to be in the wrong space for the crowd, though of course you can’t tell that ahead of time. Perhaps this just means that people who voted were biased away from things like OpenLayers and FeatureServer relative to the majority of the population… but then again, TileCache went in the Big Hall, and that’s only really usable with OpenLayers as far as I know…

Anyway, we also had the pre-sprint BOF, where we talked through some ideas on what we want to hack. It seems like improved documentation is definitely on the list, as well as context and animated panning/zooming. We’ll see what gets done, but it’s exciting times.

Speaking of exciting times: Camptocamp’s Cartoweb got rave reviews from everyone I talked to. (And, What is it based on on the client side but OpenLayers?) It seems like a really new thing to most people: “Wait, I can do real GIS-y things in a browser? Why did no one tell me this before?”

I don’t know about everyone else, but I was hugely impressed by seeing OpenLayers doing things that looked to me like real work: attribute search, quantile based styling, etc. Things that every GIS application seems to have — and now you can get them for OpenLayers too. Cool stuff.

OpenLayers 2.5 RC1 has been released. Bug reports are, as usual, solicited from any and all users. More links in the OpenLayers Blog Entry.

Here’s hoping there’s a final release before the end of FOSS4G…

For the past week, I’ve been working on OpenLayers 2.5, which has been rewarding, though exhausting. I’m looking forward to getting our first RC out the door — maybe even sometime next week, if I can get enough attention from other developers. Check out the post for an overview of some of the cool stuff coming up in the next release: GeoJSON, better vector feature editing support, better commercial API interactions, and more.