[mapserver-users] GRID labeling, OK, where are the MapServerGRID guru's??

[Bob Basques]

Bent,

See inline . . .

Brent Fraser wrote:
> Bob,
>   
>>   Makes it into one of those jobs that tends to
>> fall between the cracks.
>>     
>
> Cool! I hadn't considered a tiled approach mostly due to potential
> label/symbol match-up issues on the tile edges.
>   
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.

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.
>>   Think about the outside
>> labeling  being formatted as a table, with separate images being created
>> around the edges of the map.
>>     
>
> 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. 
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.
>  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...
>   
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.
>> 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 . . . .
>>     
>
> 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...
>   
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?

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.

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.

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?

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 . . .

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.

bobb

> Brent
>
>
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20080323/02f0dcb5/attachment.htm>