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

[Tyler Mitchell]

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

Hi Bob, yes I think you're a bit ahead of us :)  Most of are still not happy with printing options in our app - hehe.  But that doesn't mean it shouldn't be a thread here!  I have seen some work on style editors before when I used to put up web mapping sites - Paul might have a few good pointers on that?

----- Original Message -----
From: Bob Basques <Bob.Basques at ci.stpaul.mn.us>
Date: Wednesday, April 7, 2010 6:56 am
Subject: Re: [Carto] Students: Get Paid to work on this project (isthisstillthe thread about high resolution printing??)
To: Landon Blake <lblake at ksninc.com>, "Tyler Mitchell (OSGeo)" <tmitchell at osgeo.org>
Cc: carto at lists.osgeo.org

> 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 
> startingto 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/3287ccf4/attachment.html