Re: [udig-devel] about MemoryDataStore

[Arto Pastinen <arto.pastinen@xxxxxxxxx>]

Hi, i have now spend some time to play and test all kind options to
continue my work,
about these edit tools, if i have understand correctly, the changes
will be committed when user saves
the map, like with CTRL+S key?

What happends now with temprary geo resource, the udig offers to save
the map to .shp file, instead to save to memory (ok there was also
some nullpointerexception, in 1.2M4, but i fixed it..), where and how
this save functionality is defined if i can do something for it?

- Artsi


2009/10/14 Jody Garnett <jody.garnett@xxxxxxxxx>:
>
> 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
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>