BOX3D strange behaviour

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

BOX3D strange behaviour

Rémi Cura
Hey,
I can't understand this behaviour of box3D ans &&& operator.



SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&& ST_Makepoint(5,5,-1) -- ---> TRUE

the answer is obviously FALSE.
I have latest postgis.

Cheers,
Rémi-C

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Paul Ramsey
Here’s a clue:

select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);


On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]> wrote:

SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&& ST_Makepoint(5,5,-1)


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Sandro Santilli-2
On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]> wrote:
> >
> > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&& ST_Makepoint(5,5,-1)
>
> select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);

Horrible. box3d::geometry drops the Z ?
Was it always like that ? I'd call it a bug ...

--strk;

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Darafei "Komяpa" Praliaskouski
I'd call it a bug too.
Bumped into it storing timestamp in z coordinate of linestring and willing to cut it by timestamp interpolating endpoints, calculating ST_3DIntersection(geom, box3d). It failed, so I had to give up and go back to ST_Dump + WHERE ST_Z(pt) BETWEEN :(

чт, 18 февр. 2016 г. в 11:37, Sandro Santilli <[hidden email]>:
On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]> wrote:
> >
> > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&& ST_Makepoint(5,5,-1)
>
> select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);

Horrible. box3d::geometry drops the Z ?
Was it always like that ? I'd call it a bug ...

--strk;

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Even Rouault-2
In reply to this post by Sandro Santilli-2
Le jeudi 18 février 2016 09:37:41, Sandro Santilli a écrit :

> On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]> wrote:
> > >
> > > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&&
> > > ST_Makepoint(5,5,-1)
> >
> > select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
>
> Horrible. box3d::geometry drops the Z ?
> Was it always like that ?

Seems so:

=> select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
            postgis_version            |             st_astext              
---------------------------------------+------------------------------------
 1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0 0))
(1 ligne)

select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
            postgis_version            |             st_astext              
---------------------------------------+------------------------------------
 2.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0 0))

>
> --strk;
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Rémi Cura
So what is the point to have a Box3D,
 as any use of it requires it to be casted to geometry,
which turns it into a box2D?
(Maybe I missed a way to use this 3D box with a 3D index so it uses Z? )

Is there any way to perform &&& in all 3 dimensions?

My problem is "give points whose X, Y, Z are inside the range R1,R2,R3",
and I'd prefer have one 3D geom gist index rather than 3 btree index on coordinates.

I was thinking the 3DBox was smart, untill I spent quite some time tracking subsequent errors to postgis.

Cheers,
Rémi-C

2016-02-18 9:53 GMT+01:00 Even Rouault <[hidden email]>:
Le jeudi 18 février 2016 09:37:41, Sandro Santilli a écrit :
> On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]> wrote:
> > >
> > > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&&
> > > ST_Makepoint(5,5,-1)
> >
> > select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
>
> Horrible. box3d::geometry drops the Z ?
> Was it always like that ?

Seems so:

=> select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
            postgis_version            |             st_astext
---------------------------------------+------------------------------------
 1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0 0))
(1 ligne)

select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
            postgis_version            |             st_astext
---------------------------------------+------------------------------------
 2.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0 0))

>
> --strk;
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Even Rouault-2
Le jeudi 18 février 2016 10:03:54, Rémi Cura a écrit :

> So what is the point to have a Box3D,
>  as any use of it requires it to be casted to geometry,
> which turns it into a box2D?
> (Maybe I missed a way to use this 3D box with a 3D index so it uses Z? )
>
> Is there any way to perform &&& in all 3 dimensions?
>
> My problem is "give points whose X, Y, Z are inside the range R1,R2,R3",
> and I'd prefer have one 3D geom gist index rather than 3 btree index on
> coordinates.
>
> I was thinking the 3DBox was smart, untill I spent quite some time tracking
> subsequent errors to postgis.

The following hack seems to work :

SELECT  st_geomfromtext('multipoint z (0 0 0,10 10 10)')  &&& ST_Makepoint(5,5,-1);
 ?column?
----------
 f
(1 ligne)


SELECT  st_geomfromtext('multipoint z (0 0 0,10 10 10)')  &&& ST_Makepoint(5,5,3);
 ?column?
----------
 t
(1 ligne)



