On Wed, Nov 6, 2013 at 8:52 AM, Andrea Aime <[email protected]>wrote:
> On Wed, Nov 6, 2013 at 4:48 PM, Justin Deoliveira <
> [email protected]> wrote:
>
>>
>> On Wed, Nov 6, 2013 at 6:24 AM, Andrea Aime <[email protected]
>> > wrote:
>>
>>> Hi,
>>> when dealing with 3 dimensional data we genate GML that has the
>>> srsDimension attribute
>>> at the geometry level.
>>> It's a good place, it avoid repeating the attribute in all posLists
>>> around the code, however,
>>> the GML specification is not clear about how it is supposed to be
>>> handled, the spec
>>> says that srsName is inherited by the contained elements, but does not
>>> say anything about
>>> srsDimension.
>>>
>>> Turns out there is software around (NTS) that is not able to deal with
>>> srsDimension at the
>>> geometry level, and works only if it is specified at the posList level
>>> instead.
>>>
>>> How do you feel about having srsDimension be specified also at the
>>> posList level?
>>> Or would it be better to specify it only there to avoid the duplication?
>>>
>>
>> My initial thought is that adding the attribute for a single client may
>> be a bit much. How about adding a configuration option to engage it?
>>
>
> Eh, yes, that's the only example I have, at the same time the spec leaves
> room for this
> kind of interpretation.
>
> Well given that gml (especially the later versions) isn't built for
terseness I don't imagine it will be an issue to add the additional
property to the position / coordinate level. It would be nice if Ben could
weigh in. If Ben sees no adverse side affects than I am fine with just
adding this in by default, otherwise i would vote to make it an option.
> About the configuration, would a system variable do?
>
If we do go the option route it would be nice if the option followed the
pattern the other encoding config options (like bounds, featureMember vs
featureMembers, etc...) work. Maybe we could support the system property at
the geoserver level and when set engage the appropriate config property on
the xml encoder configuration.
Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
[email protected]
@j_deolive <https://twitter.com/j_deolive>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
