# [postgis-users] New within problem

strk at refractions.net strk at refractions.net
Thu Jul 28 09:06:22 PDT 2005

```On Thu, Jul 28, 2005 at 12:01:24PM -0300, Miguel de la Fuente wrote:
> I think I didn't explain it very well.
>
> what I don't understand is why Within(g1,g2) returns me False while g1
> is in fact a segment of g2, so g1 is "within" g2.
>
> WITHIN(g1,g2) returns FALSE
>
> And only because of it is that I added the within functions between
> their box2d(), and their geometryfromtext(astext()), and they return
> me TRUE as I expected.
>
> WITHIN(BOX2D(g1),BOX2D(g2)) returns TRUE
> WITHIN(GEOMETRYFROMTEXT(ASTEXT(g1)),GEOMETRYFROMTEXT(ASTEXT(g2))) returns TRUE

Ok, sorry, I answered too fast.
Also it seems I was wrong about within definition ...

I've reduced your problem to a single point, starting
from the WKB you provided.

g1: 01010000001BA43BA50E5A5541A12F8367C8095641
g2: 01010000001BA43BA50E5A5541A02F8367C8095641
^
The two points are *different*, so within() output
is correct.

within(g1, g2) == false
intersects(g1, g2) == false

Passing the first geometry (g1) trough WKT and back
makes it the same of g2:

geometryfromtext(astext(g1)) === g2 :
01010000001BA43BA50E5A5541A02F8367C8095641

Did one of your geometries come from a GeomFromText input
func while the other directly from a shapefile ?

In general, you should not be using GeometryFromText
to extract elements from your goemetries if you want to
retain precision.

Or, as an alternative, pass ALL your geoms trough the SnapToGrid
function to enforce a grid/precision system.
Using GeometryFromText is like calling SnapToGrid using the
smallest representable float number as grid size.

--strk;

```