2006 (old posts, page 15)

Atom feed RSS feed

Persistent Misconception About the GPL

David Maguire writes:

There are two primary reasons why ESRI joined the group: the opportunity to work at a peer to peer level with smart developers so that we can build useful GIS code that will advance the GIS field; and to explore the community software development and open source licensing model.

Here's a couple tips -- as if this will be read ;) -- to get started: Buy and read Producing Open Source Software. Yes, buy it. Next, disabuse yourself of the misconception that the GPL is non-commercial (from Maguire's entry):

Products will be available using two licensing models: GNU General Public License (GPL); and a commercial use license.

Commercial use is not prohibited by the GPL. From the terms, 1:

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

This means that anyone can take GPL software from the 52N initiative, make a sexy box, nicely-bound manuals, and sell these physical copies for any price so long as they meet all terms of the license. If 52N seeks to own all commercial rights to the software, it will have to find a different license.

ER Mapper is another company that can't seem to get its head around around the GPL yet. They consistently refer to their non-commercial license as "GPL-like".

Thanks to James Fee for clueing me in.

Comments

Re: Persistent Misconception About the GPL

Author: Joel

Sean (and James?), I can see two reasons for the 52d North dual license with a "commercial-use" version. Please correct me if I am wrong. 1) Many companies are reluctant to use GPL'd software because of item 2-b, a.k.a. the "viral" part of the GPL. Nobody wants to stack their profit-making IP on top of a library which would automatically GPL their work. Using software as a development platform is different of course from simply using the software as is. The commercial license would allow a commercial GIS company to develop a product based on 52d North-release software. 2) Some large organizations, including many federal agencies, require a license with a purchase receipt for accounting purposes. Even if you charge $1 for the license the bean counters are happy. This is not a 100% fool-proof way of avoiding licensing issues of course but it's the way it is done. I've worked with and for these types of organizations. The U.S. Navy always buys a license whenever possible and if they can't they get a letter from the software creators giving them specific permission to use the software for documented purposes. They do this for Tomcat and Apache and probably Plone. Many large companies do this in an attempt to avoid license infringement lawsuits. This fact is one of the reasons ESRI started endorsing and even including "ServletExec" engine with ArcIMS as an alternative to Tomcat.

Re: Persistent Misconception About the GPL

Author: Sean

Joel, I don't disagree with you at all. I was just pointing out that the GPL may not be the non-commercial license they are looking for.

Re: Persistent Misconception About the GPL

Author: Joel

You are right. This is a huge leap for ESRI and they will probably stumble into the open source world like a bull in a China shop. But this initiative and their adoption of gdal in ArcGIS 9.2 is amazing to me. They and every other GIS company has always at least verbally supported OGC's open standards but open source software is a differnt story. ESRI definitely seems to be taking open source software seriously. I am certain this is in no small part to the community and variety of projects which radiate out from Mapserver. The steady improvements in open source GIS software and the coverage on blogs and the few books which have appeared are having an effect. Things are getting very interesting.

REST and WMS

Could WMS have been REST-ful? Andrew Hallam says probably not. I think he's being too strict about REST. It's quite acceptable to send data specifying aspects of your request. A REST-ful WMS request would look like:

GET http://host/wms/1.1.1?layers=one,two&...

The WMS service and version would be specified not in the query, but by the HTTP method and URI. Every other parameter is now of a kind: they parameterize a view of the WMS resource.

Comments

Re: REST and WMS

Author: Andrew Hallam

WMS could have been designed to be RESTful. Things are the way they are because they got that way. I don't think my application of REST principles to WMS is overly strict. In the case of WMS, it may not be practical, but to claim to be RESTful you should follow the principles (hence my original rant). A key abstraction in REST is that a URI identifies a resource, a "thing". That resource may have multiple representations in different formats ("views"). i.e. The URI does not identify the content transferred (the "view"), just the abstract "thing" without form. Say I request a map with FORMAT=image/gif&. I then change the FORMAT parameter value to image/png and send the request again. I consider the responses I get back to be two different representations of the same map. Same applies if I vary the BGCOLOR value. It's just a different representation of the same map. Therefore, any WMS query parameter that defines the format, or portrayal, of the map's resource representation should not be part of that map's URI. It seems like a small distinction, but it is a key part of REST.

Re: REST and WMS

Author: Paul Ramsey

I am still wrapping my head around the right ways to approach this very nice design philosophy, but I think this page has some useful perspectives on dealing with resources that can be consumed in different formats: http://www.peej.co.uk/articles/conneg.html

