From: Martin D. <md...@op...> - 2012-04-30 23:08:01
|
I just tried this in ReprojectFeatureIterator, and it seems to work for my test (running a WFS query against an Oracle datastore). It was a bit ugly having to change ReprojectFeatureIterator, however, so what might be better is to simply alter GeometryCoordinateSequenceTransformer so it lazily creates a DefaultCoordinateSequenceTransformer using the CSF of the first Geometry it sees. This will then be transparent to all calling code. I'll try this. Some suggestions on which tests to try would be welcome, since this is pretty far-reaching. On Mon, Apr 30, 2012 at 3:23 PM, Jody Garnett <jod...@gm...>wrote: > The GeometryCoordinateSequenceTransformer is used in quite a few places > where reprojection of FeatureCollections take place. It provides two > constructors: the default one uses a default > CoordinateArraySequenceFactory, while the other can specify which > CoordinateSequenceFactory to use. But only the default constructor is > every used. This has the effect of changing the CoordinateSequence from > LiteCoordinateSequence to CoordinateArraySequence. Is this deliberate, or > just an oversight or a dont_care? > > > I suspect this is just a result of the codebase being old; and us only > introducing LiteCoordinateSequence in a minimal amount of places. > > The reason I'm interested is that unfortunately CoordinateArraySequence > currently only supports a fixed coordinate dimension of 3. This means that > the true coordinate dimension captured in the LiteCoordinateSequence is > lost. This makes it more difficult to accurately output the correct > dimension in the GML3 encoder. > > Right. > > It looks like a fairly simple change to create > GeometryCoordinateSequenceTransformers with the same > CoordinateSequenceFactory as the input, but would this cause downstream > issues? > > It should be okay; as long as our test cases pass - and it does not harm > Andrea's rendering performance story we should be alright. > > (The inability to set a dimension on CoordinateArraySequence is a flaw in > the current JTS API. I'm going to add the ability to set this in the > factory, but this won't happen soon enough to help this GeoTools problem). > > This would be the kind of change to try on trunk first; and then back port > to the stable branch after we have confirmed downstream projects are still > happy. > > I note that I have sent a "release candidate" email out; so ideally you > could try out this change shortly? I expect a couple of weeks of code > freeze as we take the library through QA with downstream projects. > > Jody > > -- Martin Davis OpenGeo - http://opengeo.org Expert service straight from the developers. |