[gdal-dev] RFC 35: Delete, reorder and alter field definitions of OGR layers - Call for discussion

[Even Rouault]

> 
> I would like to see some description of the effect of ReorderField().  I
> assume iOldFieldPos and iNewFieldPos have to both be existing fields, and
> that intermediate fields will be shuffled along as needed to satisfy the
> request - is that right?

Yes, exactly. iOldFieldPos and iNewFieldPos must be in [0, GetFieldCount()-1]

If you have initially 5 fields "0", "1", "2", "3","4" :
* ReorderField(1,3) --> "0", "2", "3", "1", "4"
* ReorderField(0,4) --> "1", "2", "3", "4", "0"
* ReorderField(4,0) --> "4", "0", "1", "2", "3"

> 
> I am somewhat wondering if it would be better to provide a mechanism
> to reorder all columns in one request.

Yes, that could be a possibility. The use case I was thinking initially was a 
user dragging the header of a column in a table to move it at a new position. 
But that could be done through a global reordering method, 
OGRLayer::ReorderFields(int* panNewPos), panNewPos being a permutation of [0, 
GetFieldCount()-1]. ReorderFields() would behave such, for each field that was 
initially at position i, its new position would be panNewPos[i]. I believe 
that the implementation in shapelib would be doable, and perhaps even a bit 
more straightforward than the one of ReorderField() where one must be careful 
to move things in the right order depending on if iOldFieldPos < iNewFieldPos 
or not.

I'll update the RFC, patch and test with that solution.

> 
> Otherwise I am satisfied with the suggested approach.
> 
> Best regards,