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

[Lime, Steve D (MNIT)]

I'd rather see support for an optional units parameter to the functions that can handle it. More metadata would suck... I do like the idea of a [cellsize] tag.

One issue missing from the SLA is how to handle queries since presumably a user will want to interact with transformed features in a map display. For style GEOMTRANSFORMs we basically just punted. For layer-level GEOMTRANSFORMs the transformation should/could also be applied when querying so transformations should be integrated into the msLayerNextShape()/msLayerGetShape() pipeline (see RFC 72).

I don't know what your funding looks like but it would be great to have labelObj GEOMTRANSFORMs too.

Steve

________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] on behalf of Stephen Woodbridge [woodbri at swoodbridge.com]
Sent: Tuesday, February 19, 2013 8:30 PM
To: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] RFC 89 Layer Geomtransform: Call for vote

On 2/19/2013 4:55 PM, Alan Boudreault wrote:
> Stephen,
>
> I'm afraid that in the code I cannot know if the layer UNITS was set by
> the user explicitly, since there is a default value. MS_METER is the
> default. I can check the specified proj for sure.. but how to know if I
> should use layer->units or map->units if there is no layer proj set.
> Either we force the layer->units to be set explicitly or we just don't
> rely on it and check the proj then fall back to the map units.
>
> Any thoughts?

OK, well if other have a thought on this, please chime in.

I think that we should always take the specific over the general. And I
would err on the side that is most easiest for the user to correct.

So I think that means use the UNITS set at the LAYER always even if it
is the default value. I'm not sure that I like this option because if
the user wants to set the LAYER in one UNITS but to specify this in
another UNITS it is a problem.

That said, it is well defined behavior and it would be consistent and
easy to understand.

I'm not sure it makes sense to go this direction, but you could
potentially look for a METADATA GEOTRANSFORMUNITS units END and use that
if it exists. This would decouple it from the other use of UNITS.

Any thoughts on up or down side of doing either of these?

-Steve W

> Alan
>
> On 13-02-19 11:09 AM, Stephen Woodbridge wrote:
>> On 2/19/2013 10:30 AM, Alan Boudreault wrote:
>>> Thanks Daniel for the good explanation. If everyone agree, I'll add this
>>> information in the RFC.
>>>
>>> Steve, in the code, if the UNITS is specified... it will be used. Else,
>>> I'll try to get the projection unit, and finally default to degree. Is
>>> this ok?
>>
>> Yes, that sounds like the best effort that you can do. I agree with the
>> change. If the user needs it to be more precise then they need to
>> specify UNITS. Please add this detail to the RFC because it will need to
>> be documented when everything is done.
>>
>> Thanks,
>>    -Steve W
>>
>>> Thanks,
>>> Alan
>>>
>>> On 13-02-19 10:12 AM, Daniel Morissette wrote:
>>>> Alan, All,
>>>>
>>>> As we looked into the implementation details with Alan, we found out
>>>> that the STYLE-level GEOMTRANSFORM receives a shape in pixel
>>>> coordinates, whereas the LAYER-level GEOMTRANSFORM will receive the raw
>>>> shape in ground coordinates (meters, degrees, etc.)
>>>>
>>>> This poses a little potential for confusion in the user's mind as the
>>>> argument to methods such as simplify() must be in the same units as the
>>>> coordinates of the shapes at that point of the rendering workflow, i.e.
>>>> pixels at the STYLE-level and in ground units at the LAYER-level.
>>>>
>>>> e.g.
>>>>
>>>> LAYER NAME "my_layer"
>>>>    TYPE LINE
>>>>    STATUS DEFAULT
>>>>    DATA "lines.shp"
>>>>    GEOMTRANSFORM (simplify([shape], 10))  ## 10 ground units
>>>>    CLASS
>>>>      STYLE
>>>>        GEOMTRANSFORM (buffer([shape], 5)  ## 5 pixels
>>>>        WIDTH 2
>>>>        COLOR 255 0 0
>>>>      END
>>>>    END
>>>> END
>>>>
>>>>
>>>> It would be possible (but messy) to include some maths at the
>>>> layer-level to allow passing a value in pixels at the layer level as
>>>> well. This way things would be consistent between STYLE level and LAYER
>>>> level as we would always pass args in pixels, but this may not be what
>>>> we want in lots of cases, for instance if a LAYER-level
>>>> GEOMTRANSFORM is
>>>> used to simplify shapes in a WFS context where pixel size makes no or
>>>> little sense.
>>>>
>>>> It is also not possible at all to deal with values in ground units at
>>>> the style level because we do not have information about map
>>>> cellsize at
>>>> that level in the code (so passing values in ground units at the style
>>>> level is not an option without messy code changes)
>>>>
>>>> Note that in cases where we want to pass a pixel value at the layer
>>>> level, a [map_cellsize]  variable will be available, e.g.
>>>>
>>>> LAYER NAME "my_layer"
>>>>    TYPE LINE
>>>>    STATUS DEFAULT
>>>>    DATA "lines.shp"
>>>>    # 10 * [map_cellsize] == 10 pixels converted to ground units
>>>>    GEOMTRANSFORM (simplify([shape], [map_cellsize]*10))
>>>>    ...
>>>>
>>>>
>>>> It seems that our best option would be to keep the values as pixels at
>>>> the style level and ground units at the layer level, and properly
>>>> document the difference, and hope that users won't be too confused.
>>>>
>>>> What do you all think?
>>>>
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On 13-02-14 6:58 AM, Alan Boudreault wrote:
>>>>> Hi devs,
>>>>>
>>>>> Please vote on RFC 89, Layer Geomtransform (
>>>>> http://mapserver.org/trunk/development/rfc/ms-rfc-89.html )
>>>>>
>>>>> I'll start with my +1.
>>>>>
>>>>> Thanks,
>>>>> Alan
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 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