[Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

GeoServer GeoServer User
1

Hi list,

I’m looking into implementing the possibility to get only the bbox (same as envelope?) of the result of a GetFeature request. I need some help to find out a good way to do it.

I have already made an outputformat extension named “onlybbox” and it works fine. But it doesn’t feel right because it’s not a real format :slight_smile:

A more obvious way would be to create a new ResultType but it seems problematic. There are two resulttypes in the WFS 1.1 spec and they are “results” and “hits”. A new one called “bbox” would be the neatest way. But the spec does not seem to allow this as the WFS schema has a ResultTypeType that only allows the two values “results” and “hits”.

This means that the geoserver (or geotools?) code parses the resultType attribute of the query as a ResultTypeType object and this object is final and can’t be overloaded with my new type “bbox” added. And even if it was possible it would not follow the spec.

Does anyone have an idea of how to achieve this in a nice way? Do I have to do a GetBbox operation in order to not go against the spec?

Regards

Albin

2

Lundmark Albin wrote:

I’m looking into implementing the possibility to get only the bbox (same as envelope?) of the result of a GetFeature request. I need some help to find out a good way to do it.

I have already made an outputformat extension named “onlybbox” and it works fine. But it doesn’t feel right because it’s not a real format :slight_smile:

A "format" can really be whatever you want, and gives you complete
control of what you're generating.
If you created a new output type, you'd stumble in existing output
formats that do have no way to state the bbox to get started with,
plus the code in existing output formats returns the bounds of the
feature collection and then dumps the feature collection, so you'd
have to make a sort of inner hack, wrap a collection so that it
returns the bbox and count, but not the features.

Plus, the collection bbox is something that is normally not generated,
unless you configure wfs to do so (feature bounding) because in some
cases you have so many features that just counting them takes minutes
(imagine how happy the db admin is going to be seeing his db server
bring down to his knees because five users with uDig are trying to hit GeoServer and gathering back the whole collection).

All in all it seems to me the output format is the path of least
resistance, and the cleanest one as well, as it severely reduces
the amount of interaction with the other GeoServer moving parts.

We were actually discussing something similar for WMS, a sort of
a "description" output format that among the others gives you
the bbox of each layer taking into account the current filters
and style.
For WFS it could get similar, a GetFeature request can request
more than one typeName (in its xml POST form), so a general
"bbox" output format would have to dump one bbox per type
anyways. And it could provide the count as well. If the admin
does not like the possible consequences of it, he can always
get rid of the output format.

Soo... interested in contributing back your work? :wink:

Cheers
Andrea

3

Hi Albin,

There are a couple of ways we could approach this. One way could be to include the bounding box when result type = hits. I don't think there is anything in the spec that disallows this.

If the spec does say that the bounds should not be included then we could perhaps add a format option to explicitly enable that option. For instance something like:

...request=getfeature&resulttype=hits&format_options=bounds:true

Either way I think the only change required would be to the HitsOutputFormat class. There may be a tweak necessary to the geotools feature encoding classes as well.

What are your thoughts on this solution? Or do you still think a separate value for resulttype is necessary?

-Justin

Lundmark Albin wrote:

Hi list,

I’m looking into implementing the possibility to get only the bbox (same as envelope?) of the result of a GetFeature request. I need some help to find out a good way to do it.

I have already made an outputformat extension named “onlybbox” and it works fine. But it doesn’t feel right because it’s not a real format :slight_smile:

A more obvious way would be to create a new ResultType but it seems problematic. There are two resulttypes in the WFS 1.1 spec and they are “results” and “hits”. A new one called “bbox” would be the neatest way. But the spec does not seem to allow this as the WFS schema has a ResultTypeType that only allows the two values “results” and “hits”.

This means that the geoserver (or geotools?) code parses the resultType attribute of the query as a ResultTypeType object and this object is final and can’t be overloaded with my new type “bbox” added. And even if it was possible it would not follow the spec.

Does anyone have an idea of how to achieve this in a nice way? Do I have to do a GetBbox operation in order to not go against the spec?

Regards

Albin

------------------------------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

Hi Justin,

Thanks for your response.

The WFS 1.1 specification say like this:
"If, however, the value of the resultType attribute is specified as hits, a web feature service must generate a <wfs:FeatureCollection> element with no content (i.e. empty) but must populate the values of the timeStamp attribute and the numberOfFeatures attribute."

I guess that means we can't put a bounding box element inside the FeatureCollection in the ordinary resultType=hits case. Or how do you interpret it?

So maybe the format_options is the way to do it. I've read what is written at http://geoserver.org/display/GEOSDOC/Format+Options and also your discussion in the dev-list linked from that page.

I can see that you implemented the format_options parameter for GET requests and there's no problem to get hold of them from the HitsOutputFormat class. What was your conclusion about format_options and POSTs?

After looking a little into the code it seems like the main challenge would be how to alter the Encoder class :slight_smile:

//Albin

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Mon 3/2/2009 6:48 PM
To: Lundmark Albin
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

Hi Albin,

There are a couple of ways we could approach this. One way could be to
include the bounding box when result type = hits. I don't think there is
anything in the spec that disallows this.

If the spec does say that the bounds should not be included then we
could perhaps add a format option to explicitly enable that option. For
instance something like:

...request=getfeature&resulttype=hits&format_options=bounds:true

Either way I think the only change required would be to the
HitsOutputFormat class. There may be a tweak necessary to the geotools
feature encoding classes as well.

What are your thoughts on this solution? Or do you still think a
separate value for resulttype is necessary?

-Justin

Lundmark Albin wrote:

Hi list,

I'm looking into implementing the possibility to get only the bbox (same
as envelope?) of the result of a GetFeature request. I need some help to
find out a good way to do it.

I have already made an outputformat extension named "onlybbox" and it
works fine. But it doesn't feel right because it's not a real format :slight_smile:

A more obvious way would be to create a new ResultType but it seems
problematic. There are two resulttypes in the WFS 1.1 spec and they are
"results" and "hits". A new one called "bbox" would be the neatest way.
But the spec does not seem to allow this as the WFS schema has a
ResultTypeType that only allows the two values "results" and "hits".

This means that the geoserver (or geotools?) code parses the resultType
attribute of the query as a ResultTypeType object and this object is
final and can't be overloaded with my new type "bbox" added. And even if
it was possible it would not follow the spec.

Does anyone have an idea of how to achieve this in a nice way? Do I have
to do a GetBbox operation in order to not go against the spec?

Regards

Albin

------------------------------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

All in all it seems to me the output format is the path of least
resistance, and the cleanest one as well, as it severely reduces
the amount of interaction with the other GeoServer moving parts.

Hmmm I disagree here. A new "format" to me means a new exchange format, mime type, etc... This is just a variation on of the gml format, just like resultType = "hits". While I do agree that implementing a new output format would be simplest from an implementation point of view, I think from a protocol point of view it really fits in better as a new result type, or a modification of the hits result type.

Also consider acheiving this same functionality with json, rather than gml. Do we have two formats? boxgml, and boxjson? Seems wrong to me.

My 2c.

-Justin

We were actually discussing something similar for WMS, a sort of
a "description" output format that among the others gives you
the bbox of each layer taking into account the current filters
and style.
For WFS it could get similar, a GetFeature request can request
more than one typeName (in its xml POST form), so a general
"bbox" output format would have to dump one bbox per type
anyways. And it could provide the count as well. If the admin
does not like the possible consequences of it, he can always
get rid of the output format.

Soo... interested in contributing back your work? :wink:

Cheers
Andrea

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

Lundmark Albin wrote:

Hi Justin,

Thanks for your response.

The WFS 1.1 specification say like this:
"If, however, the value of the resultType attribute is specified as hits, a web feature service must generate a <wfs:FeatureCollection> element with no content (i.e. empty) but must populate the values of the timeStamp attribute and the numberOfFeatures attribute."

I guess that means we can't put a bounding box element inside the FeatureCollection in the ordinary resultType=hits case. Or how do you interpret it?

I guess it depends on how you interpret an "empty" feature collection. Does empty mean no xml elements inside of it? Or does it mean no featureMembers? Not sure myself. I Think the best thing to do would be to query the wfs-dev list (wfs-dev@anonymised.com). That is where the spec writers lurk and can give us a definitive answer.

So maybe the format_options is the way to do it. I've read what is written at http://geoserver.org/display/GEOSDOC/Format+Options and also your discussion in the dev-list linked from that page.

I can see that you implemented the format_options parameter for GET requests and there's no problem to get hold of them from the HitsOutputFormat class. What was your conclusion about format_options and POSTs?

Well it is possible to specify kvp parameters in a POST request. GeoServer does this with the "strict" parameter to validate POST requests. So doing:

POST http://…/geoserver/wfs?format_options=…

<wfs:GetFeature>...</wfsGetFeature>

Should work ok.

After looking a little into the code it seems like the main challenge would be how to alter the Encoder class :slight_smile:

I think it would be doable without actually modifying the Encoder class, but some simple modifications to the HitsOutputFormat class (if that was the chosen route). Basically just to get add an "empty" feature collection which still returns a bounds. This could be done with an anonymous subclass of DefaultFeatureCollection which overrides bounds to return the appropriate bounds.

Looking into the code I think I just found a bug in that FeatureCollectionTypeBinding never encodes the bounding box. With this fixed I believe it would work as suggested.

If you were interested in implementing such an improvement it would be a welcome contribution :).

//Albin

-----Original Message-----
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Mon 3/2/2009 6:48 PM
To: Lundmark Albin
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result
Hi Albin,

There are a couple of ways we could approach this. One way could be to include the bounding box when result type = hits. I don't think there is anything in the spec that disallows this.

If the spec does say that the bounds should not be included then we could perhaps add a format option to explicitly enable that option. For instance something like:

...request=getfeature&resulttype=hits&format_options=bounds:true

Either way I think the only change required would be to the HitsOutputFormat class. There may be a tweak necessary to the geotools feature encoding classes as well.

What are your thoughts on this solution? Or do you still think a separate value for resulttype is necessary?

-Justin

Lundmark Albin wrote:

Hi list,

I'm looking into implementing the possibility to get only the bbox (same as envelope?) of the result of a GetFeature request. I need some help to find out a good way to do it.

I have already made an outputformat extension named "onlybbox" and it works fine. But it doesn't feel right because it's not a real format :slight_smile:

A more obvious way would be to create a new ResultType but it seems problematic. There are two resulttypes in the WFS 1.1 spec and they are "results" and "hits". A new one called "bbox" would be the neatest way. But the spec does not seem to allow this as the WFS schema has a ResultTypeType that only allows the two values "results" and "hits".

This means that the geoserver (or geotools?) code parses the resultType attribute of the query as a ResultTypeType object and this object is final and can't be overloaded with my new type "bbox" added. And even if it was possible it would not follow the spec.

Does anyone have an idea of how to achieve this in a nice way? Do I have to do a GetBbox operation in order to not go against the spec?

Regards

Albin

------------------------------------------------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

Justin Deoliveira wrote:

All in all it seems to me the output format is the path of least
resistance, and the cleanest one as well, as it severely reduces
the amount of interaction with the other GeoServer moving parts.

Hmmm I disagree here. A new "format" to me means a new exchange format, mime type, etc... This is just a variation on of the gml format, just like resultType = "hits". While I do agree that implementing a new output format would be simplest from an implementation point of view, I think from a protocol point of view it really fits in better as a new result type, or a modification of the hits result type.

Also consider acheiving this same functionality with json, rather than gml. Do we have two formats? boxgml, and boxjson? Seems wrong to me.

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Cheers
Andrea

8

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Well I would just assume that geojson supports some notion of a bounding box but I could be wrong. For other formats in which there are no standard representing spatial information (csv, excel) a bounding representation could be mocked up. A single row with 5 columns sort of thing.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

9

Justin Deoliveira wrote:

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Well I would just assume that geojson supports some notion of a bounding box but I could be wrong. For other formats in which there are no standard representing spatial information (csv, excel) a bounding representation could be mocked up. A single row with 5 columns sort of thing.

For excel, I have my hands free, but for csv, that would break its "single table" nature. It could be eventually
included as part of a comment, hacky, but workable.

For GeoJSON, yep, there is an optional element that can be used,
called bbox:
http://geojson.org/geojson-spec.html#bounding-boxes

Mind that by default we don't generate the bounds (see recent patches
to avoid killing the server in case you're working with multi-million
feature collections), so this new result type would have to either
override the server configuration, or just not work in case the
admin disabled feature bounding.
In the case of a server providing millions of features per type
as an admin I would certainly like to have some control on that kind of setting and eventually disable it so that nobody can slam my server
with non interruptible jdbc queries that can take minutes to be run.

