Hi Paul,
Thanks for looking into it.
On Tue, Jul 3, 2018 at 11:41 PM, Paul Ramsey
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,
The PostGIS development team is pleased to release PostGIS 2.5.0beta1.
This release is a work in progress. No more api changes will be made from
this point on before 2.5.0 release. Remaining time will be focused on bug
fixes and documentation for the new functionality and performance
enhancements
That's the stupidest idea I ever heard.
/JK
Actually it's just a misunderstanding. We can't return the three-space
box, we have to return a lon/lat shape that, when plotted on the
surface of the earth, has the expected 3-space bounding box. So, it
could get tricky.
P.
On Tue, Jul 3, 2018 at
>
> 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
Ug. So the issue with XL is an interesting side-effect of the way
expand is implemented in geography...
The first part to understand is that the bounding box of a geography
is expressed in 3-space. So imagine the world, it's a big sphere. Now,
imagine a line on that world. In 3-space, it's a
On 3 July 2018 at 12:50, Devdatta Tengshe wrote:
>
> Currently I'm using the following query to figure out if we can potentially
> service the customer:
>
> Select count(id) from service_areas where
> ST_CoveredBy(ST_SetSRID(ST_MakePoint(78.46239,17.30360),4326), geom);
Try
Hi all,
I'm developing an API which will help us figure out if we can server a
potential customer. For this, I have a PostGIS Table with polygon
representing the service area of each of our store. There could be up to
10,000 polygons in the table. These polygons are geometries in EPSG:4326
and
