Hi,
I was looking into the changes necessary to support
the creation of a new feature type via REST and
found some strong limitations in AttributeTypeInfo
that do not allow even a partial implementation.
The idea was that we could POST a feature type description
to a datastore URL to create the new feature type.
Now, look at the feature type description format here:
http://docs.geoserver.org/stable/en/user/_downloads/featuretype_xml.txt
Seeing anything missing in the attribute type descriptions?
Like... the data type, for example? :-p
In order to support a minimal type creation imho
the attribute type description should contain:
- the data type (as a java class)
- the length restriction (important for any real world
usage of string types)
Very much welcomed would be also the number of decimals
if we want to be able to create NUMBER(x,y) columns
in a database.
Oh hum... looks like a trunk only change to me?
Well, in the meantime I'll play with a type creation GUI :-p
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Oh hum... looks like a trunk only change to me?
Well, in the meantime I'll play with a type creation GUI :-p
Humm... tried to actually use the rest config instead but
I'm getting stuck.
So, I've added the necessary fields to AttributeTypeInfo
and I was expecting to see them appear in the feature types
xml descriptions.
Unfortunately that's not happening. For feture types already
configured, nothing changes, and for the new ones, there
are no attributes at all in the output.
For what I can see the issue is that the rest configuration
is using FeatureTypeInfo.getAttributes(), that is, the stored
ones, instead of calling to FeatureTypeInfo.attributes().
If I'm recalling things right the AttributeTypeInfo were
used only to drive the schema overrides in terms of hiding/showing
an attribute, so trying to use them to actually describe the
attributes in the feature type is probably the wrong way to go?
Or else, some rework is needed in all REST outputs/inputs
to actually make them play the role of the attribute descriptors.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yup it is definitely a limitation that will need to be addressed. Although I don't think it is that outlandish for a first cut to just default column types to string with some preset length, and refine from there.
On 3/18/10 12:42 PM, Andrea Aime wrote:
Hi,
I was looking into the changes necessary to support
the creation of a new feature type via REST and
found some strong limitations in AttributeTypeInfo
that do not allow even a partial implementation.
The idea was that we could POST a feature type description
to a datastore URL to create the new feature type.
Now, look at the feature type description format here:
http://docs.geoserver.org/stable/en/user/_downloads/featuretype_xml.txt
Seeing anything missing in the attribute type descriptions?
Like... the data type, for example? :-p
In order to support a minimal type creation imho
the attribute type description should contain:
- the data type (as a java class)
- the length restriction (important for any real world
usage of string types)
Very much welcomed would be also the number of decimals
if we want to be able to create NUMBER(x,y) columns
in a database.
Oh hum... looks like a trunk only change to me?
Well, in the meantime I'll play with a type creation GUI :-p
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Right, this is done intentionally because we assume that an empty getAttributes() means derive them from the underlying feature type. The reason the persister uses getAttributes() and not attributes() is because if the attributes get stored on disk it then assumes the user has performed a manual override and then any ability to change the underlying feature type dynamically goes bye bye.
That said in some cases we do want to output the derived attribute list, like for REST output. In my opinion I think we should probably just add a flag to XStreamPersister which will control this behaviour. By default leave the behaviour as is but for rest set the flag. We do this with various other things too. See AbstractCatalogResource.createXMLFormat().
-Justin
On 3/18/10 2:24 PM, Andrea Aime wrote:
Andrea Aime ha scritto:
Oh hum... looks like a trunk only change to me?
Well, in the meantime I'll play with a type creation GUI :-p
Humm... tried to actually use the rest config instead but
I'm getting stuck.
So, I've added the necessary fields to AttributeTypeInfo
and I was expecting to see them appear in the feature types
xml descriptions.
Unfortunately that's not happening. For feture types already
configured, nothing changes, and for the new ones, there
are no attributes at all in the output.
For what I can see the issue is that the rest configuration
is using FeatureTypeInfo.getAttributes(), that is, the stored
ones, instead of calling to FeatureTypeInfo.attributes().
If I'm recalling things right the AttributeTypeInfo were
used only to drive the schema overrides in terms of hiding/showing
an attribute, so trying to use them to actually describe the
attributes in the feature type is probably the wrong way to go?
Or else, some rework is needed in all REST outputs/inputs
to actually make them play the role of the attribute descriptors.
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.