Hi Jody, hi Gabriel, Thanks for response!
> I am the original implementor of MemoryDataStore and I am afraid it > needs a little love and attention. It was used to define the > datastore api and thus it is really focused on correctness; and not > speed or efficiency - indeed file based implementations like > shapefile are faster. Sounds good. I created a JIRA issue for MemoryDataStore a week ago (getBound -Error) include a test case. I would say, i append the MemoryDataStore patch where the getBounds patch is already included. Could you generalize the JIRA task to "Bugfixing MemoryDataStore" or something like that where we could apply all these patches? Do you have written any testcases to compare the performance of memory datastores with file based datastores? I looked into StreamingRenderer an i guess the envelope of request is not applied to the layer-filter except the method isMemoryPreloadingEnabled returns true. But if, how can the Datastore extract a spatial query from the filter (BoundingBox AND FidFilter)? Would be the DataStore the right place to create a SpatialIndex for faster access? And how would it look like? > In terms of order; there is the Query sortBy method if you wish to > ask for features in a specific order; I often made use of a TreeMap > internally (in order to avoid duplicate features; and to simulate the > idea of an index). > > I am interested in your patch :-) It sounds like an solid improvement. please have a look at the patch file for MemoryDataStore and MemoryDataStoreTest. It includes the one which is appended to the issue (http://jira.codehaus.org/browse/GEOT-2404). > > As far as I can tell the comment is full of it; the SLD specification > has specific ideas about how to draw features; and they allow you to > seperate out multiple rendering "passes" in order to handle > overlapping features in a sensible manner. Interesting, I agree the order of the results is unsorted by default. For example if you use a JDBC DataStore it's the order of the returned result is undefined if the "order by" clause where used (see http://www.programmersheaven.com/mb/oracle/317859/317859/default-order-of-data-retrival-in-oracle/?S=B20000). So I come to the conclusion that the datastores can't return the results in the same order each time the datastore is requested. Have a nice weekend. Frank > Jody > > On Fri, Mar 27, 2009 at 12:59 AM, <[email protected]> wrote: > Hi, > > I reviewed some DataStore implementations and have some questions. In > MemoryDataStore is a comment that the features should return in the > same order they were inserted. The FeatureSource interface does'nt > expect a specific order and the MemoryDataStore comment set me on the > wrong track I guess. Are there any requirements of the feature order > in a store (hopefully not because JDBC datastores could return > features in different order each time a new request were started)? > Is the TempMemoryDataStore a changed copy of MemoryDataStore (maybe a > try to get ConcurrentModificationExceptions in StreamRenderers > anymore). But I/we use the StreamMaps and the Exceptions were still > thrown. Therefore we created a fixed MemoryDataStore which uses the > ConcurrentHashMap to store the features. > Are you interested in a patch fixing the problems? I stumbled by > reading the following comment: > // use an order preserving map, so that features are returned in the > same > // order as they were inserted. This is important for repeatable > rendering > // of overlapping features. > > The implementation is'nt very consistent because in > addFeatures(FeatureReader <SimpleFeatureType, SimpleFeature> reader) > and createSchema-Method > the internal Map is a LinkedHashMap > > BUT in > > addFeatures(FeatureIterator<SimpleFeature> reader) a HashMap is used. > > I'm a little confused about that. Do you have any suggestions? > > Frank > > >
ConcurrentMemoryDataStore.patch
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