Re: REST and WMS

Author: Sean

Andrew, I agree completely with your comments. Did I misunderstand your blog entry? I took your point to be that a WMS request would need to be free of view-specifying query parameters to be REST-ful.

Levels of Openness

Some of us care a great deal about open development as well as open source. Howard explains. I've been recently cajolling the authors of a well-known, open source, closed development project about just this issue.

New OSGeo Executive Director

I was complaining to Frank "El Presidente" Warmerdam last week that OSGeo was too opaque and needed to shed a little more blog light on itself. Today is different, with almost every OSGeo-related blogger reporting on the hire of Tyler Mitchell as Executive Director. I've met Tyler. He's a good guy. I think he was one of the last people to let the doomed, brain-dead, MapServer Enterprise/Cheetah notion go, long after it had crashed and burned like the Hindenburg, but I can't hold that against him forever, can I? My only question is: did the board consider anybody from outside the MapServer Foundation cabal?

Comments

Re: New OSGeo Executive Director

Author: Gary Lang

Sean, It was definitely discussed. This was one of those hiring situations where you had a great candidate in hand, and stood to lose the opportunity if you deliberated too long. That's all that happened. In big companies, you are often required to post a job description and hope that you don't lose the perfect candidate you have in your hand. Luckily, OSGeo is not a big company. Gary

Re: New OSGeo Executive Director

Author: Mateusz Loskot

Sean, I'm not sure I understand what's wrong (if there is anything) with selecting candidate from MapServer Foundation. AFAIR, the MapServer Foundation was the very first initiative trying to organize GIS and Open Source communities. People gathered around MapServer Foundation are pioneers in this area and I'm sure they have experience and knowledge that's valuable and even needed for the OSGeo.

OWSLib 0.1.0

Landsat mosaic, Colorado Plateau

Uploaded: http://cheeseshop.python.org/pypi/OWSLib/0.1.0.

OWSLib is a Python package for working with OGC web map and feature services. It provides a common API for accessing service metadata and wrappers for GetCapabilities, GetMap, and GetFeature requests.

It's the work on this software that made me so grumpy about WFS yesterday. OWSLib is designed to forward imagery and feature responses to the user, and raise an exception in the case of a W*S service exception. It would be nice to be able to do this just by inspecting response headers, without looking in the data, but that's not possible in the WFS case. My solution is to waive large data through, assuming success, and only check smaller responses. I think this will generally work, though it could be spoiled by enormous tracebacks that make their way into service exception messages.

Comments

Re: OWSLib 0.1.0

Author: Joel

Excellent! Thanks, Joel

Why Does WFS Dislike the Web?

I read Andrew Hallam's post about REST Abuse last month, and nodded: right, REST != not SOAP. There's more to it. I've spent the past two days programming WMS and WFS clients, and have a little more to add to his thread.

Look at the specs and you'll see that WMS and WFS are aimed at a number of possible distributed computing platforms (DCP). For the enterprisey there is a SOAP DCP. Operations which can't or won't enter the 21st century could use a CORBA DCP. Howard Butler might be willing to scope out an ICE DCP for you. The one DCP you're going to encounter in the wild is named HTTP.

Comments

Re: Why Does WFS Dislike the Web?

Author: Tom Kralidis

Interesting; a few comments: If someone were to use the native HTTP methods, then that wouldn't that have stuck things more in the hands of the httpd server for configuration? The OGC way, it's easier to decouple and add an auth layer between httpd and the application software (or within the app software). Mind you, it's work either way. Also, HTTP status codes are totally different things then ExceptionReport codes. An ExceptionReport still comes back as HTTP 200 as it should, i.e. the HTTP response was successful (as a protocol), but the service returns error.

Re: Why Does WFS Dislike the Web?

Author: Allan Doyle