>
> Cheers,
> Rémi-C
>
> 2016-02-18 9:53 GMT+01:00 Even Rouault <[hidden email]>:
> > Le jeudi 18 février 2016 09:37:41, Sandro Santilli a écrit :
> > > On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > > > > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]>
> > > > > wrote:
> > > > >
> > > > > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&&
> > > > > ST_Makepoint(5,5,-1)
> > > >
> > > > select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
> > >
> > > Horrible. box3d::geometry drops the Z ?
> > > Was it always like that ?
> >
> > Seems so:
> >
> > => select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10
> > 10)'::box3D::geometry);
> >
> >             postgis_version            |             st_astext
> >
> > ---------------------------------------+---------------------------------
> > ---
> >
> >  1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0
> >  0))
> >
> > (1 ligne)
> >
> > select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10
> > 10)'::box3D::geometry);
> >
> >             postgis_version            |             st_astext
> >
> > ---------------------------------------+---------------------------------
> > ---
> >
> >  2.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0
> >  0))
> >  
> > > --strk;
> > >
> > > _______________________________________________
> > > postgis-devel mailing list
> > > [hidden email]
> > > http://lists.osgeo.org/mailman/listinfo/postgis-devel
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > _______________________________________________
> > postgis-devel mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Rémi Cura
Great !
I'll try that and see how much faster it is !
Cheers,
Rémi-C

2016-02-18 10:17 GMT+01:00 Even Rouault <[hidden email]>:
Le jeudi 18 février 2016 10:03:54, Rémi Cura a écrit :
> So what is the point to have a Box3D,
>  as any use of it requires it to be casted to geometry,
> which turns it into a box2D?
> (Maybe I missed a way to use this 3D box with a 3D index so it uses Z? )
>
> Is there any way to perform &&& in all 3 dimensions?
>
> My problem is "give points whose X, Y, Z are inside the range R1,R2,R3",
> and I'd prefer have one 3D geom gist index rather than 3 btree index on
> coordinates.
>
> I was thinking the 3DBox was smart, untill I spent quite some time tracking
> subsequent errors to postgis.

The following hack seems to work :

SELECT  st_geomfromtext('multipoint z (0 0 0,10 10 10)')  &&& ST_Makepoint(5,5,-1);
 ?column?
----------
 f
(1 ligne)


SELECT  st_geomfromtext('multipoint z (0 0 0,10 10 10)')  &&& ST_Makepoint(5,5,3);
 ?column?
----------
 t
(1 ligne)



>
> Cheers,
> Rémi-C
>
> 2016-02-18 9:53 GMT+01:00 Even Rouault <[hidden email]>:
> > Le jeudi 18 février 2016 09:37:41, Sandro Santilli a écrit :
> > > On Wed, Feb 17, 2016 at 11:33:12AM -0800, Paul Ramsey wrote:
> > > > > On Feb 17, 2016, at 10:46 AM, Rémi Cura <[hidden email]>
> > > > > wrote:
> > > > >
> > > > > SELECT 'BOX3D( 0 0 0, 10 10 10)'::box3D::geometry &&&
> > > > > ST_Makepoint(5,5,-1)
> > > >
> > > > select st_astext('BOX3D( 0 0 0, 10 10 10)'::box3D::geometry);
> > >
> > > Horrible. box3d::geometry drops the Z ?
> > > Was it always like that ?
> >
> > Seems so:
> >
> > => select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10
> > 10)'::box3D::geometry);
> >
> >             postgis_version            |             st_astext
> >
> > ---------------------------------------+---------------------------------
> > ---
> >
> >  1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0
> >  0))
> >
> > (1 ligne)
> >
> > select postgis_version(), st_astext('BOX3D( 0 0 0, 10 10
> > 10)'::box3D::geometry);
> >
> >             postgis_version            |             st_astext
> >
> > ---------------------------------------+---------------------------------
> > ---
> >
> >  2.0 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 | POLYGON((0 0,0 10,10 10,10 0,0
> >  0))
> >
> > > --strk;
> > >
> > > _______________________________________________
> > > postgis-devel mailing list
> > > [hidden email]
> > > http://lists.osgeo.org/mailman/listinfo/postgis-devel
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > _______________________________________________
> > postgis-devel mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Sandro Santilli-2
In reply to this post by Rémi Cura
On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:

