OGC WFS/FES SWG has decided that STARTINDEX should begin at 0 #4180

Closed
mapserver-bot opened this Issue Apr 4, 2012 · 10 comments

Projects

None yet

6 participants

@mapserver-bot

Reporter: rouault
Date: 2012/02/09 - 09:28
Trac URL: http://trac.osgeo.org/mapserver/ticket/4180
I had raised that issue recently as a GeoServer bug and reported it in a mapserver email thread ( http://lists.osgeo.org/pipermail/mapserver-dev/2012-January/thread.html#11864 ), but now with the latest elements given in https://jira.codehaus.org/browse/GEOS-4920 , it seems that MapServer should be fixed so that STARTINDEX = 0 means the first feature.

@mapserver-bot

Author: rouault
Date: 2012/02/09 - 22:52
Also created the relevant ticket for OGR: http://trac.osgeo.org/gdal/ticket/4504

@dmorissette
Contributor

Bump! This STARTINDEX issue was brought up again on the GDAL list today, which reminded us that we should fix MapServer so that it uses STARTINDEX=0 for the first feature as was decided by the WFS SWG back in Feb. 2012.

@aboudreault is this something you could look into?

@rouault
Contributor
rouault commented Jan 3, 2013

Note: GDAL http://trac.osgeo.org/gdal/ticket/4504 has now been fixed (for GDAL 1.10)

@mkofahl mkofahl added a commit to faegi/mapserver that referenced this issue Jun 24, 2013
@mkofahl mkofahl WFS paging parameter startIndex changed to base on 0 (0 is the first …
…feature). See #4180 for external references.
3edd5fd
@mkofahl
Contributor
mkofahl commented Jun 24, 2013

As far I can see MapServer internally uses startindex starting with 1 for the first feature. My local msautotest looks fine with changeing startindex in the WFS part, only.

@mkofahl mkofahl was assigned Jun 24, 2013
@mkofahl
Contributor
mkofahl commented Jun 24, 2013

@tbonfort Are you fine if this goes into branch-6-2? This is an important change, but for WFS clients only. Will have to do some tests with real clients, however.

@tbonfort
Member

@mkofahl @dmorissette I am not in a position to comment wether this should go into the 6.2 branch or not. As this will clearly be breaking backwards compatibility for clients who are currently expecting the startindex to be 1, our policy would dictate that this should wait until 6.4. However, this could also be seen as a bug and therefore be added to 6.2.
tl;dr : not my call, I'm personally fine with both options

@sdlime
Member
sdlime commented Jul 3, 2013

I think I'd wait until 6.4. It's much easier to detail a regression like this (even if it is a bug) with a minor release. I fear it will be missed by folks otherwise.

Steve

@dmorissette
Contributor

I agree with @sdlime, let's apply this change only in 6.4 to reduce the impact on existing clients that rely on the incorrect behavior.

@rouault
Contributor
rouault commented Jul 7, 2013

Fix merged. I also had to (logically) adapt 3 msautotest tests that tests STARTINDEX=10 ( mapserver/msautotest_DEPRECATED@2d7deab and mapserver/msautotest_DEPRECATED@e6d4956 )

@mkofahl
Contributor
mkofahl commented Jul 24, 2013

Thank you @rouault.

@mkofahl mkofahl closed this Jul 24, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment