Hi -
I have an installation of GeoServer 2.0.1. In the WFS getCapabilities document,
all the Get and Post URLs end in ".../geoserver/wfs", for example,
<ows:Operation name="GetCapabilities">
−
<ows:DCP>
−
<ows:HTTP>
<ows:Get xlink:href="http://doemo.lib.berkeley.edu:8090/geoserver/wfs"/>
<ows:Post xlink:href="http://doemo.lib.berkeley.edu:8090/geoserver/wfs"/>
</ows:HTTP>
</ows:DCP>
−
<ows:Parameter name="AcceptVersions">
<ows:Value>1.0.0</ows:Value>
<ows:Value>1.1.0</ows:Value>
</ows:Parameter>
−
<ows:Parameter name="AcceptFormats">
<ows:Value>text/xml</ows:Value>
</ows:Parameter>
</ows:Operation>
and these URLs show up in the
metadata as harvested by GeoNetwork for individual features. However, GeoServer
does not recognize this URL. The exception text reads
Could not determine geoserver request from http request [GET /geoserver/wfs]@22979911
org.eclipse.jetty.server.Request@anonymised.com
Is this a configuration problem?
Garey Mills
On Wed, Apr 14, 2010 at 4:57 PM, Garey Mills
<gmills@anonymised.com> wrote:
Hi -
I have an installation of GeoServer 2.0.1. In the WFS getCapabilities
document,
all the Get and Post URLs end in ".../geoserver/wfs", for example,
and these URLs show up in the
metadata as harvested by GeoNetwork for individual features. However,
GeoServer
does not recognize this URL. The exception text reads
Could not determine geoserver request from http request [GET
/geoserver/wfs]@22979911
org.eclipse.jetty.server.Request@anonymised.com
You need to put a request parameter on the end of the URL. For example
http://doemo.lib.berkeley.edu:8090/geoserver/wfs?request=getCapabilities
works just fine. You might want to read the WFS standard
(Web Feature Service - Open Geospatial Consortium) to see how the
specification works.
Ian
--
Ian Turton
Ian -
Thanks for your response. What I don't understand why the URL showing up in the metadata for a feature doesn't have anything in it that qualifies the URL. For example, here is the metadata for one of the features as seen by GeoNetwork
Identification info
Title berklandmarks
Date 2010-04-14T13:21:02
Date type *Revision*: Date identifies when the resource was examined or re-examined and improved or amended
Abstract landmarks in Berkeley
Status *Completed*: Production of the data has been completed
Descriptive keywords (theme).
Descriptive keywords Berkeley , landmarks (theme).
Spatial representation type *Vector*: Vector data is used to represent geographic data
Topic category code Society
Extent
Geographic bounding box
*North bound latitude*
37.875
*West bound longitude*
-122.266
*East bound longitude*
-122.244
*South bound latitude*
37.867
Distribution info
Transfer options
OnLine resource berklandmarks <http://doemo.lib.berkeley.edu:8090/geoserver/wfs>
Data quality info
Hierarchy level *Dataset*: Information applies to the dataset
Metadata
File identifier d92ac77a-4577-4bd5-a77e-56d977503ee0
Language English
Character set *UTF8*: 8-bit variable size UCS Transfer Format, based on ISO/IEC 10646
Hierarchy level *Dataset*: Information applies to the dataset
Date stamp 2010-04-14T13:21:02
Metadata standard name ISO 19115:2003/19139
Metadata standard version 1.0
Metadata author
Individual name Claudius Ptolomaeus
Organisation name The ancient geographes INC
Position name Chief geographer
Role *Point of contact*: Party who can be contacted for acquiring knowledge about or acquisition of the resource
City Alexandria
Country Egypt
Check out the 'onLine Resource'. The URL behind that is only "http://doemo.lib.berkeley.edu:8090/geoserver/wfs"\. Is this to be expected?, is it a GeoNetwork error? or what?
Any help appreciated;
Garey Mills
Ian Turton wrote:
On Wed, Apr 14, 2010 at 4:57 PM, Garey Mills
<gmills@anonymised.com> wrote:
Hi -
I have an installation of GeoServer 2.0.1. In the WFS getCapabilities
document,
all the Get and Post URLs end in ".../geoserver/wfs", for example,
and these URLs show up in the
metadata as harvested by GeoNetwork for individual features. However,
GeoServer
does not recognize this URL. The exception text reads
Could not determine geoserver request from http request [GET
/geoserver/wfs]@22979911
org.eclipse.jetty.server.Request@anonymised.com
You need to put a request parameter on the end of the URL. For example
http://doemo.lib.berkeley.edu:8090/geoserver/wfs?request=getCapabilities
works just fine. You might want to read the WFS standard
(http://www.opengeospatial.org/standards/wfs) to see how the
specification works.
Ian
On 4/14/10 7:03 PM, Garey Mills wrote:
Ian -
Thanks for your response. What I don't understand why the URL
showing up in the metadata for a feature doesn't have anything in it
that qualifies the URL. For example, here is the metadata for one of
the features as seen by GeoNetwork
I suspect that's because with the featuretype name and the service end point you have all you need to operate with it. If at all, I would expect some kind of indication of what kind of service it refers to, either WFS/WCS/WMS etc.
All in all, it looks more like a question for the GeoNetwork community, but my gut feeling is that the online resource is alright as long as it provides you the service end point and the type name so you can operate with it.
My 2c
Gabriel
On 4/15/10 9:47 AM, Gabriel Roldan wrote:
On 4/14/10 7:03 PM, Garey Mills wrote:
Ian -
Thanks for your response. What I don't understand why the URL
showing up in the metadata for a feature doesn't have anything in it
that qualifies the URL. For example, here is the metadata for one of
the features as seen by GeoNetwork
I suspect that's because with the featuretype name and the service end
point you have all you need to operate with it. If at all, I would
expect some kind of indication of what kind of service it refers to,
either WFS/WCS/WMS etc.
All in all, it looks more like a question for the GeoNetwork community,
but my gut feeling is that the online resource is alright as long as it
provides you the service end point and the type name so you can operate
with it.
By looking at the getcaps document, it seems you still won't be able to hit the featuretype only with the information provided by geonetwork. For instance, it lists the title of the feature type (human readable name), but not its name, which is UCB:berklandmarks, not just berklandmarks.
So yeah, it looks to me like you'll have to ask on the geonetwork mailing list (subscribe at <https://lists.sourceforge.net/lists/listinfo/geonetwork-users>\).
Cheers,
Gabriel
My 2c
Gabriel
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.