<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">Well, basically, I've always thought along the lines of a Web app (engine) for the processing. I'm a bit biased in this regard, but it shouldn't preclude building out a standalone version of some sort of engine either.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">Anyway on to the ideas.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">My thought was to use a print canvas sort of approach, where an online interface was used to assemble a print layout (could this be the specification side of the conversation so far) and send that to the engine for printing. The reason I think this user interface is important is more for the sales side of things, but I'm a big proponent of usability, and push/drag system on a web based whiteborad sort of interface seems like the right way to go.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">Using a URL based (raster images would be a good start) approach to collecting print elements seems like a no brainer, where a separate web based engine could handle URL collection duties for display in the Print canvas, and the user has all the tools needed in the interface to push, drag, scale, etc, and in a visual form. Using the Print Canvas approarch will allow for a very strict method of pushing the elements to the rendering engine as well. It will act as a sort of pre-rendering filter of sorts.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">It may sound like I'm trying to jump to the end before doing the middle, but I've been thinking about this a for a few years and even did some early concept work once upon a time.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">The bigger benefit I see to this approach (and still keeping inside of the ideas discussed) is that things can be implemented in phases, raster first, vector (3D??), and the input and rendering are completely separated with regard to development streams. If a project want to use the print canvas engine to render directly, they can, or let the users interact with the layout instead, either will work just fine.</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">I don't believe that this things need to get hung up on the specification side too much either, most elements would/could be collected via a URL resource for example, and already be in some sort of standard form. The new stuff for layout, can be integrated into this new print canvas / render engine and stay project specific, right?</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">So, am I rambling, or does any of this make sense?</font> </p>
<br>
<p style="margin-bottom: 0; margin-top: 0">
<font size="3" face="Comic Sans MS">bobb</font> </p>
<br> <br>
<p style="margin-bottom: 0; margin-top: 0">
<br>
<br>
>>> "Landon Blake" <lblake@ksninc.com> 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">
I shared my ideas Bob. Let's hear about your approach.<br><br>Landon<br>Office Phone Number: (209) 946-0268<br>Cell Phone Number: (209) 992-0658<br><br><br>________________________________________<br>From: carto-bounces@lists.osgeo.org [mailto:carto-bounces@lists.osgeo.org] On Behalf Of Bob Basques<br>Sent: Tuesday, April 06, 2010 11:24 AM<br>To: Dane Springmeyer; Tyler Mitchell (OSGeo)<br>Cc: carto@lists.osgeo.org<br>Subject: Re: [Carto] Students: Get Paid to work on this project (isthis still the thread about high resolution printing??)<br><br>All,<br><br>Is this still the thread about high resolution printing?<br><br>If so, I have a different approach that might be worth offering. . . .<br><br>bobb<br><br><br><br>>>> "Tyler Mitchell (OSGeo)" <tmitchell@osgeo.org> wrote:<br>Dane Springmeyer wrote:<br>> Because there is not a third student focusing on the OSGEO side I think<br>> was is not being addressed is the interoperability/standards<br>> specification piece. Big picture this is likely better addressed outside<br>> of a code-based GSOC project and rather by the wider community.<br><br>I think you're hitting the nail on the head here.  With my "user of<br>several apps" hat on, I mainly care about the specifications side of<br>things.  Knowing that any "engine" app is already going to be focused on<br>improving quality, features, etc. the question from a larger, OSGeo<br>ecosystem perspective does really fall into the standards doesn't it?<br><br>What I would like to avoid is inventing a new spec, only to find that<br>another app already has a well thought out model in place.  I'd much<br>rather clone an existing model, API, whatever and then see what is<br>missing from our overall needs.  I'm most familiar with MapServer's<br>model, but was able to get a good glimpse into Mapnik when playing with<br>Quantumnik.  That kind of interoperability in a client app is quite<br>encouraging to see.<br><br>In the end, I'd like to take Application X and transform its config<br>files into the engine's model.  Thereby making this project also a bit<br>of a universal translator.. but I think I'm getting ahead of myself. :)<br><br>So, how do we get a good handle on potential specs to work from?  I<br>broke it down into three components:<br>* rendering stuff<br>* map layout details<br>* output formats/resolution etc.<br><br><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><br><br>Warning:<br>Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.<br>
</p>
</div>
</body>
</html>