antialiasing stuff
Steve Lime
Steve.Lime at DNR.STATE.MN.US
Mon Apr 10 13:09:42 EDT 2006
I'll address exposure in 4.9 but have not had the time yet...
Steve
>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 4/3/2006 2:55 PM >>>
Bart,
afaik it has not been exposed and the only workaround is to modify
the source to hardcode a new value :(
Paul
On 3-Apr-06, at 1:18 PM, Bart van den Eijnden (OSGIS) wrote:
> Guys,
>
> did the hardness parameter ever get exposed to the MAP file?
>
> If not, is there a workaround? Thanks.
>
> Best regards,
> Bart
>
> Daniel Morissette wrote:
>
>> After seeing how you had to tune the hardness value in order to
>> get the best possible looking maps, I agree that just soft and
>> hard might not be enough, especially when at the lower level the
>> range of valid values is much larger than that.
>>
>> My main concern would be to not break backwards compatibility with
>> older mapfiles (even if antialias never really worked before).
>> We'd have to make sure that ANTIALIAS TRUE/FALSE are still
>> supported by the parser, with some acceptable default for the TRUE
>> case.
>>
>> BTW, isn't the internal hardness value a float in the 0.0-1.0
>> range? If that's the case then that's what we should offer in the
>> mapfile too.
>>
>> Daniel
>>
>>
>> Paul Spencer wrote:
>>
>>> That seems to go against other aspects of mapserver's design
>>> where full control is provided at the expense of some
>>> complexity. Whatever gets picked will never be quite right for
>>> some people. I think the extra complexity can be adequately
>>> controlled by documenting reasonable values for 'soft',
>>> 'medium', and 'hard' and what the effect is on the output.
>>>
>>>
>>> Cheers
>>>
>>> Paul
>>>
>>> On 14-Jan-06, at 11:15 AM, Sean Gillies wrote:
>>>
>>>> IMO, that's more control than people need. How about a few
>>>> flavors of antialiasing like "soft" and "hard".
>>>>
>>>> Sean
>>>>
>>>> On Jan 14, 2006, at 8:56 AM, Paul Spencer wrote:
>>>>
>>>>> Would it make sense to change the meaning of the antialias tag
>>>>> in the
>>>>> style and change it to a 0-100 value instead of a true/false?
>>>>> If you
>>>>> don't want to antialias a layer, then you wouldn't put ANTIALIAS
>>>>> FALSE, you'd just remove it altogether. So in the case of using
>>>>> antialias as an integer value, it would make sense.
>>>>>
>>>>> Paul
>>>>>
>>>>> On 13-Jan-06, at 4:38 PM, Yewondwossen Assefa wrote:
>>>>>
>>>>>> I have not seen an equivalent term in the sld specs.
>>>>>>
>>>>>> Steve Lime wrote:
>>>>>>
>>>>>>> I think in the next version we could expose the hardness setting
>>>>>>> to mapfile
>>>>>>> tweaking... What's the equivalent terminiology in something
>>>>>>> like SLD?
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>
>>>>>>>>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 01/13/06 2:43 PM >>>
>>>>>>>>>>
>>>>>>> cool, thanks :) I hadn't tried it, thought I would ask first.
>>>>>>> I've managed to achieve almost the desired effect by jacking
>>>>>>> the
>>>>>>> hardness to 0.95 and fixing the gd bug for 1 pixel lines
>>>>>>> since I
>>>>>>> asked so maybe we won't end up going this route.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> PS: any chance of having a HARDNESS keyword at the style level?
>>>>>>>
>>>>>>> On 13-Jan-06, at 2:55 PM, Steve Lime wrote:
>>>>>>>
>>>>>>>
>>>>>>>> This should be doable "as is". Just set TRANSPARENCY ALPHA
>>>>>>>> and point
>>>>>>>> to the right image in your style or symbol definition. All the
>>>>>>>> fuzzy brush
>>>>>>>> support does is do this programatically.
>>>>>>>>
>>>>>>>> I believe I've tested this before using an image or two that
>>>>>>>> Sean had created
>>>>>>>> while fixing another bug.
>>>>>>>>
>>>>>>>> Have you tried it and it doesn't work?
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> Paul Spencer <pspencer at DMSOLUTIONS.CA> 01/13/06 12:59 PM >>>
>>>>>>>>>>>
>>>>>>>> Steve,
>>>>>>>>
>>>>>>>> what would it take to support rendering lines with custom
>>>>>>>> symbols
>>>>>>>> that have alpha transparency in them? We would like to be
>>>>>>>> able to
>>>>>>>> make our own brushes that work in the same way that fuzzy
>>>>>>>> brushes
>>>>>>>> work, but we pre-render them and access them as symbols.
>>>>>>>> This would
>>>>>>>> allow finer control over styling without having to tweak
>>>>>>>> mapserver
>>>>>>>> code to get the desired effect :)
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>
>>>
>>> +-----------------------------------------------------------------+
>>> |Paul Spencer pspencer at dmsolutions.ca |
>>> +-----------------------------------------------------------------+
>>> |Applications & Software Development |
>>> |DM Solutions Group Inc http://www.dmsolutions.ca/|
>>> +-----------------------------------------------------------------+
>>>
>>
>>
>
>
> --
> Bart van den Eijnden
> OSGIS, Open Source GIS
> http://www.osgis.nl
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Applications & Software Development |
|DM Solutions Group Inc http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+
More information about the mapserver-dev
mailing list