id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 3361,"gserialized_from_lwgeom takes is_geodetic arg but does nothing with it, geography_serialize may give you a geometry if not careful",robe,robe,"This is not so much a bug as a change the code to keep my sanity and so that other developers don't fall into a wtf trap. In hopping threw the wonderland of gserialized I ended up in the rabbit hole of gserialized_from_lwgeom(LWGEOM * geom,int is_geodetic, size_t * size ) in g_serialized c. http://postgis.net/docs/doxygen/2.3/da/d21/g__serialized_8c_a0b9fd37dce2089c4fecb8a23ed102323.html#a0b9fd37dce2089c4fecb8a23ed102323 All roads from geometry and geography eventually lead to this function, and I was puzzled why every call would both do a lwgeom_set_geodetic(lwgeom, true); and then still pass along this is_geodetic bit. On closer inspection -- that is_geodetic bit is never used, just always ignored like some vestigial cecum that turned into a useless appendix. In fact the internal bit in lwgeom is always used, so we should just get rid of this argument. I should add -- geography_serialize(lwgeom); I thought would be smart enough to set the geodetic bit too from the name of the function as isn't the point to get a geography serialized out of an lwgeom, nope. If you feed in an lwgeom that is not geodetic, you end up with a gserialized that is not geodetic also. Anyway I'd like to change at the very least that gserialized_from_lwgeom and changed geography_serialize to guarantee always getting back a geography. But I would like to get some opinions before I do that. Of course I would only do this in 2.3 and not backport. ",defect,closed,medium,PostGIS 2.3.0,postgis,master,fixed,,