March FRUGOS Meeting

Here's the plan for the next FRUGOS meeting:

Date: Tuesday March 8th

Place: Central Denver-- 2000 Clay Street, Suite 300 (spitting distance from Mile High Stadium)

Time: 6:15PM

Topic: Rolling With PostGIS

Bruce Rindahl will walk through step-by-step the installation process of the PostgreSQL/PostGIS combination (for Windows). Walk in with your laptop, walk out with an enterprise-level spatial database.

Update: Date has been changed to the 8th. Same time and place.

New Belgium Sees the Lite

In pursuit of the mass market, New Belgium drops one more of their unique and interesting brews; the wild and gamey Biere de Mars, which I loved, is gone, replaced by the lite, insipid, and disappointing Springboard. I didn't care when they replaced Loft with the even-lighter Skinny Dip, but this latest switch is quite a bum deal.

Comments

Re: New Belgium Sees the Lite

Author: bahua

Is this news authoritative? Where did you hear they were getting rid of the Biere de Mars?

Re: New Belgium Sees the Lite

Author: Sean

I contacted the brewers, who said they had quality problems with Biere de Mars last year, and wouldn't make it again until they got it right. Maybe next year.

Proprietary Feedback Part 2

Two weeks ago I explained how proprietary software might benefit open source projects, and began to look for examples to support a proprietary feedback hypothesis. As Paul Ramsey wrote, it's hard to get proprietary users to come out of the closet, so it's very likely that I don't have all the evidence. What I have found does not support the hypothesis of a general feedback between proprietary and open source GIS software. Any feedback is much more narrow and selective. I now have 2 new hypotheses:

Proprietary benefit for open source GIS software is primarily a phenomenon of the GDAL project. No other project has such a list of proprietary contributions, and I think this says more about Frank Warmerdam, his ingenuity, and his customer service than it does about open source GIS in general.

Proprietary benefit for open source GIS software goes almost exclusively to low-level projects. What are proprietary software companies contributing to GDAL? Drivers. Format readers and writers. Bedrock functionality. Not all contributions go to GDAL (a fact that undermines my first hypothesis a bit), but the others do go to similarly low-level projects. See the comment about GEOS in my previous post.

My conclusion is that developers of higher-level open source GIS projects shouldn't be overly concerned about scaring off contributions by choosing the GPL. I've found vanishingly little evidence that proprietary companies contribute at other than the lowest level.

Comments

Re: Proprietary Feedback Part 2

Author: Chris 'Xenon' Hanson

I would agree with the facts for the most part, but I think the conclusion is subtly flawed by the choice of the investigation. High-level apps are less likely to contain code that is useful in a context outside of themselves (open source, or not). One might as well ask, what portion of code from a high-level open source app is reused in ANY other context -- open source or not. It's simply a matter of common sense that low-level libraries and components are more likely to be useful to projects outside of themselves, open source or proprietary. The greater outside use a body of code has (irrespective of the licensing it's used under) the more likely it is to get contributions from those users (again, completely regardless of what licensing those users participate under). If you compared the amount of code reuse between a high-level apps and low-level apps, I think you'd find it's in remarkably similar in proportion to the same comparison focusing only on proprietary users/contributors. A side issue is this: It benefits users, commercial and otherwise, to have commercial/proprietary companies utilizing and contributing to low-level Open Source projects. The more people who utilize a piece of code (especially something implementing a standard like a file format) the better exposure and expansion of capability that code gets. As a concrete example, look at libtiff/geotiff or libjpeg. So many programs rely on them that it's to the point where if those tools can't handle a particular file, it's probably a failing of the file. The open source nature of the code has led to them becoming the de-facto standard, improving interoperability far beyond what we'd have if everyone tried to roll their own. A discussion of the pitfalls of a code monoculture (a la Microsoft Windows) is beyond the scope of this discussion.

Re: Proprietary Feedback Part 2

Author: matt wilkie

What about ghostscript? It's the oldest open source project I can think of with a very strong proprietary backing. Dunno how many proprietary contributors there are outside of Aladin tho. Although it's model is very different from most, and from gdal, it's history also supports the low-level hypothesis.

Geospatial Mashup Components

When Howard announced his projection web service, I told him that this was not nearly as useful as a service that operates on entire documents. A service that reprojected, buffered, or spatially aggregated the items in a GeoRSS feed or KML document could be a great component in a mashup pipeline. Pipes doesn't support remote modules yet, but I expect that's only a matter of time. It's an obvious next step.

TileCache 1.4

I forgot to mention that TileCache 1.4 was released this week. If you're running MapServer as a WMS without any WFS requirements, you've gotta check out TileCache. This is, without a doubt, the best way to use MapServer on the web. The WSGI support is my favorite new feature as it provides a simple and effective protocol for implementing custom request and authentication handlers. In Python. It's 2007, do you really want a C program answering the internet phone when it rings?