> Is there any way to perform &&& in all 3 dimensions?

Our boxes are all broken.
There should be somewhere a wiki page or ticker or something about
options to improve the situation. IIRC it boiled down to:

 1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
 2) Expose a GBOX postgresql type (like BOX2D, BOX3D)

Recently, I've started using 2-vertices linestrings to simulate
the equivalent of a "BOX geometry type". It is the value returned
by http://postgis.net/docs/ST_BoundingDiagonal.html

You can easily create such object via ST_MakeLine:
http://postgis.net/docs/ST_MakeLine.html

It will support SRID and all supported dimensions.

Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
it return a "bounding diagonal" too...

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Rémi Cura
Using Even trick saves me about 25% time.
Good !

Now I'll always use the multipoints/line instead of box3D

Cheers,
Rémi-C

2016-02-18 10:49 GMT+01:00 Sandro Santilli <[hidden email]>:
On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:

> Is there any way to perform &&& in all 3 dimensions?

Our boxes are all broken.
There should be somewhere a wiki page or ticker or something about
options to improve the situation. IIRC it boiled down to:

 1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
 2) Expose a GBOX postgresql type (like BOX2D, BOX3D)

Recently, I've started using 2-vertices linestrings to simulate
the equivalent of a "BOX geometry type". It is the value returned
by http://postgis.net/docs/ST_BoundingDiagonal.html

You can easily create such object via ST_MakeLine:
http://postgis.net/docs/ST_MakeLine.html

It will support SRID and all supported dimensions.

Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
it return a "bounding diagonal" too...

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Sandro Santilli-2
On Thu, Feb 18, 2016 at 11:02:49AM +0100, Rémi Cura wrote:
> Using Even trick saves me about 25% time.
> Good !

Right, it's the same approach of the "BoundingDiagonal",
only he does it with a 2-members multipoint rather than
with a 2-vertices linestring.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Rémi Cura
Exactly,
in the end it's just 2 points.
I personally would prefer to keep it as 2 points,
because I feel a line is semantically more different,
but it amounts to the same thing in the end.

Cheers,
Rémi-C

2016-02-18 11:36 GMT+01:00 Sandro Santilli <[hidden email]>:
On Thu, Feb 18, 2016 at 11:02:49AM +0100, Rémi Cura wrote:
> Using Even trick saves me about 25% time.
> Good !

Right, it's the same approach of the "BoundingDiagonal",
only he does it with a 2-members multipoint rather than
with a 2-vertices linestring.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Sandro Santilli-2
On Thu, Feb 18, 2016 at 01:27:18PM +0100, Rémi Cura wrote:
> Exactly,
> in the end it's just 2 points.
> I personally would prefer to keep it as 2 points,
> because I feel a line is semantically more different,
> but it amounts to the same thing in the end.

My pick of a line is to make it clear what's the "min"
and what's the "max". Whereas elements in a MULTIPOINT
are conceptually unordered.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Even Rouault-2
In reply to this post by Sandro Santilli-2
Le jeudi 18 février 2016 10:49:52, Sandro Santilli a écrit :

> On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:
> > Is there any way to perform &&& in all 3 dimensions?
>
> Our boxes are all broken.
> There should be somewhere a wiki page or ticker or something about
> options to improve the situation. IIRC it boiled down to:
>
>  1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
>  2) Expose a GBOX postgresql type (like BOX2D, BOX3D)
>
> Recently, I've started using 2-vertices linestrings to simulate
> the equivalent of a "BOX geometry type". It is the value returned
> by http://postgis.net/docs/ST_BoundingDiagonal.html
>
> You can easily create such object via ST_MakeLine:
> http://postgis.net/docs/ST_MakeLine.html
>
> It will support SRID and all supported dimensions.
>
> Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
> it return a "bounding diagonal" too...

Naively, I would rather have expected a BOX3D to be converted as a
PolyhedralSurface, but there might be implications in doing so.

>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

geohash is a strange beast

nicklas
Hello

First I thought that this was a bug in PostGIS.
But now I am not sure. It is likely just a smelling brain fart.

First what made me start thinking:

The query:
SELECT ST_Box2dFromGeoHash('0');

I expect to get the western half of the world back like :
"BOX(-180 -90,0 90)"

from my understanding after reading for instance this post:
http://www.bigfastblog.com/geohash-intro

