[mapserver-dev] Need mapfile for AGG and Transparent overlay

[Thomas Bonfort]

Steve,

I'm taking note of your request. The aim of the rendering api overhaul
is exactly that: getting consistent output throughout the renderers
without it being a pain to maintain on the development side.
On a side note, I wonder why you're getting lousy quality output when
overlaying over satellite images (as if you look at G's overlays, you
can get antialiased features that show up nicely over a photo). I'm
suspecting that there are too many colors in your different road
classes, which means that the limited palette available when using
transparency ( we are reducing the 4 294 967 296 possible colors
available to 256 ) isn't sufficient to get quality output.
* Can you confirm that the rendering is ok if you don't use
quantization (i.e plain 32bit rgba)
* I'd also investigate in using a less broad color spectrum for a
mapfile that will be used for transparent overlays (at least for the
layers that will be rendered that way. if you look at G's overlays,
you'll see they are doing exactly that)

regards,

thomas


www.camptocamp.com
+33 5 16 57 01 02



On Thu, Nov 5, 2009 at 15:23, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> Thomas,
>
> When I display the the map as the base map I want antialiasing on so the map
> looks smooth. But for a transparent overlay, I do not want antialiasing on
> because it creates lots of artifacts along the edges of lines in a
> transparent image.
>
> What I have done in the past is create two mapfiles one for AGG that is
> antialiased and another that I run through GD that does not have
> antialiasing in it. This is a lot of extra work.
>
> The reason I have been doing this is that the GD renderer does(did?) not not
> understand things like WIDTH, you had to use a SYMBOL and SIZE to stroke the
> roads.
>
> Maybe I've had my head too buried in projects to notice that things have
> changed in which case I would be happy to be enlightened :) otherwise my
> request is that we try to drive the renderers to support a common mapfile
> language/behavior and/or to the extent that they support it allow
> transparency/antialiasing to be switched on/off.
>
> My goal is to get this into your thinking and planning, because I realize it
> is likely not a small task, but I think it would have high value to users if
> they can trivially switch between antialiased maps to transparent overlays
> using the same mapfile and change a few parameters and layers on/off.
>
> Thanks,
>  -Steve W
>
> Thomas Bonfort wrote:
>>
>> Steve,
>> Why would you want aliased output?
>> Why isn't RGBA+quantization sufficient in your case?
>>
>> best regards,
>> thomas
>>
>> www.camptocamp.com
>> +33 5 16 57 01 02
>>
>>
>>
>> On Wed, Nov 4, 2009 at 22:20, Stephen Woodbridge
>> <woodbri at swoodbridge.com> wrote:
>>>
>>> Thomas,
>>>
>>> I think this is mostly directed at you. I have been using your sample OSM
>>> mapfile and it is really great - Thanks for putting this together.
>>>
>>> It raises an issue that I think needs to be dealt with, but maybe I'm
>>> missing some feature that is already implemented.
>>>
>>> My use case is that I need a single mapfile that I can use for
>>> antialiased
>>> rendering like your file above, but I also need to generate transparent
>>> overlay images of just the road network by selecting just those layers or
>>> group. For example, in Openlayers, I need to have google like controls
>>> for
>>> [map][hybrid][etc] where the [map] view is like above and the hybrid view
>>> is
>>> satellite imagery as an OL layer and transparent road network overlay in
>>> OL.
>>>
>>> So it would be nice if we can use a single mapfile to do both.
>>>
>>> In OL, I would set the overlay layer to be:
>>>  imagetype: 'png',
>>>  transparency: 'on',
>>>  antialias: 'off',
>>>  ...
>>>
>>> or whatever and then the mapfile would be interpreted correctly for
>>> generating a non-antialiased transparent image.
>>>
>>> Questions:
>>>
>>> 1. Can this be done now? or do I need to build a separate mapfile for
>>> these
>>> two tasks?
>>>
>>> 2. Does this sound like a reasonable goal? Achievable in 6.0?
>>>
>>> 3. There were some posts that hinted that you might be trying to obsolete
>>> the gd rendering code, which I do not have a problem with. How would this
>>> impact this issue?
>>>
>>> I hope this all makes sense.
>>>
>>> Thanks,
>>>  -Steve W
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>
>