[mapserver-dev] RFC 105 : Support for WFS 2.0 (server side)

Andrea Peri aperi2007 at gmail.com
Sun Nov 24 00:10:33 PST 2013


Hi,
I'm not sure to well understand the question due to my poor english.

But, the wfs 1.1.0 specs will allow the sort clausole adding this parameter
in the url request:
It is allowable also in a post request.

This example:

...&sortBy=field1+D,field2+A


will sort on field1 ascending and field2 descending.

Andrea.



2013/11/24 Even Rouault <even.rouault at mines-paris.org>

> Le dimanche 24 novembre 2013 00:42:23, Martin Kofahl a écrit :
> > Hi Even,
> > amazing work you've done!
> >
> > After reading through the rfc I'm convinced that, regarding paging
> support,
> > we should require an order statement for rdbms connections or at least
> > mention it in the docs and all sample mapfiles
> (wfs_200_cite_postgis.map),
> > as unexpected getfeature responses are likely to occur (think of load
> > balancers).
>
> I'm not sure we must enforce it in code (the table refered in the mapfile
> could
> be a view that has already a ORDER BY clause, and we wouldn't know), but
> perhaps we can strongly recommand it in the doc.
>
> > Then i wondered about the wfs_cite_wfs2 flag. According the the
> > wfs spec the service parameter is mandatory (7.6.2.3), so this might be
> > more a cite issue.
>
> Yes, the service parameter is mandatory, but the following CITE test tries
> to
> check server behaviour when a mandatory parameter is missing
>
>
>     /**
>      * A GET request that omits a mandatory query parameter must produce a
>      * response with status code 400 (Bad Request) and an exception report
>      * containing the exception code {@code MissingParameterValue}.
>      *
>      * @see "ISO 19142:2010, cl. 7.5: Exception reporting"
>      * @see "OGC 06-121r3, cl. 8: Exception reports"
>      * @see "OGC 06-121r3, cl. A.4.1.5: HTTP response status code"
>      */
>     @Test
>     public void getCapabilities_missingServiceParam() {
>
> Unfortunately they've chosen the SERVICE parameter as a missing parameter,
> which is annoying when the server also implement other protocols. That
> would
> have been better if they had chosen VERSION in a DescribeFeatureType
> request
> for example.
>
> > Will you remove the flag when all testing is done?
>
> Not in that file, since it is used for testing of CITE compliance. But in
> normal mapfiles that don't try to be CITE pedantic, it is unnecessary.
>
> >
> > Kind regards,
> > Martin
> >
> >
> >
> > 2013/11/21 Even Rouault <even.rouault at mines-paris.org>
> >
> > > Hi,
> > >
> > > As I announced a few weeks ago, WFS 2.0 implementation + Inspire
> Download
> > > Services was in the works.
> > > Please find http://www.mapserver.org/development/rfc/ms-rfc-105.htmlfor
> > > review. A candidate implementation is available in a branch mentionned
> in
> > > the
> > > RFC.
> > >
> > > Best regards,
> > >
> > > Even
> > >
> > > --
> > > Geospatial professional services
> > > http://even.rouault.free.fr/services.html
> > > _______________________________________________
> > > mapserver-dev mailing list
> > > mapserver-dev at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20131124/41c9d514/attachment.html>


More information about the mapserver-dev mailing list