But it doesn't. It returns:
"BOX(-180 -90,-135 -45)"

The reason is that geohash is coded with base32

So the function have no way to understand if we on bit level mean 0 or
00 or 000 or 0000 or 00000

The way the function is written it iterates all 5 bit-positions and if
there is a 0 it divides the eastern and southern part.
lon goes through those divisions
starts with -180 to 180
-180 to 0
-180 to -90
-180 to -135

and lat through
-90 to 90
-90 to 0
-90 to -45

3 rounds for lon and 2 for lat.

That is what the 5 bits in the base32 representation of 0 does.

Worst is that I guess this happens on all geohashes that ends with 0.
How to know how many bits to use?

And in the PostGIS case I have a question about if we are doing this
right.

We are assuming the maximum precision from the inputed 0
Is it not more right to assume the worst precision?

I hope I am totally wrong in all this or geohash is far from that usable
that I thought.

Did I forget my brain at home today?

Best Regards

Nicklas Avén


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: geohash is a strange beast

nicklas
Sorry for the noise.

I realize everything of course is as it should.
Geohash only have 5 bit steps.

One box can only be divided in 32 smaller boxes, not just 2 as I
thought.

I found my brain at home.

/Nicklas


On Wed, 2016-02-24 at 14:54 +0100, Nicklas Avén wrote:

> Hello
>
> First I thought that this was a bug in PostGIS.
> But now I am not sure. It is likely just a smelling brain fart.
>
> First what made me start thinking:
>
> The query:
> SELECT ST_Box2dFromGeoHash('0');
>
> I expect to get the western half of the world back like :
> "BOX(-180 -90,0 90)"
>
> from my understanding after reading for instance this post:
> http://www.bigfastblog.com/geohash-intro
>
> But it doesn't. It returns:
> "BOX(-180 -90,-135 -45)"
>
> The reason is that geohash is coded with base32
>
> So the function have no way to understand if we on bit level mean 0 or
> 00 or 000 or 0000 or 00000
>
> The way the function is written it iterates all 5 bit-positions and if
> there is a 0 it divides the eastern and southern part.
> lon goes through those divisions
> starts with -180 to 180
> -180 to 0
> -180 to -90
> -180 to -135
>
> and lat through
> -90 to 90
> -90 to 0
> -90 to -45
>
> 3 rounds for lon and 2 for lat.
>
> That is what the 5 bits in the base32 representation of 0 does.
>
> Worst is that I guess this happens on all geohashes that ends with 0.
> How to know how many bits to use?
>
> And in the PostGIS case I have a question about if we are doing this
> right.
>
> We are assuming the maximum precision from the inputed 0
> Is it not more right to assume the worst precision?
>
> I hope I am totally wrong in all this or geohash is far from that usable
> that I thought.
>
> Did I forget my brain at home today?
>
> Best Regards
>
> Nicklas Avén
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Daniel Baston
In reply to this post by Even Rouault-2
There's now a pull request to address this:


The only places in the regression suite where a BOX3D->geometry cast is executed are places where a (user-input) BOX3D literal is explicitly cast to a geometry.  So, there shouldn't be a performance hit or ill effect of having the BOX3D->geometry cast produce a PolyhedralSurface, as Even suggests.

Any objections to this?

Dan

On Thu, Feb 18, 2016 at 8:02 AM, Even Rouault <[hidden email]> wrote:
Le jeudi 18 février 2016 10:49:52, Sandro Santilli a écrit :
> On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:
> > Is there any way to perform &&& in all 3 dimensions?
>
> Our boxes are all broken.
> There should be somewhere a wiki page or ticker or something about
> options to improve the situation. IIRC it boiled down to:
>
>  1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
>  2) Expose a GBOX postgresql type (like BOX2D, BOX3D)
>
> Recently, I've started using 2-vertices linestrings to simulate
> the equivalent of a "BOX geometry type". It is the value returned
> by http://postgis.net/docs/ST_BoundingDiagonal.html
>
> You can easily create such object via ST_MakeLine:
> http://postgis.net/docs/ST_MakeLine.html
>
> It will support SRID and all supported dimensions.
>
> Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
> it return a "bounding diagonal" too...

Naively, I would rather have expected a BOX3D to be converted as a
PolyhedralSurface, but there might be implications in doing so.

