[Geoserver-users] schema and getFeature issues upgrading from 1.5.4 to 1.6.4 WFS 1.1

Sarah_Haskins · June 27, 2008, 5:26pm

Geoserver Users,

I am attempting to upgrade my Geoserver installation from 1.5.4 to 1.6.4b. In our previous 1.5.4 version we placed a schema.xml inside the /data/featureTypes/_ folder to restrict the columns returned in getFeature responses and to provide the specific geometry type in a describeFeature request.

After upgrading (and a lot of debugging into the source code) I discovered that to replicate the schema.xml functionality for a WFS 1.1 describeFeature request I needed to create a schema.xsd file and put into a folder called /data/featureTypes/_. The old schema.xml file still works for a WFS 1.0 request.

However, as soon as I create the /data/featureTypes/_/schema.xsd file, my getFeature requests on that featureType begin to fail with a NullPointerException in org.geotools.gml2.FeaturePropertyExtractor.

Here is the stack trace:

java.lang.NullPointerException
at org.geotools.gml2.FeaturePropertyExtractor.properties(FeaturePropertyExtractor.java:60)
at org.geotools.xml.Encoder.encode(Encoder.java:724)
at org.geotools.xml.Encoder.encode(Encoder.java:471)
at org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:123)
at org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:137)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:629)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:192)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:170)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:595)

My /data/featureTypes/ora_AIRTRAIN/info.xml looks like this…

AIRTRAIN AIRTRAIN 2263 0 Airtrain Generated from ora / AIRTRAIN, ora 0

My /data/featureTypes/doitt_AIRTRAIN/schema.xsd file looks like this…

<xs:schema targetNamespace=“http://gis.nyc.gov” xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:gml=“http://www.opengis.net/gml” elementFormDefault=“qualified” attributeFormDefault=“unqualified”>
<xs:import namespace=“http://www.opengis.net/gml” schemaLocation=“http://geo-dev-1.nycnet:80/geoserver/schemas/gml/2.1.2/feature.xsd”/>
<xs:complexType name = “AIRTRAINType” >
<xs:complexContent >
<xs:extension base = “gml:AbstractFeatureType” >
<xs:sequence >
<xs:element type = “xs:decimal” minOccurs = “1” name = “OBJECTID” nillable = “false” maxOccurs = “1” />
<xs:element type = “xs:string” minOccurs = “1” name = “NAME” nillable = “false” maxOccurs = “1” />
<xs:element type = “xs:string” minOccurs = “1” name = “URL” nillable = “false” maxOccurs = “1” />
<xs:element type = “gml:PointPropertyType” minOccurs = “1” name = “SHAPE” nillable = “false” maxOccurs = “1” >

</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>

My getFeature request looks like this…

<wfs:GetFeature service=“WFS” version=“1.1.0”
xmlns:doitt=“http://gis.nyc.gov”
xmlns:wfs=“http://www.opengis.net/wfs”
xmlns:ogc=“http://www.opengis.net/ogc”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://www.opengis.net/wfs
http://schemas.opengis.net/wfs/1.1.0/wfs.xsd”>
<wfs:Query typeName=“doitt:AIRTRAIN”>
</wfs:Query>
</wfs:GetFeature>

I find it odd that the error is in a GML3 class, when this request should be using GML3. Also, if I change my getFeature request to include outputFormat=“GML2” then it works, but I don’t think that makes sense, I should be able to use GML3, right?

Thanks in advance for any help you can give me in understanding this error or the use/misuse of schema.xsd.

Sincerely,
Sarah

Andrea_Aime3 · June 30, 2008, 8:49am

Sarah Haskins ha scritto:

Geoserver Users,

I am attempting to upgrade my Geoserver installation from 1.5.4 to 1.6.4b. In our previous 1.5.4 version we placed a schema.xml inside the /data/featureTypes/<datastore id>_<featureTypeName> folder to restrict the columns returned in getFeature responses and to provide the specific geometry type in a describeFeature request.

After upgrading (and a lot of debugging into the source code) I discovered that to replicate the schema.xml functionality for a WFS 1.1 describeFeature request I needed to create a schema.xsd file and put into a folder called /data/featureTypes/<namespace>_<featureTypeName>. The old schema.xml file still works for a WFS 1.0 request.

Both schema.xml and schema.xsd are hacks we created in order to be able
and pass the CITE tests but are not really meant to be supported.
I'm not the one that worked on those so I cannot be certain, but I'm
relatively sure of the following:
* gml2 and gml3 code paths are totally different
* the gml3 output format is the only one using schema.xsd
* by the looks at the code, it seems schema.xsd can only be used
to cheat with the type of the properties exposed, but not to hide
existing ones.

It _may_ be that we can fix that to allow it to be used for reducing
the number of properties exposed, can you open a jira request at
jira.codehaus.org?

In any case, I would suggest you try to fix the root of the problem
by making GeoServer publish exactly what you want without any
extra mapping.

Hiding columns can be done by creating a view in your database and
properly registering it against the spatial metadata tables,
as suggested here (end of page):
http://geoserver.org/display/GEOSDOC/Oracle+DataStore

