about MemoryDataStore

[Arto Pastinen-2]

Hi,

What is the idea in MemoryDataStore(FeatureWriter) to instead store
the given SimpleFeature (addFeature), to create new instance from
SimpleFeature, and just set the attributes to it?

What i try to do is extend SimpleFeature and SimpleFeatureType, so i
could make more control how feature should work, so those could fit
better to my domain.
For an example i am doing a SimpleFeature class, which i give some
coordinates and it will automatically calculate more shapes for it,
and i need to do more these kind own classes. Ok this is what i have
already done, but now what happend when i later try drag coordinates
in map, and i try to access my instance my featureStore.getFeatures(),
the original instances has been replaced by normal SimpleFeature
classes, and cant anymore cast those to my own classes..

Of course i could implement all MemoryDataStore and stuff again, but
that is something i dont like to do.. or is there some examples?

I hope you understand, it is quite difficult to explain.. =)

thanks, Artsi
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

[Jody Garnett-3]

Hi - I think I can answer questions about Memory Datastore :-)

Be advised that the memory datastore is not especially fast; it is  
intended to simulate
a data storage format; and does not have a spatial index or anything.

On 12/10/2009, at 7:33 PM, Arto Pastinen wrote:

> Hi,
>
> What is the idea in MemoryDataStore(FeatureWriter) to instead store
> the given SimpleFeature (addFeature), to create new instance from
> SimpleFeature, and just set the attributes to it?

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.

> What i try to do is extend SimpleFeature and SimpleFeatureType, so i
> could make more control how feature should work, so those could fit
> better to my domain.

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.

> For an example i am doing a SimpleFeature class, which i give some
> coordinates and it will automatically calculate more shapes for it,
> and i need to do more these kind own classes. Ok this is what i have
> already done, but now what happend when i later try drag coordinates
> in map, and i try to access my instance my featureStore.getFeatures(),
> the original instances has been replaced by normal SimpleFeature
> classes, and cant anymore cast those to my own classes..

That is correct; remember it is being a simulating of writing your  
object out to disk. It is not
trying to hold on to your objects as provided.

There is a couple of feature collection classes that will hold on to  
features on disk... but we
would need to teach udig to render those.

> Of course i could implement all MemoryDataStore and stuff again, but
> that is something i dont like to do.. or is there some examples?
>
> I hope you understand, it is quite difficult to explain.. =)

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 tracking example shows this approach; in that objects are rendered  
on a map dynamically as they move.

I am keen to allow the GIS facilities to work as a form of object  
persistence; but it is really not a common request (just something I  
think is fun).

Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

[Arto Pastinen-2]

2009/10/12 Jody Garnett <jody.garnett@...>:
> Hi - I think I can answer questions about Memory Datastore :-)
>
> Be advised that the memory datastore is not especially fast; it is intended
> to simulate
> a data storage format; and does not have a spatial index or anything.

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.

>
> On 12/10/2009, at 7:33 PM, Arto Pastinen wrote:
>
>> Hi,
>>
>> What is the idea in MemoryDataStore(FeatureWriter) to instead store
>> the given SimpleFeature (addFeature), to create new instance from
>> SimpleFeature, and just set the attributes to it?
>
> 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. =)

>
>> What i try to do is extend SimpleFeature and SimpleFeatureType, so i
>> could make more control how feature should work, so those could fit
>> better to my domain.
>
> 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.
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..

>
>> For an example i am doing a SimpleFeature class, which i give some
>> coordinates and it will automatically calculate more shapes for it,
>> and i need to do more these kind own classes. Ok this is what i have
>> already done, but now what happend when i later try drag coordinates
>> in map, and i try to access my instance my featureStore.getFeatures(),
>> the original instances has been replaced by normal SimpleFeature
>> classes, and cant anymore cast those to my own classes..
>
> That is correct; remember it is being a simulating of writing your object
> out to disk. It is not
> trying to hold on to your objects as provided.
>
> There is a couple of feature collection classes that will hold on to
> features on disk... but we
> would need to teach udig to render those.
>
>> Of course i could implement all MemoryDataStore and stuff again, but
>> that is something i dont like to do.. or is there some examples?
>>
>> I hope you understand, it is quite difficult to explain.. =)
>
> 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..

>
> The tracking example shows this approach; in that objects are rendered on a
> map dynamically as they move.
>
> I am keen to allow the GIS facilities to work as a form of object
> persistence; but it is really not a common request (just something I think
> is fun).
>
> Jody
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

[Jody Garnett-3]

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

[Arto Pastinen-2]

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@...>:

>
> 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
>

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

[Jody Garnett-3]

On 26/10/2009, at 9:20 PM, Arto Pastinen wrote:

Hi, i have now spend some time to play and test all kind options to
continue my work,

Good timing; moovida was looking at a h2 datastore yesterday which may be one of the options?

about these edit tools, if i have understand correctly, the changes
will be committed when user saves the map, like with CTRL+S key?

Each temporary layer is given a chance to save itself when the map is closed (or CTRL+S is pressed I guess).

How it does that we will need to check; right now the code to export to a shapefile is in single location.

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?

Could we try another technique here; you just want the stuipid save process to shut up right?

Can you make your own memory datastore and use it for your own work? As long as the IGeoResource does

not implement "ITransientResolve" you should be okay?

Jody

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

[Arto Pastinen-2]

2009/10/26 Jody Garnett <jody.garnett@...>:
>
> On 26/10/2009, at 9:20 PM, Arto Pastinen wrote:
>
> Hi, i have now spend some time to play and test all kind options to
> continue my work,
>
> Good timing; moovida was looking at a h2 datastore yesterday which may be
> one of the options?

Ok it is fine, one option what i was thinking was to create some
temporary .shp file to be the datastore, but there is some document
that it can contain only one graphic or something. I am not sure what
it means the file format is unknow for me.. I need to be able to draw
points and polygons etc. and i will do graphic tools to draw arrows
etc.

>
> about these edit tools, if i have understand correctly, the changes
> will be committed when user saves the map, like with CTRL+S key?
>
> Each temporary layer is given a chance to save itself when the map is closed
> (or CTRL+S is pressed I guess).
> How it does that we will need to check; right now the code to export to a
> shapefile is in single location.
>
> 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?
>
> Could we try another technique here; you just want the stuipid save process
> to shut up right?
> Can you make your own memory datastore and use it for your own work? As long
> as the IGeoResource does
> not implement "ITransientResolve" you should be okay?
> Jody

Ok own memory datastore is also just fine, what i want is to commit
the features which are drawn with edit tools to memory datastore, in
my tests i have found that commit happends in case of save, but when
datastore is memory datastore udig offers to write them to disk, and
that is not what i want.. unless i use the temporary .shp which i tell
earlier comment.
Later when user has drawn what he needs, there is some my own export
button to export the features to our own file format.

> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>

thanks, Artsi
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel