[mapserver-dev] RFC 89 Layer Geomtransform: Call for vote

[Alan Boudreault]

Thanks Daniel for the good summary. I agree with all your points and 
will finish my implementation this way. I'm also going to update the RFC.

Alan

On 02/20/2013 11:38 PM, Stephen Woodbridge wrote:
> On 2/20/2013 11:18 PM, Daniel Morissette wrote:
>> Hi Steve,
>>
>> Is it possible that you are missing SIZEUNITS and UNITS?
>>
>> The WIDTH of your lines is specified in SIZEUNITS, and OTOH the UNITS
>> param I was alluding to is used to indicate the units of the source
>> data. The doc says that it is currently used only for inline features
>> (is this true?), but with this RFC it would become more widely used.
>>
>
> Yes, my bad, Sorry. I think you have addressed all the issue. Thanks 
> for all the work you and Alan have done on this.
>
> -Steve W
>
>> On 13-02-20 11:09 PM, Stephen Woodbridge wrote:
>>> On 2/20/2013 10:11 PM, Daniel Morissette wrote:
>>>> On 13-02-20 1:36 PM, Alan Boudreault wrote:
>>>>> Initially, that's what I wanted to avoid: adding new
>>>>> GEOMTRANSFORMUNITS.
>>>>> We already have UNITS, TOLERANCEUNITS and SIZEUNITS. I would tend to
>>>>> force the user to use UNITS with GEOMTRANSFORM. I'm not necessary 
>>>>> right
>>>>> though.
>>>>>
>>>>
>>>> Thinking about this some more and out loud:
>>>>
>>>> - unless I'm mistaken, the UNITS value will matter in this context 
>>>> only
>>>> if you use the [map_cellsize] variable in your GEOMTRANSFORM 
>>>> expression.
>>>> In this case the UNITS setting is used to convert the map->cellsize 
>>>> from
>>>> the map output units to the units of the source data
>>>>
>>>> - if you don't use the [map_cellsize] variable then the args (e.g. the
>>>> simplify or buffer tolerance)) are passed directly to the 
>>>> corresponding
>>>> function (GEOS or other), so the arg value is assumed to be in the 
>>>> same
>>>> units as the source data (whatever it is) and the UNITS setting has no
>>>> impact in this case
>>>>
>>>> - there is currently no way in MapServer to set UNITS to a null/unset
>>>> value, so we have no way to know if UNITS was explicitly set in the
>>>> mapfile or not (the default units setting is meters)
>>>>
>>>> - adding a GEOMTRANSFORMUNITS param (presumably to add the ability to
>>>> pass the tolerance args in arbitrary units instead of in the data
>>>> source's units) will just complicate the issue and not solve the core
>>>> issue which is to determine in which units the original data source
>>>> coordinates are in order to convert the map>cellsize from map output
>>>> units to layer data source units for use in the [map_cellsize] 
>>>> variable
>>>>
>>>>
>>>> If the above are true, then a simple solution would be to always 
>>>> use the
>>>> layer->units value and never try to lookup of the projection units. We
>>>> should document the requirement to set UNITS together with the
>>>> [map_cellsize] variable docs (at the same place). If one chooses to 
>>>> use
>>>> [map_cellsize] in their GEOMTRANSFORM expression then they MUST also
>>>> explicitly set UNITS in the layer to the correct value 
>>>> (corresponding to
>>>> the UNITS of the raw vector data source).
>>>
>>> Daniel,
>>>
>>> This explanation is very clear and helps a lot - thank you.
>>>
>>> I agree with all of your points except for the part that if you set
>>> [map_cellsize] that you must set UNITS to reflect the raw source data
>>> units. This breaks the following use case.
>>>
>>> I have street data in degrees,
>>> I want to street widths to be rendered in meters
>>> (the proceeding is very common) and
>>> I need to apply a GEOTRANSFORM using [map_cellsize] or not.
>>>
>>> Your requirement means that I can not use different UNITS for the 
>>> WIDTH,
>>> the GEOTRANSFORM with [map_cellsize] and my source data!
>>>
>>> OK, so maybe this is not a case anyone would want to use, I just don't
>>> know. Maybe we should provide a way to specify the source data units if
>>> that is what is unknown and needed?
>>>
>>> I'm not trying to make this more complicated than it needs to be and I
>>> think that there is significant value even if it isn't supported for 
>>> all
>>> possible cases.
>>>
>>> Thanks,
>>>    -Steve W
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev