Boston OSGeo Code Sprint Synopsis

nospam@example.com (Regina Obe) — Thu, 28 Mar 2013 17:49:00 -0400

The Boston OSGeo Code Sprint ended today. Overall I think it was a great success just in terms of what was accomplished and the fact that it was the very first conference we had ever set up. We were all nerves so couldn't enjoy it as much as we wanted to. It was also the first conference we were able to sorta attend all days for.

Paul already gave a great cap on what was going on in the PostGIS and MapServer camps. I still felt like there was way too much coding going on and would be nice to have a bit more talking and a bit less typing.

I want to thank EnterpriseDb for being a Gold Sponsor and it would have been nice if they gave a talk. Maybe I can drag them in some other day. Rich Grady, of AppGeo gave a wonderful and humorous talk about the metamophisis AppGeo is going thru coming from a predominantly ESRI shop, now focused on the prize of finding the best solutions to solve spatial IT problems; which surprisingly does not always involve ESRI and is more and more requiring Open Source GIS technologies. They did show off their ESRI medals of honor and how well they kept papers from flying around.

For those who contributed to our pgRouting campaign, a BIG THANKS. We'll be circling back later this week or early next to try to finish collecting and charging credit cards. If you already wrote us asking, but how do I pay? and we haven't responded with details, don't worry about it. We'll get to you next week. More concerned about those who haven't contacted us.

Continue reading "Boston OSGeo Code Sprint Synopsis"

Mapserver Cheatsheet

nospam@example.com (Regina Obe) — Tue, 30 Dec 2008 16:19:00 -0500

We started to upgrade all our old mapfiles to the new 5.2 standard because first its about time and now that we are starting to do a non-trivial amount of Mapserver consulting, we felt it important to keep informed.

In doing so we started to develop a cheat sheet to help guide us on what's possible in Mapserver Mapfile 5.2. The cheat sheet can be found here -- keep in mind its still a work in progress so please refrain from laughing. In the middle of making this -- all the mapserver document links changed. I guess Mapserver documentors were busy too. I must say the new documenation is much better than the old. It has some nice examples all nicely color coded. So I want to thank Steve Lime, Jeff Mckenna, Jean-François Doyon and the others in Mapserver doc group for a job well done.

In mapping this cheat sheet out, the first thing slapping me on the side of the head is Mapserver really needs an XML defined schema. Yes I know I sound like a hypocrite and one who has been smoking XSLT a tad too long for my own good. Yes I was on the side of the group of people who thought What is it with these XML idiot lovers. What is to love in such a monstrously verbose unforgiving format? Mapfile format is wonderful, easy to read, fast to parse, and write THANK YOU very much.

Now it appears I am switching camps. Wait a minute though - the truth is I could care less if the Mapserver engine can understand XML. I just want to write my map file in XML and am happy to XSLT it to a format Mapserver can deal with. Why? Do I think XML is a beautiful language? On the contrary -- I find the format stinks and I think it is inefficient in many use-cases. It is in fact the most abused language if there ever was one.

Our main frustration with XML is that in our line of work we do a lot of data loading, data scrubbing and so forth, and we are usually on the side of the fence where some goof-ball gives you some blob of XML with weird characters and other junk and just stuffs it in a CDATA tag and thinks that will solve all issues or where some guy just took OO UML 101 and he has spent a great deal of time over-thinking his data model when time would have been better spent getting loaded at the nearest bar. He has this wonderfully elaborate 30-level portable XML data file for his simple list of jobs complete with 200-pages describing every facet of it for you to digest.

XML is bulky, unforgiving, and easily abused so why is it useful? The beauty of XML and XML XSDs is that a lot of software and development tools support them.

If I had an XSD for mapserver, my editor would immediately tell me what values are valid for each type that takes a fixed number of constants
My editor would immediately tell me when I am stuffing something in a layer that is not valid
I can XSLT my way to a standard mapserver file or god forbid some sort of tree thingy with links to documentation of that element. How many times have you looked at the mapserver documentation and thought? Can I stuff this object in a layer group? Have no clue - the documentation doesn't really tell me that unless the writer happened to remember and even then there is way too much reading involved for my 5-minute attention span to deal with.
Nowadays XSLT joins the group of SQL as an embeddable language. Can you think of a modern language that can't deal with XML/XSLT? In PHP/.NET which we program in predominately, both have XSLT classes that can take any xsl file and xml file and transform. My code editor has a built-in XSL processor.
Mapserver mapfile format just lends itself to that - think nested groups, groups that can go in some groups but not others or can have at most x number of item z in it. Mapserver is far from a simple structure with simple rules, so demands something designed for that kind of thing.
I tend to think it would help the documentation effort immensely too, because right now as the documentation stands, there is not enough cross-referencing going on or an easy way to visualize the natural flow of the map file. An XSLT of an XSD would solve that problem nicely I think. Take for example LABEL. Do you have any clue what elements a label can be stuffed in if you were just starting out?

So to me -- or at least with my understanding of things XML -> MapFile -- fairly trivial, XSD fairly trivial but torturous exercise, MapFile --> XML not so trivial but less torturous exercise. I'm perfectly content with an XML -> MapFile route and am actually thinking about creating such a thing for 5.2 if someone hasn't done it already, if only I could ever find the time, but if things keep going as they are, I may just have to do that if nothing but to keep my sanity.

BostonGIS Blog - mapserver

Boston OSGeo Code Sprint Synopsis

Mapserver Cheatsheet