Cheers
Andrea

10

Andrea Aime wrote:

Justin Deoliveira wrote:

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Well I would just assume that geojson supports some notion of a bounding box but I could be wrong. For other formats in which there are no standard representing spatial information (csv, excel) a bounding representation could be mocked up. A single row with 5 columns sort of thing.

For excel, I have my hands free, but for csv, that would break its "single table" nature. It could be eventually
included as part of a comment, hacky, but workable.

For GeoJSON, yep, there is an optional element that can be used,
called bbox:
http://geojson.org/geojson-spec.html#bounding-boxes

Mind that by default we don't generate the bounds (see recent patches
to avoid killing the server in case you're working with multi-million
feature collections), so this new result type would have to either
override the server configuration, or just not work in case the
admin disabled feature bounding.

Sure that sounds reasonable. Give the server administrator final authority to turn the feature off. Or just take the meaning of featureBounding = false to mean never ever calculate bounds. And if the client asks for it throw a service exception.

In the case of a server providing millions of features per type
as an admin I would certainly like to have some control on that kind of setting and eventually disable it so that nobody can slam my server
with non interruptible jdbc queries that can take minutes to be run.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

11

Justin, I'll try your suggestion with a empty feature collection that still returns a bounding box.

You mensioned a bug with encoding the bounding box. Is it fixed in 1.7.x now that http://jira.codehaus.org/browse/GEOS-2583 is fixed??

And if I get it to work we can deside on the "correct" way to get into the structure. For now I'll try the "Hits"-way with format_options.

//Albin

-----Ursprungligt meddelande-----
Från: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Skickat: den 3 mars 2009 17:16
Till: Andrea Aime
Kopia: Lundmark Albin; geoserver-users@lists.sourceforge.net
Ämne: Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

Andrea Aime wrote:

Justin Deoliveira wrote:

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Well I would just assume that geojson supports some notion of a
bounding box but I could be wrong. For other formats in which there
are no standard representing spatial information (csv, excel) a
bounding representation could be mocked up. A single row with 5
columns sort of thing.

For excel, I have my hands free, but for csv, that would break its
"single table" nature. It could be eventually
included as part of a comment, hacky, but workable.

For GeoJSON, yep, there is an optional element that can be used,
called bbox:
http://geojson.org/geojson-spec.html#bounding-boxes

Mind that by default we don't generate the bounds (see recent patches
to avoid killing the server in case you're working with multi-million
feature collections), so this new result type would have to either
override the server configuration, or just not work in case the
admin disabled feature bounding.

Sure that sounds reasonable. Give the server administrator final
authority to turn the feature off. Or just take the meaning of
featureBounding = false to mean never ever calculate bounds. And if the
client asks for it throw a service exception.

In the case of a server providing millions of features per type
as an admin I would certainly like to have some control on that kind of
setting and eventually disable it so that nobody can slam my server
with non interruptible jdbc queries that can take minutes to be run.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

Hi Albin,

Yes, GEOS-2583 was recently fixed for 1.7.3 so that should be one less hurdle for you to jump.

As for the correct way, I stand by the outputFormat="hits" with format_options because 1) it is the least amount of code and 2) imho nicest from a protocol stand point.

Unless Andrea or anyone else strongly disagrees I suggest going that route.

-Justin

Lundmark Albin wrote:

Justin, I'll try your suggestion with a empty feature collection that still returns a bounding box.

You mensioned a bug with encoding the bounding box. Is it fixed in 1.7.x now that http://jira.codehaus.org/browse/GEOS-2583 is fixed??

And if I get it to work we can deside on the "correct" way to get into the structure. For now I'll try the "Hits"-way with format_options.

//Albin

-----Ursprungligt meddelande-----
Från: Justin Deoliveira [mailto:jdeolive@anonymised.com] Skickat: den 3 mars 2009 17:16
Till: Andrea Aime
Kopia: Lundmark Albin; geoserver-users@lists.sourceforge.net
Ämne: Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

Andrea Aime wrote:

Justin Deoliveira wrote:

Hmm... you are assuming all formats are actually able to return a
bbox information. Not sure if json does, csv and excel most definitely
won't. So you'd end up with a new resultType that works only with a
specific output format (gml), and in order to get it working, you'd have
to modify core code instead of adding a new peripheral change.
Kinda feels like using a cannon to hit a small bird :wink:

