Hobu is getting a lot of attention for his recent article on ESRI and the Google Maps phenomenon. He looks into ESRI's eyes and doesn't see any clear sign that they are ready to make a play for the mindshare of web map hackers.
Frank Warmerdam's proposal to form a MapServer Technical Steering Committee has been accepted. Such a committee is long overdue, and absolutely necessary now as we are beginning to consider some re-engineering of the MapServer core to support input driver plugins and new output drivers.
Initial members are: Steve Lime, Daniel Morissette, Frank Warmerdam, Sean Gillies (yours truly), Assefa Yewondwossen, Howard Butler and Perry Nacionales. Steve Lime is the first Chair.
Dead at 85. Chief Engineer Montgomery Scott was my favorite of Star Trek's supporting characters, and a patron saint of all IT people who've been called upon to do the impossible again and again. Oddly, I watched the episode The Deadly Years just last night, and saw Scotty come within minutes of succumbing to radiation poisoning and extremely accelerated aging.
This past week I spent some time catching up with Zope3 and Five, and thinking about ZCO in this context. I'm determined to bring ZCO a little closer to Zope3 in the next release, but have ruled out making ZCO depend on Five until after 1.0. We now have interfaces that can be readily converted to Zope3 interfaces, and I'm going to be re-doing ZCO's proxy methods in a way more near to the Zope3 adapter pattern.
Tyler Mitchell's Web Mapping Illustrated, published by O'Reilly, could have spared me about a week of hair-pulling back in 2000 when I was just beginning to discover open source GIS software. Our projects are reasonably well documented, and there is an enormous amount of knowledge within the community, but there has never before been a broad and coherent synthesis of that information. Finally, new users can see the entire domain of open source mapping from data creation, to data processing, to digital map. We've needed this book for a long time.
We expect O'Reilly books to be excellent productions, and indeed it is. In appearance, style, and scale, it is like the Web Services Essentials and SVG Essentials -- also edited by Simon St. Laurent -- but has a larger format, better paper, heavier binding, and copious color illustrations. The book takes on a big workflow and diverse tools, but Tyler manages to keep it together with a consistent mapping narrative, clear writing style, and concrete, replicable examples.
Highlights of Web Mapping include:
I would have liked to have seen Tyler take on some of MapServer's anti-patterns, or help users avoid these 300 layer map config files we keep hearing about on the mapserver-users list. I also disagreed with his use of PostGIS geometries as unique keys for spatial sub-selects in Chapter 13. Spatial tables should always be provided with a lightweight unique identifier for this purpose. The book also suffers a bit from too many color screenshots of OpenEV. Powerful as it may be, OpenEV's primitive interface isn't going to sell any copies of this book.
I also wonder whether or not Google, which launched their web map just as this book was going into print, hasn't permanently altered the meaning of "web mapping" and thus moved the book's target. Now, to most of the IT world, Google's map is web mapping; there is one web map, and it's all a matter of annotating it with your own points. A distinction between Tyler's workflow and tools, and what the masses call "web mapping" is important.
In my estimation, users of ArcIMS/ArcSDE who are looking to broaden their horizons will find Web Mapping slightly too introductory, but a still valuable aid in getting over the first humps. Definitely worth buying. IT and Web professionals looking to break into geospatial and mapping work will find this book to be the ideal starting point, as will those who are graduating from Google map hacks to more unique and data-dependent applications.
Howard has put online our workshop materials. I may be recycling some of these at GIS in the Rockies.
Industry was better represented and more involved at this year's conference. A new Directions article lists 10 ideas and themes, and examines the significance for both the open source community and the geospatial industry's mainstream.
Howard Butler, the organizer of the lightning talks and the developer of the new MapServer site prototype, takes a broader view back at the conference.
I really disagree with Adena Schutzberg on this one where she applauds Autodesk's RealDWG countering move against OpenDWG:
"Real" sounds well, authentic, true, and it being from Autodesk, who owns the format, is a pretty good name. The term "open," I believe is the main source for "fear uncertainty and doubt" in IT. No offence to Open Design Alliance, but "open" is just not a strong word these days.
Autodesk certainly can't name it ClosedDWG; it would take off like a jet with a closed throttle. Is RealDWG any better? I've been watching the meaning of the word real erode for years. The obvious recent example, Reality Television, is actually the opposite of reality. Face it, "real" is not what it used to be.
The assertion that the word open itself is the source of FUD is nonsense. FUD is the flop sweat of no longer innovative companies. Open is one of the richest words in the English language, spanning (with its derivatives) 12 pages in my OED. Not every meaning is positive in every context, but it is an overwhelmingly positive word. Ask family, friends, and colleagues whether they consider themselves open-minded. I'd be extremely surprised if a majority say no.
After last year's conference there was some discussion about whether or not the MapServer/Open Source Geospatial community needed a Foundation to look out for the software, its users, and its developers. Some saw the Apache Software Foundation as a model, and were able to bring its current President, Dirk-Willem van Gulik, to tell us all about the ASF and compare the community of Apache users to our own fledging open source community.
We learned that open source GIS projects have asked to join the ASF. They were not enumerated by van Gulik, who simply stated that they had all been quickly rejected. The ASF's great success at promoting and defending the Apache brand is the result of extremely rigorous code requirements which our community's projects cannot, apparently, meet. This shouldn't be seen as invalidation, because the ASF model is not for every community. It arose from the very specific needs of the Apache users who had to find a way to work through the chaos of the internet boom and bust. Competition between their employers was far more cutthroat than we experience in the open soure GIS community, and extreme measures were needed to protect the Apache code.
To me, van Gulik's talk was right on. Instead of bringing answers, he reminds us of questions that we should be asking not of him, but of each other. Which brand is it that we want to promote and defend? Do some of our projects need to be more open? Is our community one of individuals, or of corporate bodies? There are lessons from the ASF, but we are really going to need something more organic.
Update: For those of you coming from mappinghacks.com, I have a follow-up.