Where would be the best place for test cases for these changes:
Looking through the ContentDataStore/ContentFeatureSource test cases, the
mocks used are not fully functioned and would not really support tests of
the feature reader bounds query reprojections.
Would it make more sense to expand the mock to properly implements
getBoundsInternal and getReaderInternal, or add test cases for this fix to
downstream implementing classes such as PropertyFeatureSource?
There is one related test in MemoryDataStore, but this is insufficient to
fully test the 'new' funcitonality.
Torben
On Thu, Jan 15, 2015 at 5:49 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> AbstractDataStore had a ForceCoordinateSystemIterator
> <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/crs/ForceCoordinateSystemIterator.java>
> and
> there is a ForceCoordinateSystemFeatureReader
> <https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/crs/ForceCoordinateSystemFeatureReader.java>
> that
> also does the trick.
>
> If you look in the implementation you will see:
>
> if (!cs.equals(originalCs)) {
> type = FeatureTypes.transform(type, cs, forceOnlyMissing);
> }
>
> So there is a FeatureTypes utility method to adjust the CRS.
>
> --
> Jody Garnett
>
> On 15 January 2015 at 16:57, Torben Barsballe <tbarsba...@boundlessgeo.com
> > wrote:
>
>> In order to fix the problems with ContentFeatureSource, changes are
>> required to ContentFeatureSource.getBounds(Query) and
>> ContentFeatureSource.getReader(Query). Fixing getBounds is relatively easy,
>> but it looks like getReader is a bit more difficult.
>>
>> Basic reprojection is handled by ReprojectFeatureReader, which reprojects
>> from the CRS of the GeometryDescripter of the FeatureType of the wrapped
>> reader
>> (reader.getFeatureType().getGeometryDescriptor().getCoordinateReferenceSystem();)
>> to the provided feature type.
>>
>> Is there any way to force the CRS of our underlying featureType?
>>
>> Alternatively, I could change the implementation of
>> ReprojectFeatureReader to take a source and target CRS to bring it more in
>> line with the Query API, but I feel like this is straying a bit from the
>> intended usage, especially in the case where we are just forcing the CRS
>> and not reprojecting.
>>
>> Torben
>>
>> On Thu, Jan 15, 2015 at 3:09 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> While migrating MemoryDataStore to extend ContentDataStore, I have
>>> discovered that ContentDataStore does not conform to the Geotools query API:
>>>
>>> Query has two CRS variables:
>>>
>>> coordinateSystem;
>>> The coordinate system to apply to features retrieved by this Query.
>>>
>>> This denotes a request to *temporarily* override the coordinate system
>>> contained in the feature data source being queried. The same coordinate
>>> values will be used, but the features retrieved will appear in this
>>> Coordinate System.
>>>
>>> This change is not persistant and only applies to the features returned
>>> by this Query. If used in conjunction with getCoordinateSystemReproject()
>>> the reprojection will occur from getCoordinateSystem() to
>>> getCoordinateSystemReproject().
>>>
>>> coordinateSystemReproject;
>>> Request that features retrieved by this Query be reprojected into the
>>> given coordinate system.
>>>
>>> If used in conjunction with
>>> setCoordinateSystem(CoordinateReferenceSystem) the reprojection will occur
>>> from the overridden coordinate system to the system specified here.
>>>
>>> The current implementation of ContentDataStore ignores coordinateSystem
>>> and only checks coordinateSystemReproject. The only class implementing
>>> canReproject() is WFSFeatureSource, which also ignores coordinateSystem.
>>>
>>> I will be working to fix this in the near future.
>>>
>>> Torben
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>> GigeNET is offering a free month of service with a new server in Ashburn.
>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>> http://p.sf.net/sfu/gigenet
>> _______________________________________________
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
