#1321 closed defect (invalid)
ST_AsGML fails to swap X/Y when outputting Envelope
Reported by: | strk | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
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.
Change History (6)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
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
comment:3 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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).
comment:4 by , 13 years ago
Sandro,
What do you want to clean exactly in the code ? Looks like a pure documentation issue, as you describe it.
comment:5 by , 13 years ago
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 ?
comment:6 by , 13 years ago
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.
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