MemoryDataStore would be best (for speed and low effort setting up test
cases).
--
Jody Garnett
On 16 January 2015 at 09:41, Torben Barsballe <tbarsba...@boundlessgeo.com>
wrote:
> 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
