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

[Bob Basques]

All, 

Most projects have some sort of printing capability already, I'm not too interested in rebuilding this type of functionality, but rather in building out a much more functional print service that goes beyond just printing maps, and enables typesetting functionality as well, even adding in other elements like charts and fancy legends, map details, etc. 

One additional item that I'm interested in is being able to do is to mix and match sources for the data elements for the final output.   This is mostly my reasoning for not trying to build something that is app specific up front.   I want to be able to use the new spec to combine things from different applications (desktop and web based)  into a output stream.   I think going after the web approach up front gets things to the app agnostic level the soonest. 

The pieces of such an app are still sort of swirling around in my head at the moment.  But one big function I've thought would be good in this type of application would be to build out a style manager (and possibly a data manager) in front of something like MapServer. Based on the comments so far though, seems like most folks have their favorite application that they want to see added on to instead, or am I reading too far between the lines? 

While thinking this through further (since yesterday) am I describing something that is different enough that it shouldn't be included in this thread? 

bobb 


>>> "Tyler Mitchell (OSGeo)" <tmitchell at osgeo.org> wrote:

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
_______________________________________________
Carto mailing list
Carto at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/carto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/carto/attachments/20100407/28f4cc2b/attachment.html