New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
6 participants
@mapserver-bot

mapserver-bot commented Apr 4, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mapserver-bot

mapserver-bot Apr 4, 2012

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

mapserver-bot commented Apr 4, 2012

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

@dmorissette

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Jan 3, 2013

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?

Contributor

dmorissette commented Jan 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Jan 3, 2013

Contributor

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

Contributor

rouault commented Jan 3, 2013

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

mkofahl added a commit to faegi/mapserver that referenced this issue Jun 24, 2013

@mkofahl

This comment has been minimized.

Show comment
Hide comment
@mkofahl

mkofahl Jun 24, 2013

Contributor

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.

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.

@ghost ghost assigned mkofahl Jun 24, 2013

@mkofahl

This comment has been minimized.

Show comment
Hide comment
@mkofahl

mkofahl Jun 24, 2013

Contributor

@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.

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

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Jun 26, 2013

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

Member

tbonfort commented Jun 26, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@sdlime

sdlime Jul 3, 2013

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@dmorissette

dmorissette Jul 4, 2013

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.

Contributor

dmorissette commented Jul 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Jul 7, 2013

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@mkofahl

mkofahl Jul 24, 2013

Contributor

Thank you @rouault.

Contributor

mkofahl commented Jul 24, 2013

Thank you @rouault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment