ST_AsGML fails to swap X/Y when outputting Envelope

[strk]

Options 255|16 seem to be legal but don't do what they advertise to do in the manual page.

255 outputs an gml:Envelope tag (in GML3). 16 is supposed to swap X and Y (for GML3).

The combination isn't swapping.

[strk]

So it turns out it's worst than it looks. It _always_ swaps, rather than never.

Actually, I suspect 255 is just setting all bits on, which isn't a good idea for bitfields

[strk]

New findings: liblwgeom AND postgis disagree on which numbers/flags to use for what. THis is pretty frustrating.

At PostGIS level (manual) it's documented that 16 does the swapping of X/Y (is_degree) but at liblwgeom level that flag is (1<<1) which means just 1. While 16 is for the extent flag (1<<4).

I hope Olivier will show up soon to clear the picture some :)

[strk]

Alright, looking at the code in PostGIS it turns out the flag for outputting EXTENT is 32 (1<<5). Hopefully this is then NOT a bug, but rather just an opportunity to clean things up in the code (and a documentation issue).

[colivier]

Sandro,

What do you want to clean exactly in the code ? Looks like a pure documentation issue, as you describe it.

:)

[strk]

Colivier: the difference between flags as seen by SQL/postgis and those as seen by liblwgeom:

        if (option & 2)  lwopts &= ~LW_GML_IS_DIMS; 
        if (option & 4)  lwopts |= LW_GML_SHORTLINE;
        if (option & 16) lwopts |= LW_GML_IS_DEGREE;
        if (option & 32) lwopts |= LW_GML_EXTENT;

/** For GML3 only, include srsDimension attribute in output */
#define LW_GML_IS_DIMS     (1<<0)
/** For GML3 only, declare that datas are lat/lon. Swaps axis order */
#define LW_GML_IS_DEGREE   (1<<1)
/** For GML3, use <LineString> rather than <Curve> for lines */
#define LW_GML_SHORTLINE   (1<<2)
/** For GML2 and GML3, output only extent of geometry */
#define LW_GML_EXTENT      (1<<4)

You can see, for example, that DEGREE is 2 at the liblwgeom and 16 at the sql level. SHORTLINE and EXTENT seem to be consistent. DIMS seems to be using the flag that in liblwgeom means DEGREE, isn't it ?

[colivier]

Sandro,

Yes the bitfield are not the sames, because it was choosed to not change anything in the public prototype, and so to postgis level. (was a good thing i think)

But at liblwgeom level, it doesn't make sense (for me) to keep it as it, for instance, there's no option for 8 bit field

I don't have strong conviction on this point so feel free to change it, if you believe it worths to have the same bitfield values on both levels.