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.

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.

Today, I finally made the switch from the 7 month-running Mapnik based homepage map on the boston freemap to a MapServer 5.0-based AGG rendering.

The new map has had more cartography put into than any existing Boston Freemap to date. Maps like:

Cambridgeport
The state of Massachusetts
Downtown Boston

All demonstrate some of the qualities offered by the new MapServer.

Among other things, the new maps:

• Have had the labels lowercased, to fit more text in (Python OGR script I wrote, help from #gdal)
• Have had sortshp run over them, to order them so that you don’t get weird overlaps (help from danmo)
• Have had additional cartography work done in order to create a better fit for labels
• Benefit from the excellent AGG rendering work I’ve been describing here, by tbonfort.

In my opinion, the look and feel of these maps really does approach the level of quality that the commercial services have set, as far as rendering goes. MapServer’s leaps and bounds in the past couple weeks in rendering have changed the game from being a “Work on the rendering” game back to a “Work on the cartography” game.

I want to send a special thanks to tbonfort and all the work he’s done recently to make this happen! The rendering is simply incredible in comparison — truly night and day. I’m so happy to be back in MapServer land where the hard work I’ve done on this cartography hasn’t gone to waste. He and the other MapServer developers have really brought me back into the fold with the latest work, and I’m happy to be there.

The font work really doesn’t show up well in a small screenshot — it’s a total affect that makes a difference. Comparing AGG to GD is probably pretty informative though.

So, OpenLayers wants to use a single well-known number to describe the ‘Google Projection’ I talked about earlier. 54004/54005/41001 are all ‘well known’ as being a standard Mercator projection. Which is not the Google Projection.

So, in addition to http://spatialreference.org/ref/user/google-projection/ / http://spatialreference.org/ref/user/6/ , we need something we can use in “SRS” in WMS — an EPSG code, such as it was.

In order to pick one that doesn’t conflict.

It’s the ‘Google’ projection — so we picked 900913. (Google. In 1337-speak.)

Use it. Love it. Promote it.