In agree in that a more flexible metadata (in the whole OGC sense) discovery and explotation system would be
of great help, since there are backends that already implements it. It is the case of ArcSDE, where the metadata can
be stored in the database itself, and I have seen lots of shapefiles wich goes with it’s corresponding .xml medatada file.
I will be trying to figure out how we can do it when get some time, but I don’t think I’ll could be working
on it until january.
regards,
Gabriel
-----Mensaje original-----
De: Simon Räss [mailto:simon.raess@anonymised.com]
Enviado el: martes, 25 de noviembre de 2003 9:58
Para: geoserver-devel@lists.sourceforge.net
Asunto: Re: [Geoserver-devel] locking & TypeRepositoryAs far as I can tell from the source code, it seems that the locking of
features is completely implemented in java and not in the database.
Wouldn’t it be better, to implement locking in the database through the
data source? Especially for somebody that wants to use geoserver just as
an additional front-end to a common database. i.e. non-wfs clients and
wfs clients are accessing the data concurrently.
Yes, you are exactly correct. We are working on that functionality right
now. Most of the work is in geotools, we’ve done away with
TypeRepository. Most of the work is in the data module of geotools. The
locking functions are mostly in org.geotools.data.FeatureLocking. They
use a locking manager, with the default being an InProcessLockingManager,
which is like the TypeRepository, all java. The PostgisLockingManager
should be along soon, working with Postgis 0.8 when it comes out, as
Refractions added new locking backend locking methods. ArcSde and Oracle
will also be supported in time. It’s a bit trickier than it looks at
first, since the wfs notion of locking is a bit different than most db’s
notions.
I’ve just downloaded the latest nightly build from geotools and I’ve seen that some changes are going on in the area of locking. My point is just, the locking api should be flexible enough to work with an exisiting locking system, for instance in an existing gis system.
Another question concerning the TypeRepository.
org.vfny.geoserver.config.TypeRepository is a concrete class. It loads
the type information from info.xml and the corresponding xml schema from
schema.xml. This is a fairly specific setup. We would want to load this
information from the database. Shouldn’t there be an interface that
defines the basic methods every TypeRepository must implement and
implementing classes that define a custom TypeRepository? Just to remove
the dependency from a specific implementation…
Hmmm, that’s an interesting point. We’re redoing configuration right now.
We’ve got a lot of changes going on in the wms-merge, making room for the
new geotools data io apis. The replacement for TypeRepository is
org.geotools.config.CatalogConfig. The way the configuration will work is
that you define your connection parameters in catalog.xml, defining your
DataStores, and then each FeatureType will reference the its DataStore to
get its connection. The locking methods of TypeRepository move to
geotools LockingManagers. As for schema.xml, where we would eventually
like to go is have datasources automatically generate their schemas.
I would very much welcome this. FeatureTypes are also generated dynamically from table metadata, so it shouldn’t be a too big problem to implement this. I could do it quick and dirty, but that is obviously not very usefull…
They do this now, making geotools FeatureTypes, but we can not turn those
into XML Schemas yet. The geotools FeatureTypes also need some
improvement before we can do that. Jody Garnett is planning on spending
the next two months or so on configuration, and I think he also wants to
split things up a bit more. So what you should do is look at the new
configuration (which is still evolving), and come up with a concrete
proposal of how you’d like things split up.
I was just thinking, it would be nice to load the meta data (feature type name, title, …) from the database.
If possible you can code up a new set of interfaces, and we could easily
roll the changes in. Perhaps Jody has more thoughts on this issue? You
should probably collaborate with him and get his ideas on configuration,
and figure out a way to fit loading config files from other sources into
his plans.
I’ve just started looking into geoserver and geotools, so I’ve got to familiarize with the source first…
I’m working on adapting geoserver (especially the wfs part, because we have already a wms server) to an existing gis system. I don’t know if you’ve ever thought about this kind of usage of geoserver. I’m not interested to make fundamental changes to the source, just to adapt it to the existing system (must notably an existing database design). That’s why I’d really welcome it if geoserver and geotools would allow this as painless as possible.
hope this helps,
sure, it did.