[Geoserver-devel] Paginated WPS response

Hi,

We have developed a WPS process which takes some pagination parameters (startIndex, maxFeatures) in order to return a subset of the whole FeatureCollection.

In order to properly interact with client code, we’d like to include a totalCount property in the response, indicating the size of the total feature collection. Which is the best way to encode such parameter?

I have been thinking on the following approaches, but the main problem is that Geoserver WPS documentation is a bit vague regarding supported response types and how they are encoded:

  • To return a different return type (such as a JSON object or similar). We won’t actually have any geometry in the response of this WPS process, just an array of records, so the whole thing could be encoded on a JSON object (included the totalCount field).

  • To create an interface extending SimpleFeatureCollection (let’s call it PartialFeatureCollection) including a totalCount property (and probably some other useful properties). Then we need an implementation of that interface that acts as a wrapper of a SimpleFeatureCollection to wrap our current response. Finally, we would probably need a custom PPIO to properly encode this specialized response.

  • To investigate if we can add some property to the FeatureCollection, assuming this property is then properly encoded in the response (as this is not a property of any of the features but of the whole collection).

Do you have any suggestion?

Thanks in advance,

César


César Martínez Izquierdo
GIS developer


Blog: http://geotechnotes.wordpress.com/
ETC-SIA: http://sia.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)


Comments inline …

···

We have developed a WPS process which takes some pagination parameters (startIndex, maxFeatures) in order to return a subset of the whole FeatureCollection.

In order to properly interact with client code, we’d like to include a totalCount property in the response, indicating the size of the total feature collection. Which is the best way to encode such parameter?

I would guess you should encode it as numberOfFeatures (i.e. number of features provides in answer to your request?).

If you wanted to provide a totalNumberOfFeatures you could extend the GML feature collection in order to provide additional attributes. The trick is where to store it so client code can validate against it? I suppose it would be okay if you included such a definition in your DescribeFeatureType response … or perhaps in each WPS process response (since a similar approach is already taken to validate common wps arguments).

I have been thinking on the following approaches, but the main problem is that Geoserver WPS documentation is a bit vague regarding supported response types and how they are encoded:

It is more that we have not exhaustively defined how to handle/validate ComplexData.

  • To return a different return type (such as a JSON object or similar). We won’t actually have any geometry in the response of this WPS process, just an array of records, so the whole thing could be encoded on a JSON object (included the totalCount field).

  • To create an interface extending SimpleFeatureCollection (let’s call it PartialFeatureCollection) including a totalCount property (and probably some other useful properties). Then we need an implementation of that interface that acts as a wrapper of a SimpleFeatureCollection to wrap our current response. Finally, we would probably need a custom PPIO to properly encode this specialized response.

  • To investigate if we can add some property to the FeatureCollection, assuming this property is then properly encoded in the response (as this is not a property of any of the features but of the whole collection).

Do you have any suggestion?

Yeah I think you should consider having your WPS process produce more than one output at the same time, that way you are not messing with GML and schema validation, just have your output include a feature collection as the compilex data, and a count as simple data.

Just how a WPS can have more than one input, it can also have more than one output.

Thanks in advance,

César


César Martínez Izquierdo
GIS developer


Blog: http://geotechnotes.wordpress.com/
ETC-SIA: http://sia.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)



Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
� 3 signs your SCM is hindering your productivity
� Requirements for releasing software faster
� Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Thanks Jody, returning 2 outputs seems a very reasonable solution for this use case.

Best regards,

César

···

2014-05-08 4:12 GMT+02:00 Jody Garnett <jody.garnett@anonymised.com>:

Comments inline …


César Martínez Izquierdo
GIS developer


Blog: http://geotechnotes.wordpress.com/
ETC-SIA: http://sia.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)


We have developed a WPS process which takes some pagination parameters (startIndex, maxFeatures) in order to return a subset of the whole FeatureCollection.

In order to properly interact with client code, we’d like to include a totalCount property in the response, indicating the size of the total feature collection. Which is the best way to encode such parameter?

I would guess you should encode it as numberOfFeatures (i.e. number of features provides in answer to your request?).

If you wanted to provide a totalNumberOfFeatures you could extend the GML feature collection in order to provide additional attributes. The trick is where to store it so client code can validate against it? I suppose it would be okay if you included such a definition in your DescribeFeatureType response … or perhaps in each WPS process response (since a similar approach is already taken to validate common wps arguments).

I have been thinking on the following approaches, but the main problem is that Geoserver WPS documentation is a bit vague regarding supported response types and how they are encoded:

It is more that we have not exhaustively defined how to handle/validate ComplexData.

  • To return a different return type (such as a JSON object or similar). We won’t actually have any geometry in the response of this WPS process, just an array of records, so the whole thing could be encoded on a JSON object (included the totalCount field).

  • To create an interface extending SimpleFeatureCollection (let’s call it PartialFeatureCollection) including a totalCount property (and probably some other useful properties). Then we need an implementation of that interface that acts as a wrapper of a SimpleFeatureCollection to wrap our current response. Finally, we would probably need a custom PPIO to properly encode this specialized response.

  • To investigate if we can add some property to the FeatureCollection, assuming this property is then properly encoded in the response (as this is not a property of any of the features but of the whole collection).

Do you have any suggestion?

Yeah I think you should consider having your WPS process produce more than one output at the same time, that way you are not messing with GML and schema validation, just have your output include a feature collection as the compilex data, and a count as simple data.

Just how a WPS can have more than one input, it can also have more than one output.

Thanks in advance,

César


César Martínez Izquierdo
GIS developer


Blog: http://geotechnotes.wordpress.com/
ETC-SIA: http://sia.eionet.europa.eu/
Universitat Autònoma de Barcelona (SPAIN)



Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
� 3 signs your SCM is hindering your productivity
� Requirements for releasing software faster
� Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce


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