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

Stephen Woodbridge woodbri at swoodbridge.com
Wed Feb 20 20:38:30 PST 2013


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
>
>



More information about the mapserver-dev mailing list