<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bent,<br>
<br>
See inline . . .<br>
<br>
Brent Fraser wrote:
<blockquote cite="mid:.68.144.5.189.1206125130.squirrel@68.144.5.189"
type="cite">
<pre wrap="">Bob,
</pre>
<blockquote type="cite">
<pre wrap=""> Makes it into one of those jobs that tends to
fall between the cracks.
</pre>
</blockquote>
<pre wrap=""><!---->
Cool! I hadn't considered a tiled approach mostly due to potential
label/symbol match-up issues on the tile edges.
</pre>
</blockquote>
Actaully, since GeoMoose is abstracted by layers, we've approached the
printing in the same way, so the labels can be printed as a single tile
on top of the BASE layers which could be tiled. Doesn't help in all
situations, but it let you know we've done some extensive testing on
this to date, even if we don't yet have much to show for it.<br>
<br>
Even using the tiled approach, the server side load is quite a bit of
work, although you don't have to send all the tiles down to the client,
they are all assembled on the server into a PDF.<br>
<blockquote cite="mid:.68.144.5.189.1206125130.squirrel@68.144.5.189"
type="cite">
<blockquote type="cite">
<pre wrap=""> Think about the outside
labeling being formatted as a table, with separate images being created
around the edges of the map.
</pre>
</blockquote>
<pre wrap=""><!---->
No more of an impact than the current method of asking for a map AND a
reference map AND a scale bar. My concern would be making sure the labels
match the grid lines, and the implementer having to craft up the html
carefully, but not a big issue. </pre>
</blockquote>
I think a standard table would work in just about all cases. Some
interesting things though, would be the ability to do multiple striping
and such, no need to settle for a single edge label. One could even
stack them on top of each other with MapFile includes, which we've also
taken to heart on the server side.<br>
<blockquote cite="mid:.68.144.5.189.1206125130.squirrel@68.144.5.189"
type="cite">
<pre wrap=""> And that method would take care of the
bounding box query issue I thought of (if the user's selection box extends
into the non-mapped margin, the query results might not be what's
expected). A very interesting solution; I'll have to give that some
thought...
</pre>
</blockquote>
As long as the MAPEXTs of the original map are tracked, the neighboring
tiles should line up ok. I'm sure there are some instances where this
may be a problem though.<br>
<blockquote cite="mid:.68.144.5.189.1206125130.squirrel@68.144.5.189"
type="cite">
<blockquote type="cite">
<pre wrap="">Seems like a lot of extra work though for the client side to keep track
of, but this may be a valid piece for printing/layout tasks.
Hmmm, taking this a step further, what about sending to the print layout
client the labels as SVG, with an ID and placement in pixels, they could
be moved around in the client individually (or grouped) and sent back to
the server for PDF building. Again, maybe this is left until later in
the development cycles, but you see the control you can end up with
here. Still pondering . . . .
</pre>
</blockquote>
<pre wrap=""><!---->
For the plot layout solution I was thinking of PDF instead of SVG, and
leveraging Inkscape, Scribus, etc for the interactive editing part. So
the last couple of days I've been experimenting with having Mapserver
generate PDF output with a GRID layer. "Interesting" results: some
crashing depending on how the GRID layer is set up...
</pre>
</blockquote>
Hmm, interesting approach. Where are you running into problems with
this approach? Seems like there could be some non-standard types of
object possible for the editors for one. Does MapServer do the labels
in PDF as all separate pieces/elements? Got anything online to play
with?<br>
<br>
One thing I forgot to mention, was that I se this Printing (client
side) layout canvas, as being populated with any URL type of call, not
just mapping based. I may be reaching for the stars though on that
one, but it would be easy enough to work with raster images to begin
with.<br>
<br>
One other thought in the back of my head is related to 3D data, while
we've only experimented with output to date, we can export chunks of
the City as X3D data for example, this type of approach you've
outlined, my be related to 3D editing and viewing as well.<br>
<br>
You seem to be up on these packages, can they be scripted in any way
for retrieval from the web? Or is that a two step process? Do these
packages blow up with big files?<br>
<br>
Your ideas using these packages seems very interesting, but I'm
wondering about the import limits that they might impose. Seems to be
a fair amount of learning curve to both packages, do you have a
preference yet? I did find that Scribus can be scripted with Python,
not commandline though . . .<br>
<br>
I hop you're happy, now you got me thinking about all sorts of new
stuff, like how to teach folks about using a standalone package like
this, I hate installing standalone stuff for exactly this reason if I
can avoid it.<br>
<br>
bobb<br>
<br>
<blockquote cite="mid:.68.144.5.189.1206125130.squirrel@68.144.5.189"
type="cite">
<pre wrap="">Brent
</pre>
</blockquote>
</body>
</html>