[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] about MemoryDataStore
|
On 13/10/2009, at 7:41 PM, Arto Pastinen wrote:
Ok, thanks for the info, later i need to optimize the speed anyway,
and i am currently using the memory datastore as store for my objects
so it is good to know.
In testing shapefile often comes across as faster then memory
datastore - just because of the use of a spatial index. There are a
couple of implementations of a memory feature collection around that
uses a JTS spatial index; but they have not been packaged up as a
memory datastore implementation yet.
The idea should be to perform a deep copy; so that if code is
holding on to
an added feature they will not
accidentally change content that has been "committed" into the memory
datastore.
Ok, actually that is what i need to do, change the data etc. =)
Correct - so to do that you will need to use the transaction / commit
workflow (just as if you were working with a database or shapefile).
Yeah I know it is a pain - but this way your program will work on
massive datasets.
Interesting; I would view SimpleFeature as dumb storage - like a
database.
If you would like
to get your own content created you should be able to make a
FeatureFactory
and teach the datastore
how to create your objects.
I would be happy to make sure the code can take a factory for this
purpose;
right now I think
you need to supply it with your Query in the form of a hint.
What do you mean with "Query in the form of a hint.", what i am
currently do, is
some kind feature editor, much like what coreldraw was years ago, i
have a list of features
which i am going to draw to map, and those shapes should be editable,
which mouse in map, and
from some kind property editor.
Okay - there is an Editor extension point defined just for that; based
on the FeatureType it will show your feature editor (rather then the
default property view). There is a tutorial on this - defining a
custom editor for the "countries" shapefile included with the sample
data.
Because there is going to be many kind shapes and they have much
special functionaliy, i was thinking to extend SimpleFeature's to
specialise the
SimpleFeature, instead playing with Adapters and Filters, they are
just going to mess the code..
That is a fine approach; when you go to ask the FeatureSource for what
is selected - you would need to perform a featureSource.getFeatures
( Query ). That query takes a filter; and can also take some Hints;
including a hint about what FeatureFactory to use when creating each
feature returned....
I do understand it - you want to do normal object oriented
programming! When
i want to that I just go ahead and
write my objects as normal; and create a custom udig renderer to
get them
drawn along with all my normal GIS
stuff (features, rasters etc...).
The custom renderer is indeed one solution, but i still like to use
the code which also others are maintain, as much as possible, but i
will see..
Cheers,
Jody
