Technical Ramblings

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.

Andreas posted earlier today with a followup on the SLD Rules front: Though I had consigned myself to expressions, he had not, and went on to create a very nice looking rules system which supports the full range of SLD operators.

More information is available in his post to the mailing list: the code is in his sandbox (though this URL will move once it moves to trunk).

Three rule types are used to build up rules: comparison rules, for comparing values against feature attributes, FeatureID rules, for limiting by fid, and Logical rules, which group the other rule types together. Logical rules can be AND, OR, or NOT.

One key benefit to this — which I had not thought about until Andreas brought it up — is the ability to serialize these rules back out to SLD. It’s possible to use something like yacc/lexx (C, etc.) or eval() to evaluate an expression — but in Javascript, at least, it’s hard to turn that expression back into rules. This saves us that problem, and means we can serialize out SLD from user-created styling rules — clearing the way for the in-browser SLD editor that many people have been talking about for a long time.

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! 🙂

Three quotes from my presentation earlier today, on Getting Help With Open Source:

• On talking to Open Source developers and asking for help: “Be Polite, Be Concise, Be Gracious.”
• On diving into the code: “Code is pickled, executable documentation.”
• On choosing your requests carefully: “A developer’s time is a limited resource. Don’t waste it!”

Talk went well. Transcript recorded by Arnulf on IRC (original). Many thanks to Arnulf, and all the attendees!

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.

Grabbed Sean Gillies yesterday and talked to him about GeoJSON. We came to a conclusion that his argument against type, although not ill-reasoned, was simply going to require a couple extra edits to the spec that might possibly limit its use slightly more. So, we decided to skip duck typing, use the type attribute everywhere, etc. I don’t know if Sean was really *convinced*, but he was willing to let me put his name back on the spec 🙂

Another GeoJSON community member (Martin Daly) pointed out that abusing EPSG (By saying “Use EPSG, but ignore the coordinate order”) is probably the wrong way to go about things. After talking to Raj, I got some feedback, and posted about an alternative (using OGC URNs) to the list.

So, if you have comments on GeoJSON, please share them now.

After thinking about the previous rant I made on the OGC for the past couple days, I’ve realized that the OGC is not actually the problem. Instead, my problem was with the attitude that has built up around the OGC machine — but that’s not really OGC’s fault in any direct way. I’ll post more on this later, but if I don’t post now, I’ll forget, so: Please remind me, after FOSS4G, to talk about what was wrong with my previous post, and what I think now, if I forget.

Also, there were a couple different technical mistakes in my previous email: I called the TC the “Tech Plenary”, which is not what I meant, and there are other things like that. I’ll clear up more afterwards, and I know a couple people I owe emails and other things to. So, at some point in the relatively near future, I’ll sit down and be rational instead of simply being pissy and reactive.

Though I maintain that talking about REST is meta-wankery, for the most part 😉