[postgis-users] Oddity in _ST_Expand(geography) ?

[Pavan Deolasee]

Hi Paul,

Thanks for looking into it.

On Tue, Jul 3, 2018 at 11:41 PM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
> When I look at what we do for geometry:
>
> select st_astext(st_expand('LINESTRING(0 0, 1 1)'::geometry, 1));
>
> POLYGON((-1 -1,-1 2,2 2,2 -1,-1 -1))
>
> Huh, we morph a linestring into a polygon, odd, right? But it's a
> polygon that represents the bounds.
>

That makes sense in theory, though I admit I don't fully understand how a
line segment gets expanded to a polygon of that shape. Naively I would have
expected that each point on the polygon boundary to be at a distance of 1
unit from the line segment. But I remember only a few things from my
geometry class :-)


>
> I start to think that perhaps the existing behavior is broken, and
> geography expand should rewrite the object so that it becomes
> something that has the 3-space bounds we want. Maybe an appropriately
> chosen multipoint, for example. It will be very confusing to people,
> though, since they tend to think rectangularly about bounds, even when
> working with spherical coordinates, which are very decidedly not
> rectangular.
>

Its a relief that you think that the existing behaviour is broken,
otherwise I would have to look for ugly hacks in XL to fix this. But even
outside XL, I think this could be a problem for PostGIS since a SQL
expression may get evaluated, then converted into a string representation
and later converted back into the in-memory representation, losing critical
information on the way. So I think it's appropriate that we fix this in
PostGIS. Would it be feasible to output the bounding box information in
geography_out() and reconstructed back in the geography_in() function?

Thanks,
Pavan

P.S. Paul, I've distinct memories from your keynote at PGCon 2011, which
I'd immensely liked. I did not get chance to congratulate you then, so here
I am doing so after 7 years ;-)

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20180704/d6cabc0a/attachment.html>