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

Alan Boudreault aboudreault at mapgears.com
Mon Feb 25 08:36:17 PST 2013

FYI, this rfc is pushed in master.


On 13-02-22 10:26 PM, Alan Boudreault wrote:
> 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
>>>>>> 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
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

Alan Boudreault

More information about the mapserver-dev mailing list