[postgis-users] GeometryN() function - bug

[David Blasby]

christopher.faulkner at ntlworld.com wrote:

> Thanks for the quick advice. 
> 
> 
>>You must be looking at old documentation - I updated it 
>>when I fixed this.
>>
>>The correct behavior is "1" being the 1st geometry in a 
>>collection.
> 
> 
> For documentation, I was looking on the live website - this still refers to a zero based index. http://postgis.refractions.net/docs/c671.html#AEN674
> 
> I just checked in the c671.html page in the postgis 0.8.1 tarfile and it has the same information. Perhaps this should also be in the "changes" file.


Okay - I fixed it and re-commited the documentation.  Sorry about that - 
I could have sworn that I had updated that.

There was a discussion on this topic a little while ago.  If you want 
your postgis installation to have "geometryN(...)" be 0-based (like it 
used to be) instead of 1-based (like it is now), you can change a line 
in postgis_fn.c (around line 90):

#define NfunctionFirstPoint 1

// if you use #define NfunctionFirstPoint 0, you get 0-based indexing 
(this is what programmers want)::
//  pointN(<linestring>, 0) is the 1st point, and pointN(<linestring>, 
1) is the second point.

// if you use #define NfunctionFirstPoint 1, you get 1-based indexing 
(which seems to be what the spec wants)::
//  pointN(<linestring>, 1) is the 1st point, and pointN(<linestring>, 
2) is the second point.



dave