[Carto] Students: Get Paid to work on this project (isthisstill the thread about high resolution printing??)

[Tyler Mitchell (OSGeo)]

Landon Blake wrote:
> Bob,
> 
> I'm not a web developer by any stretch of the term, so I didn't get
> everything in your message. I did however like the concept of a
> canvas where the user can assemble common layout elements. This
> sounds like a way to make map layout a no brainer. Whether this
> component of the map-making project was on the web or in a desktop
> app, I like it!

All good ideas...

I think the biggest bang for the buck is to set up an engine in a way
that makes it easiest for as many other appliations (desktop, or web
enabled) to easily push their configuration over and spit out a map file
(e.g. at simplest level a postscript file that a plotter can print).
It's the specifications that will make it have the best possible
broadest application.  Desktop, server, or web are implementation issues
in my opinion.

Here's the typical workflow I'm envisioning, at a technical level.

Scenario 1
-----------
I'll use a desktop app as an example.  I open up my files in my desktop
GIS, set my layer styles, mock up a quick layout (if the app supports
that).  There would need to be a way of specifying what kind of output
would be expected (e.g. PDF, PS, SVG, etc).  Then I export the new print
configuration files in our specification using a plugin.  The plugin
will then run the engine with those configuration files as arguments to
the engine and spit out a file.  Maybe it prompts the operating system
to launch it a viewer app like kpdf, etc.

This is a similar approach to how Quantumnik works already!

Scenario 2
-----------
I'll have a command line script that'll take a MapServer configuration
file or even a QGIS file and transform it into the output map specs.
Then I'd also point to a layout and print spec config file and the
script passes it off to the engine and the output is produced.

Scenario 3
-----------
Web services could receive the config files, pointers to data files and
then push back the output map file.  Sounds like Web Processing Server
(WPS) spec could handle this is a general sense.  There are no OGC web
based printing standards that I've heard of - if someone knows of them,
please point them out.  It's basically that stuff we want to create I think.


Styles
-------
We all have/use apps that deal with layers and styles, though they all
describe it a bit differently.  The goal of having a spec would not be
to change the way another app does their styling, but rather to make it
possible to transform a project file into the specification instead.

Layout
-------
Many apps really suffer with not having a layout app.  In some cases,
like web mapping, layout for printing is a bit off-topic even.  Still,
having a specification to define how a map will appear is a key part of
this project.  Of course, at the basest level you are just passing a map
image that covers a whole page.  At the more complex you're dealing with
graticules and classified legends, etc.

Printing
--------
This third spec defines how the output dimensions, resolution and file
formats to be used to create.

My push this year is to have people check out the Mapnik specifications.
 It has an xml-based configuration system for defining styles and a bit
of layout.  It also has a way to define output specs, though I haven't
dug into that.  Initially important to me is that it supports the Cairo
library for rendering into vector-based output formats (PS, PDF, etc) -
a simple raster output wouldn't meet the specs of this project.

Things change of course and I know MapServer (and others!) are starting
to look at Cairo and there are other libraries likely available.  I can
appreciate all that, but think we should seriously look at Mapnik's XML
config file structure.  Then we adopt it as the spec for this project
and then *any* other application that wants to serve as an engine, must
meet that spec (either directly writing to it, or transforming their own
config files).

We'd have to extend it to include the additional requirements of our
project, but I'm not 100% sure where the holes are.

For what it's worth, I'm sticking with Python myself, but if we really
stick with XML configuration specs for the short term, then it won't
matter since we can all implement the concepts in our favourite apps :)

Make sense?  Hope that helps!
Tyler