Well I would just assume that geojson supports some notion of a bounding box but I could be wrong. For other formats in which there are no standard representing spatial information (csv, excel) a bounding representation could be mocked up. A single row with 5 columns sort of thing.

For excel, I have my hands free, but for csv, that would break its "single table" nature. It could be eventually
included as part of a comment, hacky, but workable.

For GeoJSON, yep, there is an optional element that can be used,
called bbox:
http://geojson.org/geojson-spec.html#bounding-boxes

Mind that by default we don't generate the bounds (see recent patches
to avoid killing the server in case you're working with multi-million
feature collections), so this new result type would have to either
override the server configuration, or just not work in case the
admin disabled feature bounding.

Sure that sounds reasonable. Give the server administrator final authority to turn the feature off. Or just take the meaning of featureBounding = false to mean never ever calculate bounds. And if the client asks for it throw a service exception.

In the case of a server providing millions of features per type
as an admin I would certainly like to have some control on that kind of setting and eventually disable it so that nobody can slam my server
with non interruptible jdbc queries that can take minutes to be run.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

13

Justin Deoliveira ha scritto:

Hi Albin,

Yes, GEOS-2583 was recently fixed for 1.7.3 so that should be one less hurdle for you to jump.

As for the correct way, I stand by the outputFormat="hits" with format_options because 1) it is the least amount of code and 2) imho nicest from a protocol stand point.

Unless Andrea or anyone else strongly disagrees I suggest going that route.

Nope, no strong disagreements, go ahead.
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

14

Dear All,
  I was reading the post 'Best way to implement WFS response that only
returns the bbox of the result'.
But not able to understand how to use resulttype=bbox and how to get bbox
containg of the features with out rendering/adding at client side.Can you
elaborate how to get BBox of the features with out adding to the map at
client side.

From,
Naresh

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Best-way-to-implement-WFS-response-that-only-returns-the-bbox-of-the-result-tp3805829p4502301.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

15

On Fri, Feb 24, 2012 at 2:02 PM, naresh <naresh919@anonymised.com> wrote:

Dear All,
I was reading the post ‘Best way to implement WFS response that only
returns the bbox of the result’.
But not able to understand how to use resulttype=bbox and how to get bbox
containg of the features with out rendering/adding at client side.Can you
elaborate how to get BBox of the features with out adding to the map at
client side.

Long story short: WFS does not support what you want, there is no
such a thing as resulttype=bbox, the only valid values are hits and results.
The closest thing to what you want is to select only the geometry attribute
in a GetFeature request, to limit the amount of data you get back.

Otherwise, you can install the WPS plugin, it has one process that actually
just computes and returns the bbox of a layer (or a filtered version of it)

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

16

Dear geowolf,

   Thanks for the reply.After reading your reply I was trying to implement
getfeature with restricting geometry
only, but not able to understand how to do this, could u please elaborate me
how can we achieve this. What ever i have gone through the getfeature
request I am not able to understand which parameter I have to pass/enable.

Thanks in Advance.

From,
N.Naresh

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Best-way-to-implement-WFS-response-that-only-returns-the-bbox-of-the-result-tp3805829p4514538.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

17

Hi,

This way
http://demo.opengeo.org/geoserver/ows?service=WFS&version=1.1.0&request=getfeature&typename=topp:states&maxfeatures=20&propertyname=the_geom

instead of this
http://demo.opengeo.org/geoserver/ows?service=WFS&version=1.1.0&request=getfeature&typename=topp:states&maxfeatures=20

I am interested in knowing where people are trying to find answers for questions like this. It would be important when planning how to teach people to find correct information. What sources did you read before trying what ever?

-Jukka Rahkonen-

naresh wrote:

Dear geowolf,

   Thanks for the reply.After reading your reply I was trying
to implement
getfeature with restricting geometry
only, but not able to understand how to do this, could u
please elaborate me
how can we achieve this. What ever i have gone through the getfeature
request I am not able to understand which parameter I have to
pass/enable.

Thanks in Advance.

From,
N.Naresh

--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Best-way-to-implement-WFS-
response-that-only-returns-the-bbox-of-the-result-tp3805829p45

14538.html

Sent from the GeoServer - User mailing list archive at Nabble.com.

--------------------------------------------------------------
----------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft
developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users