GeoRSS Caution

I think that if you write something cautionary about GeoRSS, like this:

Do be careful, because while these are "standards" they've not been approved by anyone, just put out there by their creators.

and also happen to consult for an industry standards organization that maintains standards alike to GeoRSS, you probably ought to make a disclosure statement of some sort. Even if your blogging has been generally favorable to GeoRSS.

Standardizing on RSS is a no-brainer. There are orders of magnitude more information being shared via RSS than by OGC protocols. It works. It scales. It's extensible. It's not going away. The success of RSS is very much a grassroots story. These folks didn't wait for W3C approval, they mobilized and took the web by storm.

The largest risk for you, the GeoRSS implementor, is that you'll go overboard with multi-part GML 3 geometries that others won't parse. Don't get me wrong, GML 3 is my favorite OGC spec by far, and has been a big influence on the development of PCL's feature model, but the fact remains that there aren't yet any full-featured GML parsers that integrate well with the top web scripting languages. I'm trying to do something about that, for Python, but it's nowhere near ready.

Update: I'm clueless. No disclosure needed.

Comments

Re: GeoRSS Caution

Author: Adena Schutzberg

Sean, I no longer "consult for an industry standards organization that maintains standards alike to GeoRSS." Adena

Re: GeoRSS Caution

Author: Sean

I should have asked you before posting. Sorry, Adena.

Re: GeoRSS Caution

Author: Allan

Don't feel bad, Sean... I stopped consulting for OGC in May 2001 and it took years before people stopped thinking I was working for them.

More Geo-JSON

Platial's Chris Goad is offering JDIL as a way forward for Geo-JSON. JDIL (I presume this is an acronym for JSON Data Integration Language) is used at Platial to map RSS 1.0 XML feeds to JSON [example feed]. It's thorough and seems a decent solution to the problems particular to RSS 1.0, but those problems don't exist in my applications.

The reason for the interest in Geo-JSON, for those who aren't familiar with JSON, is twofold: JSON can be evaluated by your browser's javascript engine, and, wrapped in javascript, can exploit a hole in your browser's same-domain policy (nicely explained by Douglas Crockford here) and allow you to integrate geo-data from diverse sites. The same-domain policy prevents us from using XML, and efforts to port XML features to JSON seem to be an inevitable result. I'm not as pessimistic about these efforts as some.

The Geo-JSON I am using for Pleiades [wiki, example] is inspired by Atom 1.0. There's no pastiche of namespaces, and, as far as I'm concerned, any specialized content could be carried as an escaped XML string property. I also prefer arrays of numeric coordinates to JDIL's georss:type string property, as it removes the need to parse a string on the client end. What to do about polygons with holes or multi- types is an open question. I think the way to go is to follow WKT, but with arrays of numbers instead of text.

Comments

Re: More Geo-JSON

Author: Tom Kralidis

Have you tried processing remote-site XML with proxies? Note that, in Apache, you can do a bit with mod_proxy, or you can have a proxy script (Mapbuilder has this for remote XML services).

Re: More Geo-JSON

Author: Sean

Sure, but that's beyond the ability or means of most users.

Re: More Geo-JSON

Author: chris goad

Putting coordinates inside strings, rather then in arrays or structures, comes from GeoRSS . JDIL itself doesn't care - it provides encoding for whatever vocab is of interest (the examples happen to use GeoRSS) I agree that it's better to expose the structure of the data directly in JSON, rather than requiring string parsing. The w3c geo vocab does this, but only for points. Maybe a future standard will fill this gap ....

Re: More Geo-JSON

Author: Rob

We've done something very similar...
{
  "version": "1.1",
  "srid": "EPSG:2193",
  "items": [
    {
      "id": 1234,
      "point": [1729539, 5914273],
      "title": "TEST_1234",
      "link": "http://example.com/url/for/poi/1234"
    }
  ]
}
(it's also valid to use 'linestring' or 'polygon', in which case it's an array [x0,y0,x1,y1, ...]) Which is similar to the content transferred via GeoRSS...
<feed xmlns="..." xmlns:georss="..." xmlns:gml="..." >
  <id>http://url/of/georss/atom/feed</id>
  <title>GeoRSS Atom Example</title>
  <updated>2005-06-06T00:00:00Z</updated>
  <entry>
    <id>2230</id>
    <updated>2005-06-06T00:00:00Z</updated>
    <title>Test Point 2230</title>
    <summary>Summary of Test Point 2230</summary>
    <georss:point>174.568911290684 -36.9276921875886</georss:point>
    <link href="http://url/to/detail/on/point/2230" />
  </entry>
</feed>