[Geoserver-devel] question about schema.xml file...

GeoServer GeoServer Developer
1

hi all,

i'd like to ask you a question concerning schema.xml file and the DescribeFeatureType request...

i tried to modify, via the web interface, one of my data's schema....

so i modify the "Schema Base" and then for all "myFeature"'s attibutes i set "nilable" to false.

then, when i performed a "DescribeFeatureType" request, the response schema shows all the attributes with "nillable" set to true....
wihle the schema.xml file generated is correct (located at /geoserver/data/featureTypes/myFeature/scema.xml)...

so my question is : is the schema.xml file used by geoserver when answering a "DescribeFeatureType" request ? or esle how does the schema is produced ?

thanks in advance.

antoine.

2

hi all,

i'd like to ask you a question concerning schema.xml file and the DescribeFeatureType request...

i tried to modify, via the web interface, one of my data's schema....

so i modify the "Schema Base" and then for all "myFeature"'s attibutes i set "nilable" to false.

then, when i performed a "DescribeFeatureType" request, the response schema shows all the attributes with "nillable" set to true....
wihle the schema.xml file generated is correct (located at /geoserver/data/featureTypes/myFeature/scema.xml)...

so my question is : is the schema.xml file used by geoserver when answering a "DescribeFeatureType" request ? or esle how does the schema is produced ?

thanks in advance.

antoine.

hi all,

i apologize for the last mail... answers about how schema.xml file is used are in the geoserver documentation...

but, there is still a thing i do not understand : it seems that the schema.xml file generated after modification in the web interface is ignore by geoserver when answering a "DescribeFeatureType" request (attributes with "nillable" set to true in the answer while set to false in the file). even if i create and then deploy a "geoserver.war" file with the "schema.xml" file in the "data/featureTypes/mydatastore_myfeature" directory the schema shown does not correspond.... more over, "myfeature" is a table in a postgis database and all attributes do have the "NOT NULL" constraint !

so i wonder how the schema is produced....

once again i apologize for wirting a mail before reading the documentation.

thanks in advance.

antoine.

3

> hi all,
>
> i'd like to ask you a question concerning schema.xml file and the
> DescribeFeatureType request...
>
> i tried to modify, via the web interface, one of my data's schema....
>
> so i modify the "Schema Base" and then for all "myFeature"'s attibutes
> i set "nilable" to false.
>
> then, when i performed a "DescribeFeatureType" request, the response
> schema shows all the attributes with "nillable" set to true....
> wihle the schema.xml file generated is correct (located at
> /geoserver/data/featureTypes/myFeature/scema.xml)...
>
> so my question is : is the schema.xml file used by geoserver when
> answering a "DescribeFeatureType" request ? or esle how does the
> schema is produced ?
>
> thanks in advance.
>
> antoine.

hi all,

i apologize for the last mail... answers about how schema.xml file is
used are in the geoserver documentation...

but, there is still a thing i do not understand : it seems that the
schema.xml file generated after modification in the web interface is
ignore by geoserver when answering a "DescribeFeatureType" request
(attributes with "nillable" set to true in the answer while set to false
in the file). even if i create and then deploy a "geoserver.war" file
with the "schema.xml" file in the
"data/featureTypes/mydatastore_myfeature" directory the schema shown
does not correspond.... more over, "myfeature" is a table in a postgis
database and all attributes do have the "NOT NULL" constraint !

so i wonder how the schema is produced....

once again i apologize for wirting a mail before reading the documentation.

No need to apologize, this is a confusing area of geoserver, and indeed I
am not exactly sure how it works, even though I wrote decent parts of the
code. THe thing I am no longer sure about is if/when we actually return
the schema.xml file completely, and when GeoSErver users it to inform its
generation. The way we meant to code it, as far as I remember, was to
return the schema.xml file directly if it was present, and to generate it
if it was not. But this may have been a bit subverted, since we end up
using schema.xml information to control other parts of the application.
In your case what we really should be doing is generating nillable
information from GeoTools, generating the not null stuff on the fly. But
since we are not there yet, then your schema.xml file should be used, and
if it is not, if geoserver is doing generation from postgis (and
imperfect generation at that) then thats a bug. I will try to look into
it soon (and submit it to the task tracker if youc ould, so I dont forget
about it).

In addition, nillable is a particularly tricky case, where the ogc specs
dont quite match up with XML intentions precisely. Basically in xml I am
pretty sure that if you allow nills then you are supposed to return an XML
nil type. But for the CITE tests of the OGC they dont check for
nilleable, they check to make sure that its not included in the response.
Granted for your case this doesnt matter, as you do not want to allow
nills. But yes, basically we do have more work to do on getting the
DescribeFeatureTypes to have more control and exactly reflect the backend,
though user customization of the schema.xml file _should_ work, and I will
look into it for the next release. And could you try one thing for me?
Try not working through the web administration interface at all, and see
if you can hand edit the schema.xml file and have that one return.
Because if that works then it can help me narrow down the problem, to the
web admin interface clobbering stuff.

best regards,

Chris

thanks in advance.

antoine.

-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

4

Chris Holmes wrote:

No need to apologize, this is a confusing area of geoserver, and indeed I am not exactly sure how it works, even though I wrote decent parts of the code. THe thing I am no longer sure about is if/when we actually return the schema.xml file completely, and when GeoSErver users it to inform its generation. The way we meant to code it, as far as I remember, was to return the schema.xml file directly if it was present, and to generate it if it was not. But this may have been a bit subverted, since we end up using schema.xml information to control other parts of the application. In your case what we really should be doing is generating nillable information from GeoTools, generating the not null stuff on the fly. But since we are not there yet, then your schema.xml file should be used, and if it is not, if geoserver is doing generation from postgis (and imperfect generation at that) then thats a bug. I will try to look into it soon (and submit it to the task tracker if youc ould, so I dont forget about it).

