Sean Gillies (Posts about mapserver)

XML mapfile

Sean Gillies — Wed, 11 Jun 2008 06:00:00 GMT

Heh. I think "XML mapfile" is a stage that many people (myself included) just have to go through on their way to enlightenment. See also bargaining.

Python, MapServer, and WSGI

Sean Gillies — Sat, 23 Feb 2008 07:00:00 GMT

To enable this is why I added an OWSRequest class and image byte access to mapscript. I'm glad they are getting used.

I was pleased to stumble onto Brent's blog a week ago: I spent my undergrad afternoons working in a molecular biology lab and still dabble in genomics. His genome browser inspired me to see OpenLayers as more than a web GIS tool.

Comments

Re: Python, MapServer, and WSGI

Author: Tim Maddle

I've found the MapScript OWSRequest capability invaluable for overlaying layers in Google Earth, so don't doubt that it's a valuable feature.

Re: Python, MapServer, and WSGI

Author: brent

hi sean, good to hear i've inspired you somehow. i'm an avid reader (and user) of your code and blog. i'm really having fun with mapscript lately.

Map Servers

Sean Gillies — Tue, 21 Aug 2007 06:00:00 GMT

Map servers -- the CGI programs and servlets that render infinitely customizable map images of any scale, size, and format -- remain useful, even increasingly useful, in this tiled world. The MapServer project, for example, is climbing steadily up out of its own "trough of disillusionment" [see hype cycle] towards a 5.0 release next month. Two use cases are driving it forward. Some data are so dynamic that caching is unfeasible or even undesirable. Aircraft traffic is an obvious case. The other growing role for MapServer is that of a tile engine for applications like TileCache. Its already-good cartographic options are getting dramatically better, and longer rendering times become acceptable if your data changes on a time scale of several days or more.

Stop Using Mapscript: Finally

Sean Gillies — Thu, 09 Aug 2007 06:00:00 GMT

MapServer 5.0 has some nice new features. Christopher Schmidt has been blogging the hell out of one. Dynamically allocated arrays (culmination of my work on a container API -- msInsertLayer and friends) is a big one that doesn't get a lot of notice. I think my favorite is this: now you can pretty much stop using mapscript.

Steve Lime did the work. I did the nagging, testing, and the final mapscript touch. Here's a Python usage excerpt from the tests:

>>> import mapscript
>>> mo = mapscript.fromstring("""MAP NAME "test" END""")
>>> mo # doctest: +ELLIPSIS
<mapscript.mapObj; proxy of C mapObj instance at ...>
>>> mo.name
'test'

I've explained the motivation previously. You can now transform the problem of writing intricate, error-prone mapscript code into a more tractable template interpolation problem.

Stop Using Mapscript: Almost There

Sean Gillies — Tue, 01 May 2007 06:00:00 GMT

MapServer revision 6064 (my first contribution in quite a while) has an example of loading a mapfile from a string: fragments.txt. We're getting very close to the point where we can practically stop using mapscript. Users, feel free to add comments to this feature's story.

Comments

Re: Stop Using Mapscript: Almost There

Author: Al

I am just getting into MapServer and have found your posts to be very enlightening. I have only gotten to the point that I can see how I would use MapScript to overlay a map with icons positioned via data in a MySQL DB. Is it possible to duplicate that sort of functionality with map files? Any pointers on where I could see examples of that? Thanks, Al

Re: Stop Using Mapscript: Almost There

Author: Sean

Al, you can use the mapfile language to define an OGR wrapper for your MySQL table. Google for "mapserver ogr virtual mysql" and you'll find examples.

MapServer Subversion Repository

Sean Gillies — Sun, 29 Apr 2007 06:00:00 GMT

MapServer users: you all owe Howard a beer.

Upcoming Events

Sean Gillies — Wed, 18 Apr 2007 06:00:00 GMT

Front Range Pythoneers: OLPC (!) and testing, 18 April.

FRUGOS: MapServer and OpenLayers class at CU-Denver, 25 April.

Improving MapServer: a Specific Example

