At the moment I try to implement an universal DataStore supporting Hints.GEOMETRY_DISTANCE.
The configuration is read from an XML file (Default Implementation)
Each pregeneralized feature type (or vector pyramid) has the following properties
1) distance
2) name of the geometry property
3) name of feature type where the pregeneralized geoms are stored
4) name of the datastore (e. g. for shape files, each feature typ has its own datastore)
The problem at the moment is how to find a path from a datastore name to a datastore object.
For geoserver, I assume the Catalog>>getDataStoreByName(String name) is my friend.
For geotools, I did not find anything comparable except the FeatureSourceRepository, Clients must create a proper FeatureSourceRepository object and initialize the new DataStore object.
And finally, if I this is correct, I have to implement a plugin mechanism for finding data stores.
(I have no idea how UDig works, I assume a catalog approach)
Hi Christian; please view geotools as the data access layer.
Organizing the live connections (ie datastores) into a catalog or
registery is something each application can figure out on its own;
even if they just use a singleton.
So any questions about catalog will need to be directed to the
application you are working within.
However I do have a suggestion; can you present a single datastore
that makes use of several "internal" datastores to do the work? This
way you can register your single datastore in the geoserver catalog
and it will never know the difference.
This is the approach taken by the geotools directory datastore; and
you may find it useful. Your datastore would probably only serve a
single featureSource; but would dynamically choose which internal
datasoure to retrieve a feature collection from based on the hint you
mention above.
Cheers.
Jody
On Tue, Apr 7, 2009 at 10:34 PM, Christian Müller
<christian.mueller@anonymised.com> wrote:
Hi Andrea
At the moment I try to implement an universal DataStore supporting
Hints.GEOMETRY_DISTANCE.
The configuration is read from an XML file (Default Implementation)
Each pregeneralized feature type (or vector pyramid) has the following
properties
1) distance
2) name of the geometry property
3) name of feature type where the pregeneralized geoms are stored
4) name of the datastore (e. g. for shape files, each feature typ has its
own datastore)
The problem at the moment is how to find a path from a datastore name to a
datastore object.
For geoserver, I assume the Catalog>>getDataStoreByName(String name) is my
friend.
For geotools, I did not find anything comparable except the
FeatureSourceRepository, Clients must create a proper
FeatureSourceRepository object and initialize the new DataStore object.
And finally, if I this is correct, I have to implement a plugin mechanism
for finding data stores.
(I have no idea how UDig works, I assume a catalog approach)
christian
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
The principle is the same as the directory data store but the the requirements are more complex.
1) Need to specify the generalization distance for each set of precalculated geometries.
2) No restriction to file based data stores, reading from any data store should be possible
and so on ....
The geotools implementation does not make me a headache, I can offer a lot of creation variants and delegate some stuff to the application.
Geoserver is the challenge.
The geoserver admin interface offers me the possibility of one config url. Within this configuration I find the names of data stores and I have to rely that I find these data stores in the geoserver catalog.
So far, so good.
But how should I code that ?. The Catalog is defined in a geoserver package, and I am still in geotools.
I am looking for a way to integrate into geoserver without special coding.
Any idea ?
Jody Garnett writes:
Hi Christian; please view geotools as the data access layer.
Organizing the live connections (ie datastores) into a catalog or
registery is something each application can figure out on its own;
even if they just use a singleton.
So any questions about catalog will need to be directed to the
application you are working within.
However I do have a suggestion; can you present a single datastore
that makes use of several "internal" datastores to do the work? This
way you can register your single datastore in the geoserver catalog
and it will never know the difference.
This is the approach taken by the geotools directory datastore; and
you may find it useful. Your datastore would probably only serve a
single featureSource; but would dynamically choose which internal
datasoure to retrieve a feature collection from based on the hint you
mention above.
Cheers.
Jody
On Tue, Apr 7, 2009 at 10:34 PM, Christian Müller
<christian.mueller@anonymised.com> wrote:
Hi Andrea
At the moment I try to implement an universal DataStore supporting
Hints.GEOMETRY_DISTANCE.
The configuration is read from an XML file (Default Implementation)
Each pregeneralized feature type (or vector pyramid) has the following
properties
1) distance
2) name of the geometry property
3) name of feature type where the pregeneralized geoms are stored
4) name of the datastore (e. g. for shape files, each feature typ has its
own datastore)
The problem at the moment is how to find a path from a datastore name to a
datastore object.
For geoserver, I assume the Catalog>>getDataStoreByName(String name) is my
friend.
For geotools, I did not find anything comparable except the
FeatureSourceRepository, Clients must create a proper
FeatureSourceRepository object and initialize the new DataStore object.
And finally, if I this is correct, I have to implement a plugin mechanism
for finding data stores.
(I have no idea how UDig works, I assume a catalog approach)
christian
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
I had read the user guide.
The principle is the same as the directory data store but the the requirements are more complex.
1) Need to specify the generalization distance for each set of precalculated geometries.
2) No restriction to file based data stores, reading from any data store should be possible
and so on ....
The geotools implementation does not make me a headache, I can offer a lot of creation variants and delegate some stuff to the application.
Geoserver is the challenge.
The geoserver admin interface offers me the possibility of one config url. Within this configuration I find the names of data stores and I have to rely that I find these data stores in the geoserver catalog.
So far, so good.
But how should I code that ?. The Catalog is defined in a geoserver package, and I am still in geotools.
I am looking for a way to integrate into geoserver without special coding.
Any idea ?
If you do your datastore factory in GeoServer and use
GeoServerExtensions to lookup the catalog you'll get enough information
to pull this out. That's the approach I'd suggest you use.
Alternatively, you can do this fully in GeoTools if your datastore
configuration file has all the information needed to connect
to the slave datastores, that is, a set of connection parameters per
slave datastore. And you'd also need a way to configure the datastores
separately as I guess you might want to use the same datastore multiple
times (multiple feature types in the same db building your pyramid).
This is doable, but at the same time looks pretty much complex to
configure from a GeoServer user point of view (the point and click
kind of user, that is).
Anyways, whatever you do, try to make it as configurable as possible
from a programmatic point of view, with the new UI we'll try to
make everything as configurable as possible from the UI itself
(so the way the configuration is stored and edited might change).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
The principle is the same as the directory data store but the the
requirements are more complex.
1) Need to specify the generalization distance for each set of
precalculated geometries.
2) No restriction to file based data stores, reading from any data store
should be possible
and so on ....
I understand the difference; the idea was to point out how a DataStore
implementation can manage "internal" datastores which it delegates
work to. I had not reason to think you were restricted to file based
data stores.
The geotools implementation does not make me a headache, I can offer a lot
of creation variants and delegate some stuff to the application.
Geoserver is the challenge.
The geoserver admin interface offers me the possibility of one config url.
Within this configuration I find the names of data stores and I have to rely
that I find these data stores in the geoserver catalog.
I am not sure about the single config url; you should get a mess of
connection parameters to deal with. However you can always point your
implementation at a property file that describes what you need. This
is the way the image pyramid works.
So far, so good.
But how should I code that ?. The Catalog is defined in a geoserver
package, and I am still in geotools.
I understand you are looking for a way for GeoServer to "advertise"
the ability to look up FeatureSource implementations into the geotools
code base; so your geotools code can look up (or refer to) some of the
other "live" connections/implementations.
This was the point of the Repository interface; specifically for the
validation code that had the same requirement. The Repository had a
very poor naming convention "datastore:::typeName" as I recall. I do
not think geoserver is currently implementing this api.
I am looking for a way to integrate into geoserver without special coding.
Any idea ?
Three Ideas:
a) patch up the Repository api to match what geoserver has on now;
hopefully backing it onto that new catalog? This is a lot of work
May but be the easiest to understand at the end of the day.
b) go for a single properties file that describes the connection
parameters for several datastores; use a DataStoreFinder to create
your own internal datastores; and spend your time ensuring that the
same connection pool is used by both the geoserver PostGISDataStore
entry; and your internal PostGISDataStore entry for the same content.
c) treat this as a hard configuration problem in GeoServer; make the
connection parameters for your datastore ask that the internal
FeatureSource instances be passed in; and then teach the GeoServer
configuration api how to look up a catalog reference; and process a
catalog reference into a FeatureSource when creating your instance.
Option (c) is pretty darn clean; and I am hard pressed to recommend
anything else - even though I personally like (a).
I am looking for a way to integrate into geoserver without special coding.
Any idea ?
Three Ideas:
a) patch up the Repository api to match what geoserver has on now;
hopefully backing it onto that new catalog? This is a lot of work
May but be the easiest to understand at the end of the day.
Last time we discussed about the repository API I was
asking it to be removed from gt-main if I my memory serves me right?
I may have to look into it again, but I have negative memories
of it, for sure I'm not looking forward to have GeoServer depend/use it
as a core component. If this can be implemented as a plugin I have
no issues with that, non core plugins are totally hands free.
b) go for a single properties file that describes the connection
parameters for several datastores; use a DataStoreFinder to create
your own internal datastores; and spend your time ensuring that the
same connection pool is used by both the geoserver PostGISDataStore
entry; and your internal PostGISDataStore entry for the same content.
We already went down this path as we agreed that factories holding
onto connection pools in static variables is not a sane idea.
How else one would manage these? (I mean, besides using contained
managed pools located in JNDI).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
So you agree with my option (c) then Andrea? I also find it the most
clean approach.
Jody
On Wed, Apr 8, 2009 at 4:33 PM, Andrea Aime <aaime@anonymised.com> wrote:
Jody Garnett ha scritto:
I am looking for a way to integrate into geoserver without special
coding.
Any idea ?
Three Ideas:
a) patch up the Repository api to match what geoserver has on now;
hopefully backing it onto that new catalog? This is a lot of work
May but be the easiest to understand at the end of the day.
Last time we discussed about the repository API I was
asking it to be removed from gt-main if I my memory serves me right?
I may have to look into it again, but I have negative memories
of it, for sure I'm not looking forward to have GeoServer depend/use it
as a core component. If this can be implemented as a plugin I have
no issues with that, non core plugins are totally hands free.
b) go for a single properties file that describes the connection
parameters for several datastores; use a DataStoreFinder to create
your own internal datastores; and spend your time ensuring that the
same connection pool is used by both the geoserver PostGISDataStore
entry; and your internal PostGISDataStore entry for the same content.
We already went down this path as we agreed that factories holding
onto connection pools in static variables is not a sane idea.
How else one would manage these? (I mean, besides using contained
managed pools located in JNDI).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
So you agree with my option (c) then Andrea? I also find it the most
clean approach.
From my previous mail:
If you do your datastore factory in GeoServer and use
GeoServerExtensions to lookup the catalog you'll get enough information
to pull this out. That's the approach I'd suggest you use.
Sorry for not delving into details, this thread has already
used more time than I can devote to it.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