thanks for the explainations chris.
i submit the bug to the task tracker...

In addition, nillable is a particularly tricky case, where the ogc specs dont quite match up with XML intentions precisely. Basically in xml I am pretty sure that if you allow nills then you are supposed to return an XML nil type. But for the CITE tests of the OGC they dont check for nilleable, they check to make sure that its not included in the response. Granted for your case this doesnt matter, as you do not want to allow nills. But yes, basically we do have more work to do on getting the DescribeFeatureTypes to have more control and exactly reflect the backend, though user customization of the schema.xml file _should_ work, and I will look into it for the next release. And could you try one thing for me? Try not working through the web administration interface at all, and see if you can hand edit the schema.xml file and have that one return. Because if that works then it can help me narrow down the problem, to the web admin interface clobbering stuff.

i created schema.xml file (one similar to the DescribeFeatureType response and another just minimal as explain in the documentation) that i put in the
featureType directory... then i created a new geoserver.war that i deployed...
but when i performed i DescribeFeatureType request it is always the same schema that it is shown...
completely different from the one i edit !

maybe it is because of my datas...
but i'd like to understand how the schema is produced by geoserver so that i can see where
there is a problem with the datas.

thanks in advance.

antoine.

best regards,

Chris

5

Sorry for the late response, I haven't been able to get on internet since
wednesday.

----- Original Message -----
From: "Antoine Hnawia" <antoine.hnawia@anonymised.com>
To: <geoserver-devel@lists.sourceforge.net>
Sent: Wednesday, November 17, 2004 4:28 AM
Subject: Re: [Geoserver-devel] question about schema.xml file... apologize

Chris Holmes wrote:

>No need to apologize, this is a confusing area of geoserver, and indeed

I

>am not exactly sure how it works, even though I wrote decent parts of

the

>code. THe thing I am no longer sure about is if/when we actually

return

>the schema.xml file completely, and when GeoSErver users it to inform

its

>generation. The way we meant to code it, as far as I remember, was to
>return the schema.xml file directly if it was present, and to generate

it

>if it was not. But this may have been a bit subverted, since we end up
>using schema.xml information to control other parts of the application.
>In your case what we really should be doing is generating nillable
>information from GeoTools, generating the not null stuff on the fly.

But

>since we are not there yet, then your schema.xml file should be used,

and

>if it is not, if geoserver is doing generation from postgis (and
>imperfect generation at that) then thats a bug. I will try to look

into

>it soon (and submit it to the task tracker if youc ould, so I dont

forget

>about it).
>
>
>
thanks for the explainations chris.
i submit the bug to the task tracker...

Cool. Thanks.

>In addition, nillable is a particularly tricky case, where the ogc

specs

>dont quite match up with XML intentions precisely. Basically in xml I

am

>pretty sure that if you allow nills then you are supposed to return an

XML

>nil type. But for the CITE tests of the OGC they dont check for
>nilleable, they check to make sure that its not included in the

response.

>Granted for your case this doesnt matter, as you do not want to allow
>nills. But yes, basically we do have more work to do on getting the
>DescribeFeatureTypes to have more control and exactly reflect the

backend,

>though user customization of the schema.xml file _should_ work, and I

will

>look into it for the next release. And could you try one thing for me?
>Try not working through the web administration interface at all, and

see

>if you can hand edit the schema.xml file and have that one return.
>Because if that works then it can help me narrow down the problem, to

the

>web admin interface clobbering stuff.
>
>
>

i created schema.xml file (one similar to the DescribeFeatureType
response and another just minimal as explain in the documentation) that
i put in the
featureType directory... then i created a new geoserver.war that i
deployed...
but when i performed i DescribeFeatureType request it is always the same
schema that it is shown...
completely different from the one i edit !

Yeah, that is definitely a bug, I'll tackle it in the next week or two.

maybe it is because of my datas...
but i'd like to understand how the schema is produced by geoserver so
that i can see where
there is a problem with the datas.

I don't think it's a problem with your data, I think it's just that
geotools, the library that we use, does not detect enough information
about the data. So the way the DescribeFeatureType response is done is to
use the FeatureType created by GeoTools. The FeatureType is created from
the JDBC DatabaseMetaData and the geometry_columns table of Postgis. But
it does not quite use all the information it could, like NOT NULL. It
probably should, indeed there is more meta information we could get from
the database, like the length of the Strings, and some other stuff. But
none of that has been a high enough priority to implement, as for
GeoServer we're supposed to allow users to edit their schema.xml file for
more complex stuff. Which I will fix. So for PostGIS the class that
constructs the FeatureType is in
gt/plugin/postgis/src/org/geotools/data/postigs/PostgisDataStore.java And
then
gt/module/main/src/org/geotools/gml/producer/FeatureTypeTransformer.java
is the class that turns the FeatureType to the actual XMLSchema
(DescribeFeatureType response). For the NOT NULL stuff I thought about it
awhile ago, and added nilleable to the AttributeType in GeoTools, but
never got around to actually using it. If you wanted to you could
probably add it to the FeatureTypeTransformer without too much difficulty.
I can give you more hints on how to do this if you're interested. But I
also should just fix the schema.xml bug, as it should be returned, as
there are cases more complicated than NOT NULL.

best regards,

Chris

--