As for getting the specific geometry type, GeoServer can figure
it out provided you specify the proper metadata in the Oracle
spatial index as suggested in the first "Troubleshooting" question
in the same page above (just added the instructions grabbing them
from another thread on this ml).

Hope this helps
Cheers
Andrea

Sarah_Haskins · June 30, 2008, 6:27pm

Thanks Andrea, your response was exactly what I needed. Since I received your response I have:

deleted all of my schema.xml files
deleted all of my schema.xsd files
updated all of my spatial indexes to include the layer_gtype

And voila, I’m now getting the property type returned in my DescribeFeature requests. My next step was to create a view to be used as a feature type (not necessarily to restrict columns, but to restrict rows in this case.)

I created the view:
create view community_board
as select *
from community_district
where has_board = ‘Y’

Added the metadata to user_sdo_geom_metadata:
insert into user_sdo_geom_metadata (table_name, column_name, diminfo, srid)
select ‘COMMUNITY_BOARD’, column_name, diminfo, srid
from user_sdo_geom_metadata where table_name = ‘COMMUNITY_DISTRICT’

The resulting user_sdo_geom_metadata table looks like this:

However, I still get the generic gml:GeometryPropertyType when doing a WFS 1.0 or WFS 1.1 style DescribeFeatureType request.

Any suggestions? Thanks again for the great advice to get me this far.

Sincerely,
Sarah

On Mon, Jun 30, 2008 at 4:49 AM, Andrea Aime <aaime@anonymised.com> wrote:

Sarah Haskins ha scritto:

Geoserver Users,

I am attempting to upgrade my Geoserver installation from 1.5.4 to 1.6.4b. In our previous 1.5.4 version we placed a schema.xml inside the /data/featureTypes/_ folder to restrict the columns returned in getFeature responses and to provide the specific geometry type in a describeFeature request.

After upgrading (and a lot of debugging into the source code) I discovered that to replicate the schema.xml functionality for a WFS 1.1 describeFeature request I needed to create a schema.xsd file and put into a folder called /data/featureTypes/_. The old schema.xml file still works for a WFS 1.0 request.

Both schema.xml and schema.xsd are hacks we created in order to be able
and pass the CITE tests but are not really meant to be supported.
I’m not the one that worked on those so I cannot be certain, but I’m
relatively sure of the following:

gml2 and gml3 code paths are totally different

the gml3 output format is the only one using schema.xsd

by the looks at the code, it seems schema.xsd can only be used
to cheat with the type of the properties exposed, but not to hide
existing ones.

It may be that we can fix that to allow it to be used for reducing
the number of properties exposed, can you open a jira request at
jira.codehaus.org?

In any case, I would suggest you try to fix the root of the problem
by making GeoServer publish exactly what you want without any
extra mapping.

Hiding columns can be done by creating a view in your database and
properly registering it against the spatial metadata tables,
as suggested here (end of page):
http://geoserver.org/display/GEOSDOC/Oracle+DataStore

As for getting the specific geometry type, GeoServer can figure
it out provided you specify the proper metadata in the Oracle
spatial index as suggested in the first “Troubleshooting” question
in the same page above (just added the instructions grabbing them
from another thread on this ml).

Hope this helps
Cheers
Andrea

Andrea_Aime3 · July 1, 2008, 2:32pm

Sarah Haskins ha scritto:

Thanks Andrea, your response was exactly what I needed. Since I received your response I have:
- deleted all of my schema.xml files
- deleted all of my schema.xsd files
- updated all of my spatial indexes to include the layer_gtype

And voila, I'm now getting the property type returned in my DescribeFeature requests. My next step was to create a view to be used as a feature type (not necessarily to restrict columns, but to restrict rows in this case.)

I created the view:
  create view community_board
  as select *
  from community_district
  where has_board = 'Y'

Added the metadata to user_sdo_geom_metadata:
  insert into user_sdo_geom_metadata (table_name, column_name, diminfo, srid)
  select 'COMMUNITY_BOARD', column_name, diminfo, srid
  from user_sdo_geom_metadata where table_name = 'COMMUNITY_DISTRICT'

The resulting user_sdo_geom_metadata table looks like this:

| TABLE_NAME | COLUMN_NAME | DIMINFO | SRID |
| COMMUNITY_BOARD | SHAPE | ((X, 900000, 1090000, 0.0005), (Y, 110000, 295000, 0.0005), , ) | 41088 |
| COMMUNITY_DISTRICT | SHAPE | ((X, 900000, 1090000, 0.0005), (Y, 110000, 295000, 0.0005), , ) | 41088 |

However, I still get the generic gml:GeometryPropertyType when doing a WFS 1.0 or WFS 1.1 style DescribeFeatureType request.

Any suggestions? Thanks again for the great advice to get me this far.

Hum... it may not have been that great given the result.
I looked into the code of the Oracle data store and the geometry
type is determined by querying mdsys.ALL_SDO_INDEX_INFO using
the table name as the search key... in your case, the view name
will be used.
I'm not an Oracle user, is ALL_SDO_INDEX_INFO updatable, that
is, can you fill in the proper metadata for your view?

Cheers
Andrea