GeoTools

Minimal Cleanup to FeatureCollection

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.5-M2
  • Fix Version/s: 2.5.0
  • Component/s: main
  • Labels:
    None

Description

There is a really good proposal out on how to clean up FeatureCollection it covers several topics:

  • making FeatureCollection not implement java.util.Collection (this is required so we do not accidently allow people to use a for each loop)
  • throwing out unused methods from Collection
  • etc...

We no longer have time to consider this entire proposal for the 2.5.0 release; but we do need to account for the first topic - not using java.util.Collection.

The attached patch has the following changes:

  • ResourceCollection no longer extends Collection
  • ResourceCollection is method compatible with collection
  • DataUtilities.list( FeatureCollection ): List - used to adapt to a real collection for a few test cases (around 12 failures)
  • Isolating the two prepCollection and prepFeatureCollection methods in StreamingRenderer
  1. Text File
    feature_collection_java5.patch
    17/Jul/08 12:19 AM
    34 kB
    Jody Garnett
  2. Text File
    feature_collection_java5.patch
    16/Jul/08 7:43 PM
    32 kB
    Jody Garnett
  3. Text File
    feature_collection_java5.patch
    16/Jul/08 4:23 AM
    29 kB
    Jody Garnett

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -
Creating a FeatureIterator that allows writing? Glab... you sure?
Our current API does not make it easy to determin when the user just wants to read as opposed to read/write, and it makes quite a few things harder, both architecture wise, performance wise and security wise. I would love to see FeatureCollection just be a read only way to access data. Frankly, I'd really love to see it disappear completely and have people use FeatureReader/Writer for sequential data access, and to use the FeatureStore writing methods for specific writes, but I guess this is not going to happen, right?
Show
Andrea Aime added a comment - Creating a FeatureIterator that allows writing? Glab... you sure? Our current API does not make it easy to determin when the user just wants to read as opposed to read/write, and it makes quite a few things harder, both architecture wise, performance wise and security wise. I would love to see FeatureCollection just be a read only way to access data. Frankly, I'd really love to see it disappear completely and have people use FeatureReader/Writer for sequential data access, and to use the FeatureStore writing methods for specific writes, but I guess this is not going to happen, right?
Hide
Permalink
Jody Garnett added a comment -
Andrea if you can read Justin's proposal; what he has is a seperate method call to something like an iterator that provides writing. Near as I can tell it is FeatureWriter withh less exceptions.
Show
Jody Garnett added a comment - Andrea if you can read Justin's proposal; what he has is a seperate method call to something like an iterator that provides writing. Near as I can tell it is FeatureWriter withh less exceptions.
Hide
Permalink
Jody Garnett added a comment -
Fixed a couple test failures; mostly H2 and the xml encoder making assumptions about collection
Show
Jody Garnett added a comment - Fixed a couple test failures; mostly H2 and the xml encoder making assumptions about collection
Hide
Permalink
Jody Garnett added a comment -
Fixed compile error with swing widgets pending (did not know that was back in the build) am off to test with uDig.
Show
Jody Garnett added a comment - Fixed compile error with swing widgets pending (did not know that was back in the build) am off to test with uDig.
Hide
Permalink
Jody Garnett added a comment -
Testing with uDig went fine; had to use one application of DataUtilities.list( featureCollection ) and we were good to go.
Show
Jody Garnett added a comment - Testing with uDig went fine; had to use one application of DataUtilities.list( featureCollection ) and we were good to go.
Hide
Permalink
Jody Garnett added a comment -
Updating the proposal:
- http://docs.codehaus.org/display/GEOTOOLS/DataStore+Cleanup

With the following tasks:

GeoTools 2.5
- FeatureCollection extends ResourceCollection does not extends java.util.Collection
- Deprecate unused java.util.Collection methods left in ResourceCollection; as measued by not being implemented
Show
Jody Garnett added a comment - Updating the proposal: - http://docs.codehaus.org/display/GEOTOOLS/DataStore+Cleanup With the following tasks: GeoTools 2.5 - FeatureCollection extends ResourceCollection does not extends java.util.Collection - Deprecate unused java.util.Collection methods left in ResourceCollection; as measued by not being implemented
Hide
Permalink
Jody Garnett added a comment -
Patch applied on trunk -r31031
Show
Jody Garnett added a comment - Patch applied on trunk -r31031
Hide
Permalink
Andrea Aime added a comment -
Jody, it looks like this has been fixed? If so, please close
Show
Andrea Aime added a comment - Jody, it looks like this has been fixed? If so, please close
Hide
Permalink
Andrea Aime added a comment -
Jody, hasn't this been fixed?
Show
Andrea Aime added a comment - Jody, hasn't this been fixed?
Hide
Permalink
Jody Garnett added a comment -
Yes I believe this was fixed; the proposal only has items remaining for 2.6.x under its tasks...
Show
Jody Garnett added a comment - Yes I believe this was fixed; the proposal only has items remaining for 2.6.x under its tasks...

People

  • Assignee:
    Unassigned
    Reporter:
    Jody Garnett
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: