[postgis-tickets] [PostGIS] #3361: gserialized_from_lwgeom takes is_geodetic arg but does nothing with it, geography_serialize may give you a geometry if not careful

[PostGIS]

#3361: gserialized_from_lwgeom takes is_geodetic arg but does nothing with it,
geography_serialize may give you a geometry if not careful
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 2.3.0
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:
----------------------+---------------------------
Description changed by robe:

Old description:

> 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 hoping 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.

New description:

 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.

--

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3361#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.