Historical precedent. WMS was developed in 1999, before we had heard of REST. (Note - Fielding's dissertation is dated 2000). WFS was patterened after WMS. I first bumped into REST in 2000 during the 2nd OGC testbed and as much as things made sense to me, it wasn't clear at the time how to turn the momentum towards REST, particularly in the face of considerable pro-SOAP interest. There are certainly things I wish we had done differently for WMS. In particular, I think having a CGI interface to the capabilities document has proven to be a huge impediment to getting people to think about search engine friendly ways of advertising WMS's.

Re: Why Does WFS Dislike the Web?

Author: Sean

Tom: yeah, my status code idea was naive. Certainly some clients are counting on a 200 along with their service exception. I think the protocol is wrong here. They *should* expect a 400 for a bad request, or a 500 for a WFS server error (db failure or whatever). Allan: REST has been around longer than that. The intro to Fielding's dissertation states that REST has been guiding the architecture of the web "over the past six years". Despite that, it's been easy to overlook. I totally agree with you about the problem with GetCapabilities. Thanks for the comments!

Re: Why Does WFS Dislike the Web?

Author: Panagiotis (Peter) A. Vretanos

Allan: with regard to making OGC services more "search engine" friendly, I think that the upcoming version of OWS common mandates that OGC services generate some descriptive metadata when they are invoked without any parameters. Is this what you had in mind for making OGC service more search engine friendly.

Re: Why Does WFS Dislike the Web?

Author: Allan Doyle

Comment to myself... maybe it was actually the 3rd testbed. It's all a blur :) Sean - yes, REST has been around as a concept, in fact, it was probably *the* concept before the XMLRPC folk started in and laid the foundation for SOAP. I think we're actually lucky that WMS turned out as it did. Peter - Holy cow! I just took my first look at OWS Common in a long time. I mean http://foo.org/mywms should have been a perfectly good WMS capabilities URL. I guess that wouldn't neccesarily improve searchability, but it would make it far easier to get results than having to try all the variations of GetCapabilities that have sprung up. Getting back to the upcoming OWS Common... I don't exactly see iPod-like zen. Who's going to implement that stuff!?!?

Re: Why Does WFS Dislike the Web?

Author: Panagiotis (Peter) A. Vretanos

Yes, I must admit, when I see the page count it does seem rather daunting! However, keep in mind that OWS common gathers up bits and pieces that might be common to a bunch of OGC services ... like BBOX. Theortically it should make the other specification shorter since they only need reference OGC common!?

Re: Why Does WFS Dislike the Web?

Author: Steven Citron-Pousty

REST is the anti-SOAP. I know they try to do the same types of things, it's just that SOAP brings all this extra baggage that I never needed. I like REST for it's ease of use. Give me tomcat and dom4j and I am good to go...

Re: Why Does WFS Dislike the Web?

Author: Chris Tweedie

Instead of using status codes, why not propose using the same mimetype method as WMS? Even though having different mime types for seemingly text/xml responses is a pain on occasion, its times like these that it makes detection so much easier. I'd vote +1 for WFS application/vnd.ogc.se_xml (or something similar).

REST and OGC

Author: Paul Ramsey

I have a theory about this: doing good REST requires understanding and using two or three different standards, HTTP for transport, URL/URI for location, some kind of *ML encoding and maybe MIME. If you know all those standards and spend a little time cogitating, it's hard not to end up RESTful. If you only really know *ML, then you tend to ignore things like HTTP codes or MIME types, and you get stuff like WFS, where almost all the magic happens in the content encoded bundle, and all the rest is treated as anonymous pipes. The ironic part is that OGC itself is trying to divide up its standards base into lots of little orthogonal pieces... data encoding, data styling, metadata encoding, service profiles. And it is getting swamped by things like KML that stuff all the information into one big block. WFS is web services ignoring the most of the web. KML is geodata interoperabilty ignoring much of the existing standards base.

Re: Why Does WFS Dislike the Web?

Author: Allan Doyle

OGC originally was trying to steer around the OLE/DCOM vs. CORBA debate. The Simple Features spec actually had a CORBA version, an OLE/DCOM version, and an SQL version. There was always the feeling that the OGC spec had to ride one level above the actual transport since otherwise it would be too hard to move from one to another. And I'm not sure many participants in those days would have been up to speed enough on HTTP/URI/XML to come up with a real REST solution. KML seems to be swamping everything else because it's easy to hack up quick things w/o having to read very much. You can get better at KML hacking slowly, without having to break much of a sweat. I don't think you can say that about most OGC specs.

Re: Why Does WFS Dislike the Web?

Author: Andrew Hallam

I've posted on a related topic, WMS Practicalities and REST, inspired by Allan's comment on making it "easy to hack up quick things".

Geo-JSON

Pleiades uses JSON when transporting map contexts and map features from Plone to our OpenLayers-based javascript applications. Our evolving flavor of geo-JSON is documented in the Pleiades wiki. I'm curious to find out if anyone else is doing something similiar.

Comments

Re: Geo-JSON

Author: Chris Holmes

Looks cool. Do you think there'd be value in having GeoServer output JSON features? It's quite easy for us to write a new output format for WFS.