Hi all,
When started the config system change, I missed one important thing about
configuring FeatureTypes wich may be can be easily fixed now.
The case is that info.xml holds the definition for a feature type, this
feature type
references the datastore by datastore id, wich is ok. So, FeatureType
configuration
is missing a self ID, other than the type name. Although reffering a featuer
type by its
type name may be enough for most cases, there are situations where one
should want
to expose filtered views of the same type as different "layers", that's when
the feature type id
gains relevance.
So, I think geoserver should manage feature types by a custom id, wich by
default it's ok
to be the same as the feature type.
I expect this can be handled nicely without too much effort.
for example:
Currently, I have a linestring SDE featuretype holding cartographics lines,
with different
meanings depending on the value of the CODE attribute. I am not the db
admin, so I have
to adapt my application to this schema. As I need to expose this type as
different layers
depending on the CODE attribute, the only way I can do that was declaring
different
DataStores with different namespaces and the feature types reffer to one or
other DataStore,
wich is an uggly hack, since both datasotres are identical except for the
namespace:
<datastore id="bizkaia.sde" enabled="true" namespace="bfa">
<description>Magister SDE database</description>
<connectionParams>
<parameter name="dbtype" value="arcsde"/>
<parameter name="server" value="cartodes1"/>
<parameter name="port" value="5151"/>
<parameter name="instance" value="sde"/>
<parameter name="user" value="sde"/>
<parameter name="password" value="carto"/>
<parameter name="pool.minConnections" value="4"/>
<parameter name="pool.maxConnections" value="12"/>
<parameter name="pool.increment" value="2"/>
</connectionParams>
</datastore>
<datastore id="bizkaia.sde2" enabled="true" namespace="bfa2">
<description>Magister SDE database</description>
<connectionParams>
<parameter name="dbtype" value="arcsde"/>
<parameter name="server" value="cartodes1"/>
<parameter name="port" value="5151"/>
<parameter name="instance" value="sde"/>
<parameter name="user" value="sde"/>
<parameter name="password" value="carto"/>
<parameter name="pool.minConnections" value="4"/>
<parameter name="pool.maxConnections" value="12"/>
<parameter name="pool.increment" value="2"/>
</connectionParams>
</datastore>
Now, for declaring the feature types, the definitionQuery manages the
filtered view, but I
have to reffer to different datastores when they should be the same one.
The solution would be something like:
<featureType id="roads" datastore="bizkaia.sde">
...
<featureType id="streets" datastore="bizkaia.sde">
...
---- the first feature type (reffers to bizkaia.sde datastore):
<featureType datastore="bizkaia.sde">
<name>CAMINOS_LINEAS_5000</name>
<SRS>-1</SRS><!-- native wich EPGS code for the FeatureType -->
<title>Lineas de caminos</title>
<abstract>Lineas de caminos, filtrado por CODIGO = B9610</abstract>
<keywords></keywords>
<latLonBoundingBox dynamic="true"/>
<!-- the list of exposed attributes. If the list is empty or not present
at all, all the FeatureType's attributes are exposed, if is present,
only those oattributes in this list will be exposed by the services -->
<attributes>
<attribute name="SHAPE"/>
<attribute name="CODIGO"/>
<attribute name="CODHOJA"/>
</attributes>
<!-- the list of styles this FeatureType can be represented by.
at least must contain the "default" attribute -->
<styles default="secciones"/>
<numDecimals value="2"/>
<definitionQuery>
<Filter>
<PropertyIsEqualTo>
<PropertyName>CODIGO</PropertyName>
<Literal>B9610</Literal>
</PropertyIsEqualTo>
</Filter>
</definitionQuery>
</featureType>
----- the second feature type (reffers to bizkaia.sde2 datastore):
<featureType datastore="bizkaia.sde2">
<name>CARRETERAS_LINEAS_5000</name>
<SRS>-1</SRS>
<title>Aceras</title>
<abstract>Lineas de aceras (CODIGO = B9040)</abstract>
<keywords></keywords>
<latLonBoundingBox dynamic="true"/>
<!-- the list of exposed attributes. If the list is empty or not present
at all, all the FeatureType's attributes are exposed, if is present,
only those oattributes in this list will be exposed by the services -->
<attributes>
<attribute name="SHAPE"/>
<attribute name="CODIGO"/>
<attribute name="CODHOJA"/>
</attributes>
<!-- the list of styles this FeatureType can be represented by.
at least must contain the "default" attribute -->
<styles default="secciones"/>
<numDecimals value="2"/>
<definitionQuery>
<Filter>
<PropertyIsEqualTo>
<PropertyName>CODIGO</PropertyName>
<Literal>B9040</Literal>
</PropertyIsEqualTo>
</Filter>
</definitionQuery>
</featureType>
-----Mensaje original-----
De: Jody Garnett [mailto:jgarnett@anonymised.com]
Enviado el: lunes, 12 de enero de 2004 11:46
Para: geoserver-devel@lists.sourceforge.net; David Zwiers
Asunto: [Geoserver-devel] Config branch winding down
Just a quick note from the depths of night...
We have most of the configuration ui up and running. We are trying to
get DataStore setup perfected before taking on the more complicated
FeatureType/AttributeType screen. David has kindly figured out how to
parse the min/max occurs out of the schema.xml fragments and providing
more work for us on the ui front.
Expected time line:
Monday: merge back onto head & complete FeatureType config
Tuesday: bug stomp/test
Wednesday: an alpha release (even if it is just a zip file)
David I am trying to inflict the GeoTools Catalog API onto GeoServer:
- Data implement Catalog (done!)
- NameSpaceInfo implement NamespaceMetaData
- DataStoreInfo implement DataStoreMetaData
- FeatureTypeInfo implement FeatureTypeMetaData / provide access to
AttributeTypeMetaData
The MetaData classes are in the data module of geotools2, the
geotools.jar in lib has been updated on the config branch.
After that is done if you could kindly begin the merge.
I am sure Richard and I will have some questions about
AttributeTypeConfig when we get in. We could not quite understand your
comments. Near as I can tell I have to throw out one of your three
cases. I need a "name" to drive the UI, and I cannot hunt down the
correct name in a random namespace.
I am hoping we can stay on the head after the merge, it will be more
timely for bug fixes and we will be working on the validation framework
which is not part of the core GeoServer functionality.
Cheers,
Jody
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel