I have also wished to see the amount of configuration required be reduced, generating based on FeatureType is a wonderful idea.
I have tried to start a Catalog api in geotools2 that would hold the kind of information required. I have not managed to port
FeatureTypeInfo
over yet - but it is certaintly where I would start.
FeatureTypeInfo seems to be pretty specific to JDBCDataStore. Therefore
it seems to make more sense to add it directly to FeatureType. Of
course, I may be missing something. I'm pretty new to
geoserver/geotools...
Hmm I was thinking FeatureTypeInfo had the metadata url, and other "Catalog" information that GeoServer cannot get from FeatureType. There is a Catalog OGC Specification that may serve as a starting off.
Just having a look at things again...
I think I meant FeatureTypeConfig on the wms-branch. I have only been working on GeoServer for a couple of weeks and already things have changed names on me
BasicConfig has:
-name
-title
-_abstract
-keywords
-fees
-accessConstraints
-maintainer
FeatureTypeConfig has:
-DataStoreConfig (called dataStore!)
-bbox
-latLongBBox
-SRS - I wonder if this should be a CoordinateReferenceSystem?)
-definitionQuery = Filter.NONE so everything
-schema (the GeoTools2 FeatureType)
-styles
-defaultStyle
-pathToSchemaFile (this is the content you are trying to generate?)
-prefix
-numDecimals
All of this information is data about the Schema (gt2 FeatureType) that GeoServer needs to work?
I did not see the metadata url I was expecting - is that one of the entries in the "schemaFile"?
I am under the impression that FeatureType (the gt2 class) was defined by the OGC Simple Feature Specification. I am not sure we can add more information to FeatureType.
I think the SchemaFile is part of the Catalog information that GeoServer provides, and has its own specification to follow.
I quickly get lost between all of the specifications. It would be nice if Geotools2/GeoServer made a note of the OGC specification they were using at the top of each file.
I think I meant FeatureTypeConfig on the wms-branch. I have only been
working on GeoServer for a couple of weeks and already things have
changed names on me
BasicConfig has:
-name
-title
-_abstract
-keywords
-fees
-accessConstraints
-maintainer
FeatureTypeConfig has:
-DataStoreConfig (called dataStore!)
-bbox
-latLongBBox
-SRS - I wonder if this should be a CoordinateReferenceSystem?)
-definitionQuery = Filter.NONE so everything
-schema (the GeoTools2 FeatureType)
-styles
-defaultStyle
-pathToSchemaFile (this is the content you are trying to generate?)
-prefix
-numDecimals
All of this information is data about the Schema (gt2 FeatureType) that
GeoServer needs to work?
I did not see the metadata url I was expecting - is that one of the
entries in the "schemaFile"?
No, it's not an entry in schemaFile. It needs to be added. It was in
earlier versions of FeatureTypeInfo, but I took it out because we weren't
doing anything with it, it was just useless. What I wanted to do was to
link it up with the z39.50 module, which is FGDC metadata clearinghouse
node, and to work requires a metadata document. So if it's being used
then we will have html documents of metadata - we just need to figure out
a way to make them available and to reference them from the metadata url.
I removed it because it's an optional element, and it seemed silly to me
to include it if it's just ignored.
Of course the ideal solution is a full catalog service built on top of
geotools catalog, with a FeatureTypeInfo (in geotools). And it would
either have a way to turn itself into various metadata formats or at least
have references to the formats. And it'd be integrated with the z39.50
work done now in geoserver (which could use a nice update).
I am under the impression that FeatureType (the gt2 class) was defined
by the OGC Simple Feature Specification. I am not sure we can add more
information to FeatureType.
I personally don't think it'd be bad to add a FeatureTypeInfo class
reference to FeatureType, but that's more of an issue for geotools. We
can bring it up at the next irc.
I quickly get lost between all of the specifications. It would be nice
if Geotools2/GeoServer made a note of the OGC specification they were
using at the top of each file.
I'd be a fan of that, would be a nice policy. Bring that up as well at
the next irc and/or send an email. It would be very nice to know where
the core interfaces got their inspiration from, what the thinking behind
the methods was.
Chris
Jody
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