>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Paul Ramsey
Nope, make it So

On Fri, Feb 26, 2016 at 12:41 PM, Daniel Baston <[hidden email]> wrote:

> There's now a pull request to address this:
>
> https://github.com/postgis/postgis/pull/92
>
> The only places in the regression suite where a BOX3D->geometry cast is
> executed are places where a (user-input) BOX3D literal is explicitly cast to
> a geometry.  So, there shouldn't be a performance hit or ill effect of
> having the BOX3D->geometry cast produce a PolyhedralSurface, as Even
> suggests.
>
> Any objections to this?
>
> Dan
>
> On Thu, Feb 18, 2016 at 8:02 AM, Even Rouault <[hidden email]>
> wrote:
>>
>> Le jeudi 18 février 2016 10:49:52, Sandro Santilli a écrit :
>> > On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:
>> > > Is there any way to perform &&& in all 3 dimensions?
>> >
>> > Our boxes are all broken.
>> > There should be somewhere a wiki page or ticker or something about
>> > options to improve the situation. IIRC it boiled down to:
>> >
>> >  1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
>> >  2) Expose a GBOX postgresql type (like BOX2D, BOX3D)
>> >
>> > Recently, I've started using 2-vertices linestrings to simulate
>> > the equivalent of a "BOX geometry type". It is the value returned
>> > by http://postgis.net/docs/ST_BoundingDiagonal.html
>> >
>> > You can easily create such object via ST_MakeLine:
>> > http://postgis.net/docs/ST_MakeLine.html
>> >
>> > It will support SRID and all supported dimensions.
>> >
>> > Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
>> > it return a "bounding diagonal" too...
>>
>> Naively, I would rather have expected a BOX3D to be converted as a
>> PolyhedralSurface, but there might be implications in doing so.
>>
>> >
>> > --strk;
>> > _______________________________________________
>> > postgis-devel mailing list
>> > [hidden email]
>> > http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>> _______________________________________________
>> postgis-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Paul Ramsey
In reply to this post by Rémi Cura
Codacil to this: a linestring involves an lwline and a pointarray, a
multipoint involves a multipoint, 2 x point, 2 x pointarray, so
there's a minor efficiency in sticking w/ the line.

On Thu, Feb 18, 2016 at 1:27 PM, Rémi Cura <[hidden email]> wrote:

> Exactly,
> in the end it's just 2 points.
> I personally would prefer to keep it as 2 points,
> because I feel a line is semantically more different,
> but it amounts to the same thing in the end.
>
> Cheers,
> Rémi-C
>
> 2016-02-18 11:36 GMT+01:00 Sandro Santilli <[hidden email]>:
>>
>> On Thu, Feb 18, 2016 at 11:02:49AM +0100, Rémi Cura wrote:
>> > Using Even trick saves me about 25% time.
>> > Good !
>>
>> Right, it's the same approach of the "BoundingDiagonal",
>> only he does it with a 2-members multipoint rather than
>> with a 2-vertices linestring.
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Darafei "Komяpa" Praliaskouski
When performong ST_3DIntersection(geom, box3d), will approach with line do the thing that's awaited from it clipping geometry by the box, or make strange multipoint/multilinestring/EMPTY intersection? :)

пт, 26 февр. 2016 г. в 17:34, Paul Ramsey <[hidden email]>:
Codacil to this: a linestring involves an lwline and a pointarray, a
multipoint involves a multipoint, 2 x point, 2 x pointarray, so
there's a minor efficiency in sticking w/ the line.

On Thu, Feb 18, 2016 at 1:27 PM, Rémi Cura <[hidden email]> wrote:
> Exactly,
> in the end it's just 2 points.
> I personally would prefer to keep it as 2 points,
> because I feel a line is semantically more different,
> but it amounts to the same thing in the end.
>
> Cheers,
> Rémi-C
>
> 2016-02-18 11:36 GMT+01:00 Sandro Santilli <[hidden email]>:
>>
>> On Thu, Feb 18, 2016 at 11:02:49AM +0100, Rémi Cura wrote:
>> > Using Even trick saves me about 25% time.
>> > Good !
>>
>> Right, it's the same approach of the "BoundingDiagonal",
>> only he does it with a 2-members multipoint rather than
>> with a 2-vertices linestring.
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
12