Paul Ramsey has an implementation at http://mapserver.refractions.net/cgi-bin/tms/.
I think URL traversal is going to expand and perhaps even blow some minds. Presently, the open source GIS community thinks about web applications almost exclusively in terms of CGI.
I like where Paul Ramsey is going with this. It's not just trendy: it's the way the web works.
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.
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.
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.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.htmlAuthor: 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.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.
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?
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. GaryAuthor: 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.
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.
Author: Joel
Excellent! Thanks, JoelNow which one is the defensive, paranoid, government?
Iran throttles internet access to 128kbps. Interior Bans Reading Blogs.
Update: I've heard that at least one person at the USGS can access All Points Blog.
I've uploaded Quadtree to the Python Cheese Shop: http://cheeseshop.python.org/pypi/Quadtree/0.1.0.
Update: I fixed the bug reported in the comments (thanks!) and uploaded 0.1.1
Author: Jack Riley
I had to remove the ';' on the line containing the PyObject_HEAD macro in order to get _treemodule.c to compile on Win32 using MSVC.
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.