2007 (old posts, page 4)

Atom feed RSS feed

Planet Geospatial Lives

Looks like Dr. Fee-enstein has finished bolting together his new creation, and is beginning to run some current through it. I see more feeds than ever, which i suspect means even more press releases, thinly-disguised product blogola, .NET fanboys, zimboe minions of SOA, and Python nutjobs that you'll want to filter. As soon as Planet Geospatial consolidates, I'll update my Greasemonkey script.

Update: If you're a user of the Planet Geospatial Scrubber and have any ideas for it, feel free to let me know with a comment or email.

Comments

Re: Planet Geospatial Lives

Author: James Fee

This is just the old previous version. The new python backend isn't finished yet, but template will be the same. Now would be the time if you want any enhancements to that template.

Re: Planet Geospatial Lives

Author: Sean

I think the HTML is fine, James. I'm thinking about adding a checkbox (using greasemonkey) to hide/show toggle the filtered items, but that wouldn't require any changes to your code.

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.