antialiasing stuff

Paul Spencer pspencer at DMSOLUTIONS.CA
Mon Apr 3 15:55:02 EDT 2006


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