<html>
<head>
<style type="text/css">
<!--
body { margin-right: 4px; margin-bottom: 1px; margin-left: 4px; line-height: normal; margin-top: 4px; font-variant: normal }
p { margin-bottom: 0; margin-top: 0 }
-->
</style>
</head>
<body style="margin-right: 4px; margin-bottom: 1px; margin-left: 4px; margin-top: 4px">
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">All,</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">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.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">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.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">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?</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">While thinking this through further (since yesterday) am I describing something that is different enough that it shouldn't be included in this thread?</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org> wrote:<br> </p>
<div style="margin-right: 0; background-color: #f3f3f3; margin-bottom: 0; margin-left: 15px; border-left: solid 1px #050505; margin-top: 0; padding-left: 7px">
<p style="margin-bottom: 0; margin-top: 0">
Landon Blake wrote:<br>> Bob,<br>><br>> I'm not a web developer by any stretch of the term, so I 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 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 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 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 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 kind of output<br>would be expected (e.g. PDF, PS, SVG, etc).  Then I export the new print<br>configuration files in our specification using a plugin.  The plugin<br>will then run the engine with those configuration files as arguments to<br>the engine and spit out a file.  Maybe it prompts the 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 files and<br>then push back the output map file.  Sounds like Web Processing Server<br>(WPS) spec could handle this is a general sense.  There are no OGC web<br>based printing standards that I've heard of - if someone knows of them,<br>please point them out.  It's basically that stuff we want to create I think.<br><br><br>Styles<br>-------<br>We all have/use apps that deal with layers and styles, though they all<br>describe it a bit differently.  The goal of having a spec would not be<br>to change the way another app does their styling, but rather to 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 some cases,<br>like web mapping, layout for printing is a bit off-topic even.  Still,<br>having a specification to define how a map will appear is a key part of<br>this project.  Of course, at the basest level you are just passing a map<br>image that covers a whole page.  At the more complex you're dealing with<br>graticules and classified legends, etc.<br><br>Printing<br>--------<br>This third spec defines how the output dimensions, resolution and file<br>formats to be used to create.<br><br>My push this year is to have people check out the Mapnik specifications.<br>It has an xml-based configuration system for defining styles and a bit<br>of layout.  It also has a way to define output specs, though I haven't<br>dug into that.  Initially important to me is that it supports the Cairo<br>library for rendering into vector-based output formats (PS, PDF, 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 starting<br>to look at Cairo and there are other libraries likely available.  I can<br>appreciate all that, but think we should seriously look at Mapnik's XML<br>config file structure.  Then we adopt it as the spec for this project<br>and then *any* other application that wants to serve as an engine, must<br>meet that spec (either directly writing to it, or transforming 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 apps :)<br><br>Make sense?  Hope that helps!<br>Tyler<br>_______________________________________________<br>Carto mailing list<br>Carto@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/carto">http://lists.osgeo.org/mailman/listinfo/carto</a><br>
</p>
</div>
</body>
</html>