Sean Gillies — Tue, 27 Mar 2007 06:00:00 GMT

Earlier this month I made some hand-waving arguments for separating the concerns of MapServer's web application and cartographic engine on general principles. There is now a new MapServer development proposal that allows me to make a specific example.

It's been proposed that the MapServer web app could generate vanilla XML responses to GetFeature, GetFeatureInfo, and other WxS requests, and user-configured XSLT would provide a finishing touch to the responses. It's a nice idea. The early implementation plan was to load up existing configuration parameters with additional meaning. Stylesheet as metadata or something like that. Actually, specification of a XSLT stylesheet for transforming WxS responses has nothing to do with cartography, and nothing to do with map or layer metadata. It is solely a concern of mapserv, the web application. Therefore, let's configure it separately from the Map section of a mapfile. Transformation of a WFS GetFeature response might be done like this:

# The traditional cartographic config section
Map
  # All the usual map layers, etc.
  ...
End

# *NEW* application config section
Application
WFS
  GetFeature
    XSLT       On
    Stylesheet "/mapserver/xslt/example.xsl"
  End
End

That's declarative, orthogonal, and crystal clear.

Suggestion for MapServer 5.0

Sean Gillies — Thu, 01 Mar 2007 07:00:00 GMT

The MapServer 5.0 plan has some compelling items (feature-level transparency, AGG rendering in particular), but the one thing I'd really like to see is separation of MapServer's cartographic and web application aspects. These are entangled both in the code and in configuration, so it's no small task, but one that would reward the community.

Frankly, making effective maps and administering a web server are skills that rarely go together. Separating cartography from the web application allows changes to be made to the cartographic presentation with greatly reduced risk of breaking the application that serves up the map. The separation would also make it easier to test and deploy maps, even across platforms.

Similarly, separating these concerns would make development of MapServer a bit more sane. Cartographic enhancements would be much less likely to break the web application, and the upcoming changes to accommodate WFS 1.1 and WMS 1.3 (for example) would be much less likely to break the cartographic engine.

Last, but not least: I consider the built-in MapServer web application (mapserv, or mapserv.exe) to be cumbersome, and a bad investment today. The W*S protocols are better implemented in your favorite web programming language. PHP, Python, Ruby, .NET -- all surpass C for working with HTTP requests, strings, and XML. All have better templating. All have better memory management (except perhaps PHP). Back when I was playing ultimate frisbee, we used to heckle our teammates, yelling "Drop the piano!" at the tired guy who couldn't run down the disc. MapServer's built-in, written in C, web application is that piano.

Comments

Re: Suggestion for MapServer 5.0

Author: Matthew Giger

I agree wholeheartedly with your assessment. Having another application to serve up http data outside of apache in this day and age is just silly. Agg is very nice at rendering antialiased lines (MS uses it in VE), I would love to see some sort of a Python MapServer library (with the crucial performance parts in C) with a Mapnik (mapnik.org which also uses Agg) renderer and OpenLayers. That would be a nice solution...

Re: Suggestion for MapServer 5.0

Author: hobu

Patches graciously accepted :)

Re: Suggestion for MapServer 5.0

Author: Sean

I'm still a committer, Howard. Consider this post a paradigm patch for the brain ;)

Re: Suggestion for MapServer 5.0

Author: Andy

I have to disagree on the mapserv thing. I wrote an app for small devices for AT&T at one time that used mapserv and it worked like gang busters. When you have a device side application and you just need images streamed to it and the app itself handles everything else mapserv is the absolute bomb. The Oregon & Washington market AT&T technicians still use this app on their Blackberries and Motorola radio phones. Without mapserv I would have been up a creek. For regular web maps I always used the PHP libraries but for small devices nothing worked better than mapserv.

MAGIS: Mediterranean Archaeology GIS

Sean Gillies — Tue, 06 Feb 2007 07:00:00 GMT

Slowly, but surely, I'm catching up on the other Web and GIS projects in the Digital Humanities. One of these is the Collaboratory for GIS and Mediterranean Archaeology's MAGIS, which provides simple MapServer-based map search for archaeological projects.