On Sun, Nov 7, 2010 at 5:11 AM, Andrea Aime <[email protected]>wrote:
> On Fri, Oct 29, 2010 at 11:18 PM, AugustTown <[email protected]> wrote:
> > None of the above four options generate correct WPS execute response, all
> > returned exception. But what's interesting is that by looking at a sample
> > WPS execute request built with WPS Query Builder, if in option 3
> (reference
> > WFS GetFeature HTTP POST), change the value of xlink:href to
> > "http://geoserver/wfs";, it just worked.
> >
> > My only guess is this is a hard code value to indicate the WFS is from
> the
> > same parent GeoServer instance as WPS, so it figures out where to load
> the
> > GML.
>
> That specific URL makes GeoServer skip the GML encoding and parsing
> entirely,
> and go directly get the data from the data source (the shapefile, the
> database,
> whatever it is). So I guess the issue is parsing related.
>
> However the module has tests that do use a literal collection and a remote
> WFS request too, so not sure why it's not working in your case.
>
> In fact I took one of your examples, the case of a literal collection, run
> it,
> and it worked at the first attempt (request and response contained in
> inline.txt,
> attached).
>
> However I also tried out making a remote WFS 1.1 request as follows:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <wps:Execute version="1.0.0" service="WPS"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://www.opengis.net/wps/1.0.0";
> xmlns:wfs="http://www.opengis.net/wfs";
> xmlns:wps="http://www.opengis.net/wps/1.0.0";
> xmlns:ows="http://www.opengis.net/ows/1.1";
> xmlns:gml="http://www.opengis.net/gml";
> xmlns:ogc="http://www.opengis.net/ogc";
> xmlns:wcs="http://www.opengis.net/wcs/1.1.1";
> xmlns:xlink="http://www.w3.org/1999/xlink";
> xsi:schemaLocation="http://www.opengis.net/wps/1.0.0
> http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd";>
> <ows:Identifier>gt:BufferFeatureCollection</ows:Identifier>
> <wps:DataInputs>
> <wps:Input>
> <ows:Identifier>features</ows:Identifier>
> <wps:Reference mimeType="application/wfs-collection-1.1"
> xlink:href="
> http://demo.opengeo.org/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&BBOX=-75.102613,40.212597,-72.361859,41.512517,EPSG:4326
> "
> method="GET">
> <wps:Body>
> <wfs:GetFeature service="WFS" version="1.0.0" outputFormat="GML2">
> <wfs:Query typeName="topp:giant_polygon"/>
> </wfs:GetFeature>
> </wps:Body>
> </wps:Reference>
> </wps:Input>
> <wps:Input>
> <ows:Identifier>buffer</ows:Identifier>
> <wps:Data>
> <wps:LiteralData>1</wps:LiteralData>
> </wps:Data>
> </wps:Input>
> </wps:DataInputs>
> <wps:ResponseForm>
> <wps:RawDataOutput mimeType="text/xml; subtype=wfs-collection/1.0">
> <ows:Identifier>result</ows:Identifier>
> </wps:RawDataOutput>
> </wps:ResponseForm>
> </wps:Execute>
>
> and this failed with a NullPointerException.
> Investigating why I found out that the parse results in the following
> feature type:
>
> SimpleFeatureTypeImpl http://www.openplans.org/topp:states identified
> extends
> Feature(metaDataProperty:metaDataProperty,description:description,name:name,boundedBy:boundedBy,location:location,the_geom:the_geom,STATE_NAME:STATE_NAME,STATE_FIPS:STATE_FIPS,SUB_REGION:SUB_REGION,STATE_ABBR:STATE_ABBR,LAND_KM:LAND_KM,WATER_KM:WATER_KM,PERSONS:PERSONS,FAMILIES:FAMILIES,HOUSHOLD:HOUSHOLD,MALE:MALE,FEMALE:FEMALE,WORKERS:WORKERS,DRVALONE:DRVALONE,CARPOOL:CARPOOL,PUBTRANS:PUBTRANS,EMPLOYED:EMPLOYED,UNEMPLOY:UNEMPLOY,SERVICE:SERVICE,MANUAL:MANUAL,P_MALE:P_MALE,P_FEMALE:P_FEMALE,SAMP_POP:SAMP_POP)
>
> The thing contains first the standard gml feature properties, one
> being "location", which
> is a geometry. The code grabs the default geometry in order to perform
> the buffering,
> and that breaks because the default geometry is the first one... location.
>
> Justin, do you know if there is any way to get around this issue? The
> default gml
> properties are rarely used. At the very least I guess we should state
> that the default
> geometry is the first geometric attribute besides location.
>
>
Yeah, this issue is indeed a pain. We could pretty easily add an encoding
flag to not output the location (and the other attributes on
AbstractFeatureType). However I could see that leading to issues if someone
actually has an attribute called "location" on their dataset.
So what it happening I guess is that location is considered the default
geometry, and it is null? SimpleFeatureImpl used to handle this case in that
it would look up the first non null geometry when the default is null. But
this logic now lives in SimpleFeaturePropertyAccessor.DEFAULT_GEOMETRY. So
could the code that is doing the buffer or whatever else use an expression
to look up the geometry instead of going directly to
feature.getDefaultGeometry()?
Cheers
> Andrea
>
> -----------------------------------------------------
> Ing. Andrea Aime
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -----------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
