<DIV>> While thinking this through further (since yesterday) am I <BR>> describing something that is different enough that it shouldn't <BR>> be included in this thread? <BR></DIV>
<DIV>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?<BR><BR>----- Original Message -----<BR>From: Bob Basques <Bob.Basques@ci.stpaul.mn.us><BR>Date: Wednesday, April 7, 2010 6:56 am<BR>Subject: Re: [Carto] Students: Get Paid to work on this project (isthisstillthe thread about high resolution printing??)<BR>To: Landon Blake <lblake@ksninc.com>, "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org><BR>Cc: carto@lists.osgeo.org<BR><BR>> All, <BR>> <BR>> Most projects have some sort of printing capability already, I'm <BR>> not too interested in rebuilding this type of functionality, but <BR>> rather in building out a much more functional print service that <BR>> goes beyond just printing maps, and enables typesetting <BR>> functionality as well, even adding in other elements like charts <BR>> and fancy legends, map details, etc. <BR>> <BR>> One additional item that I'm interested in is being able to do <BR>> is to mix and match sources for the data elements for the final <BR>> output. This is mostly my reasoning for not trying <BR>> to build something that is app specific up front. I <BR>> want to be able to use the new spec to combine things from <BR>> different applications (desktop and web based) into a <BR>> output stream. I think going after the web approach <BR>> up front gets things to the app agnostic level the soonest. <BR>> <BR>> The pieces of such an app are still sort of swirling around in <BR>> my head at the moment. But one big function I've thought <BR>> would be good in this type of application would be to build out <BR>> a style manager (and possibly a data manager) in front of <BR>> something like MapServer. Based on the comments so far though, <BR>> seems like most folks have their favorite application that they <BR>> want to see added on to instead, or am I reading too far between <BR>> the lines? <BR>> <BR>> While thinking this through further (since yesterday) am I <BR>> describing something that is different enough that it shouldn't <BR>> be included in this thread? <BR>> <BR>> bobb <BR>> <BR>> <BR>> >>> "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org> wrote:<BR>> <BR>> Landon Blake wrote:<BR>> > Bob,<BR>> ><BR>> > I'm not a web developer by any stretch of the term, so I <BR>> didn't get<BR>> > everything in your message. I did however like the concept of a<BR>> > canvas where the user can assemble common layout elements. This<BR>> > sounds like a way to make map layout a no brainer. Whether this<BR>> > component of the map-making project was on the web or in a desktop<BR>> > app, I like it!<BR>> <BR>> All good ideas...<BR>> <BR>> I think the biggest bang for the buck is to set up an engine in <BR>> a way<BR>> that makes it easiest for as many other appliations (desktop, or web<BR>> enabled) to easily push their configuration over and spit out a <BR>> map file<BR>> (e.g. at simplest level a postscript file that a plotter can print).<BR>> It's the specifications that will make it have the best possible<BR>> broadest application. Desktop, server, or web are <BR>> implementation issues<BR>> in my opinion.<BR>> <BR>> Here's the typical workflow I'm envisioning, at a technical level.<BR>> <BR>> Scenario 1<BR>> -----------<BR>> I'll use a desktop app as an example. I open up my files <BR>> in my desktop<BR>> GIS, set my layer styles, mock up a quick layout (if the app supports<BR>> that). There would need to be a way of specifying what <BR>> kind of output<BR>> would be expected (e.g. PDF, PS, SVG, etc). Then I export <BR>> the new print<BR>> configuration files in our specification using a plugin. <BR>> The plugin<BR>> will then run the engine with those configuration files as <BR>> arguments to<BR>> the engine and spit out a file. Maybe it prompts the <BR>> operating system<BR>> to launch it a viewer app like kpdf, etc.<BR>> <BR>> This is a similar approach to how Quantumnik works already!<BR>> <BR>> Scenario 2<BR>> -----------<BR>> I'll have a command line script that'll take a MapServer configuration<BR>> file or even a QGIS file and transform it into the output map specs.<BR>> Then I'd also point to a layout and print spec config file and the<BR>> script passes it off to the engine and the output is produced.<BR>> <BR>> Scenario 3<BR>> -----------<BR>> Web services could receive the config files, pointers to data <BR>> files and<BR>> then push back the output map file. Sounds like Web <BR>> Processing Server<BR>> (WPS) spec could handle this is a general sense. There are <BR>> no OGC web<BR>> based printing standards that I've heard of - if someone knows <BR>> of them,<BR>> please point them out. It's basically that stuff we want <BR>> to create I think.<BR>> <BR>> <BR>> Styles<BR>> -------<BR>> We all have/use apps that deal with layers and styles, though <BR>> they all<BR>> describe it a bit differently. The goal of having a spec <BR>> would not be<BR>> to change the way another app does their styling, but rather to <BR>> make it<BR>> possible to transform a project file into the specification instead.<BR>> <BR>> Layout<BR>> -------<BR>> Many apps really suffer with not having a layout app. In <BR>> some cases,<BR>> like web mapping, layout for printing is a bit off-topic <BR>> even. Still,<BR>> having a specification to define how a map will appear is a key <BR>> part of<BR>> this project. Of course, at the basest level you are just <BR>> passing a map<BR>> image that covers a whole page. At the more complex you're <BR>> dealing with<BR>> graticules and classified legends, etc.<BR>> <BR>> Printing<BR>> --------<BR>> This third spec defines how the output dimensions, resolution <BR>> and file<BR>> formats to be used to create.<BR>> <BR>> My push this year is to have people check out the Mapnik <BR>> specifications.It has an xml-based configuration system for <BR>> defining styles and a bit<BR>> of layout. It also has a way to define output specs, <BR>> though I haven't<BR>> dug into that. Initially important to me is that it <BR>> supports the Cairo<BR>> library for rendering into vector-based output formats (PS, PDF, <BR>> etc) -<BR>> a simple raster output wouldn't meet the specs of this project.<BR>> <BR>> Things change of course and I know MapServer (and others!) are <BR>> startingto look at Cairo and there are other libraries likely <BR>> available. I can<BR>> appreciate all that, but think we should seriously look at <BR>> Mapnik's XML<BR>> config file structure. Then we adopt it as the spec for <BR>> this project<BR>> and then *any* other application that wants to serve as an <BR>> engine, must<BR>> meet that spec (either directly writing to it, or transforming <BR>> their own<BR>> config files).<BR>> <BR>> We'd have to extend it to include the additional requirements of our<BR>> project, but I'm not 100% sure where the holes are.<BR>> <BR>> For what it's worth, I'm sticking with Python myself, but if we really<BR>> stick with XML configuration specs for the short term, then it won't<BR>> matter since we can all implement the concepts in our favourite <BR>> apps :)<BR>> <BR>> Make sense? Hope that helps!<BR>> Tyler<BR>> _______________________________________________<BR>> Carto mailing list<BR>> Carto@lists.osgeo.org<BR>> http://lists.osgeo.org/mailman/listinfo/carto<BR>> <BR>> </DIV>