Does ST_AsText truncate or round

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

Does ST_AsText truncate or round

Regina Obe-2
Hopefully this is a simple question.  I know that ST_AsText returns a
geometry that is not necessarily as prescise as what is actually stored in
the geometry field.  I have an editor that relies on WKT representation.

Anyrate just wanted to know if the ST_AsText does a rounding of the points
or it does a truncation of the points.  Also would be nice to know if I
could control the precision of this since I will need to truncate my actual
geometry accordingly so that both are in agreement.

Thanks,
Regina


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe-2
Slight clarification about what I am trying to solve.

After edits I am coming back with lines that used to be intersecting no
longer intersecting and that still have the same AsText representation.

My hope is to reduce the precision of my geometry in the database so the
edits don't break the topology of my lines by doing something like this


Update sometable
        SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)


But I fear that if AsText is doing a rounding rather than a truncation, that
I run the risk of breaking things that used to intersect.  I am more
concerned about under intersecting than over intersecting.  Although I
probably haven't thought this out enough so maybe it's a non-issue.

Thanks,
Regina

 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Paragon
Corporation
Sent: Friday, May 16, 2008 12:01 AM
To: 'PostGIS Users Discussion'
Subject: [postgis-users] Does ST_AsText truncate or round

Hopefully this is a simple question.  I know that ST_AsText returns a
geometry that is not necessarily as prescise as what is actually stored in
the geometry field.  I have an editor that relies on WKT representation.

Anyrate just wanted to know if the ST_AsText does a rounding of the points
or it does a truncation of the points.  Also would be nice to know if I
could control the precision of this since I will need to truncate my actual
geometry accordingly so that both are in agreement.

Thanks,
Regina


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Paul Ramsey-3
It all falls down into this function:

write_double(double val){
        ensure(32);
        if (lwgi)
                sprintf(out_pos,"%.8g",val);
        else
                sprintf(out_pos,"%.15g",val);
        to_end();
}



On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]> wrote:

> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting no
> longer intersecting and that still have the same AsText representation.
>
> My hope is to reduce the precision of my geometry in the database so the
> edits don't break the topology of my lines by doing something like this
>
>
> Update sometable
>        SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>
>
> But I fear that if AsText is doing a rounding rather than a truncation, that
> I run the risk of breaking things that used to intersect.  I am more
> concerned about under intersecting than over intersecting.  Although I
> probably haven't thought this out enough so maybe it's a non-issue.
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Paragon
> Corporation
> Sent: Friday, May 16, 2008 12:01 AM
> To: 'PostGIS Users Discussion'
> Subject: [postgis-users] Does ST_AsText truncate or round
>
> Hopefully this is a simple question.  I know that ST_AsText returns a
> geometry that is not necessarily as prescise as what is actually stored in
> the geometry field.  I have an editor that relies on WKT representation.
>
> Anyrate just wanted to know if the ST_AsText does a rounding of the points
> or it does a truncation of the points.  Also would be nice to know if I
> could control the precision of this since I will need to truncate my actual
> geometry accordingly so that both are in agreement.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Havard Tveite
ST_GeomFromText(ST_AsText(geom)) != geom

sounds like a bug to me (ignoring the SRS).

Håvard

Paul Ramsey wrote:

> It all falls down into this function:
>
> write_double(double val){
>         ensure(32);
>         if (lwgi)
>                 sprintf(out_pos,"%.8g",val);
>         else
>                 sprintf(out_pos,"%.15g",val);
>         to_end();
> }
>
>
>
> On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]> wrote:
>> Slight clarification about what I am trying to solve.
>>
>> After edits I am coming back with lines that used to be intersecting no
>> longer intersecting and that still have the same AsText representation.
>>
>> My hope is to reduce the precision of my geometry in the database so the
>> edits don't break the topology of my lines by doing something like this
>>
>>
>> Update sometable
>>        SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>
>>
>> But I fear that if AsText is doing a rounding rather than a truncation, that
>> I run the risk of breaking things that used to intersect.  I am more
>> concerned about under intersecting than over intersecting.  Although I
>> probably haven't thought this out enough so maybe it's a non-issue.
>>
>> Thanks,
>> Regina
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Paragon
>> Corporation
>> Sent: Friday, May 16, 2008 12:01 AM
>> To: 'PostGIS Users Discussion'
>> Subject: [postgis-users] Does ST_AsText truncate or round
>>
>> Hopefully this is a simple question.  I know that ST_AsText returns a
>> geometry that is not necessarily as prescise as what is actually stored in
>> the geometry field.  I have an editor that relies on WKT representation.
>>
>> Anyrate just wanted to know if the ST_AsText does a rounding of the points
>> or it does a truncation of the points.  Also would be nice to know if I
>> could control the precision of this since I will need to truncate my actual
>> geometry accordingly so that both are in agreement.
>>
>> Thanks,
>> Regina
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Paul Ramsey-3
In reply to this post by Regina Obe-2
Kevin might have some thoughts, he's wrestled with this.

You could put a post-update, post-insert trigger that runs a fine snap
to grid. This will ensure that all vertices remain cojoint. What it
won't do is help with places of co-linearity where there are not
co-vertexes.

P.

On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]> wrote:
> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting no
> longer intersecting and that still have the same AsText representation.
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Kevin Neufeld
In reply to this post by Regina Obe-2
Have you considered using ST_SnapToGrid() and make all geometries in you
database respect a specified tolerance?

Warning, snaptogrid may not behave as you might expect - this is not a
simple precision_reducer method (which I think would be valuable).

Consider:
select
   'POINT(0.877 0.778)'::geometry ~=
   snaptogrid('POINT(0.87689017271623 0.777984935324639)'::geometry, 0.001);

  ?column?
----------
  t
(1 row)

No problem there, but then there's this:
select
   'POINT(0.956 0.66)'::geometry ~=
   snaptogrid('POINT(0.956079571507871 0.659502930939198)'::geometry,
0.001);

  ?column?
----------
  f
(1 row)


To deal with this (I know it looks like a hack, but it works), I convert
to text and then back to a geometry.  Wrapping this in a trigger on your
geometry tables will guarantee any geometry edits are automatically
reduced to a certain precision.

select
    'POINT(0.956 0.66)'::geometry ~=
    geomfromtext(astext(snaptogrid('POINT(0.956079571507871
0.659502930939198)'::geometry, 0.001)), -1);

  ?column?
----------
  t
(1 row)


Cheers,
Kevin

Paragon Corporation wrote:

> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting no
> longer intersecting and that still have the same AsText representation.
>
> My hope is to reduce the precision of my geometry in the database so the
> edits don't break the topology of my lines by doing something like this
>
>
> Update sometable
> SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>
>
> But I fear that if AsText is doing a rounding rather than a truncation, that
> I run the risk of breaking things that used to intersect.  I am more
> concerned about under intersecting than over intersecting.  Although I
> probably haven't thought this out enough so maybe it's a non-issue.
>
> Thanks,
> Regina
>
>  
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Paragon
> Corporation
> Sent: Friday, May 16, 2008 12:01 AM
> To: 'PostGIS Users Discussion'
> Subject: [postgis-users] Does ST_AsText truncate or round
>
> Hopefully this is a simple question.  I know that ST_AsText returns a
> geometry that is not necessarily as prescise as what is actually stored in
> the geometry field.  I have an editor that relies on WKT representation.
>
> Anyrate just wanted to know if the ST_AsText does a rounding of the points
> or it does a truncation of the points.  Also would be nice to know if I
> could control the precision of this since I will need to truncate my actual
> geometry accordingly so that both are in agreement.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Mark Cave-Ayland-3
In reply to this post by Havard Tveite
Håvard Tveite wrote:
> ST_GeomFromText(ST_AsText(geom)) != geom
>
> sounds like a bug to me (ignoring the SRS).
>
> Håvard

No, since the SFS 1.1 specification supports only 2 dimensions with no
SRS (and ST_AsText() is spec compliant). If you need the SRS then you
should use the PostGIS-enhanced ST_EWKT() function which will output the
extra information, but is not spec-compliant.


ATB,

Mark.

--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe-2
In reply to this post by Kevin Neufeld
Kevin,

Actually this would help me with the second phase, but for the first phase I
just need consistency which I was hoping AsText would do for me.  It doesn't
even need to be that good since I'm sure the other side is using AsText in
some fashion.  So I just need consistency more than correctness.

Where I start off with

Orginal geometry X

I think I need to guarantee that

X =  GeomFromText(AsText(X))

Seemed like the easiest way to assure that was to just force all my Xs to X
= ST_GeomFromText(AsText(X), somesrid)    which I presume should be the same
as

ST_SetSRID(AsText(X), somesrid)  

The back end editor I'm assuming is just taking the AsText(geometry)
representation and just returning that back when no edits on a particular
point,  and so its being poisoned by its own database query.  I'm not
working on that part so that's just my general observation.

Thanks,
Regina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin
Neufeld
Sent: Friday, May 16, 2008 11:15 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

Have you considered using ST_SnapToGrid() and make all geometries in you
database respect a specified tolerance?

Warning, snaptogrid may not behave as you might expect - this is not a
simple precision_reducer method (which I think would be valuable).

Consider:
select
   'POINT(0.877 0.778)'::geometry ~=
   snaptogrid('POINT(0.87689017271623 0.777984935324639)'::geometry, 0.001);

  ?column?
----------
  t
(1 row)

No problem there, but then there's this:
select
   'POINT(0.956 0.66)'::geometry ~=
   snaptogrid('POINT(0.956079571507871 0.659502930939198)'::geometry,
0.001);

  ?column?
----------
  f
(1 row)


To deal with this (I know it looks like a hack, but it works), I convert to
text and then back to a geometry.  Wrapping this in a trigger on your
geometry tables will guarantee any geometry edits are automatically reduced
to a certain precision.

select
    'POINT(0.956 0.66)'::geometry ~=
    geomfromtext(astext(snaptogrid('POINT(0.956079571507871
0.659502930939198)'::geometry, 0.001)), -1);

  ?column?
----------
  t
(1 row)


Cheers,
Kevin

Paragon Corporation wrote:

> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting
> no longer intersecting and that still have the same AsText representation.
>
> My hope is to reduce the precision of my geometry in the database so
> the edits don't break the topology of my lines by doing something like
> this
>
>
> Update sometable
> SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>
>
> But I fear that if AsText is doing a rounding rather than a
> truncation, that I run the risk of breaking things that used to
> intersect.  I am more concerned about under intersecting than over
> intersecting.  Although I probably haven't thought this out enough so
maybe it's a non-issue.

>
> Thanks,
> Regina
>
>  
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Paragon Corporation
> Sent: Friday, May 16, 2008 12:01 AM
> To: 'PostGIS Users Discussion'
> Subject: [postgis-users] Does ST_AsText truncate or round
>
> Hopefully this is a simple question.  I know that ST_AsText returns a
> geometry that is not necessarily as prescise as what is actually
> stored in the geometry field.  I have an editor that relies on WKT
representation.

>
> Anyrate just wanted to know if the ST_AsText does a rounding of the
> points or it does a truncation of the points.  Also would be nice to
> know if I could control the precision of this since I will need to
> truncate my actual geometry accordingly so that both are in agreement.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users



_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Havard Tveite
In reply to this post by Mark Cave-Ayland-3
Sorry, for not making much sense here.  What I wanted to
say was that ST_AsText(geom) should be equivalent to geom,
meaning that if you go from the database/binary
representation of the geometry to the text representation
of the geometry (using ST_AsText) and then back to the
database/binary representation (using ST_GeomFromText),
you should end up with the same geometry that you
started out with.  This is important for applications
that use when WKT when talking to PostGIS.

Håvard


Mark Cave-Ayland wrote:

> Håvard Tveite wrote:
>> ST_GeomFromText(ST_AsText(geom)) != geom
>>
>> sounds like a bug to me (ignoring the SRS).
>>
>> Håvard
>
> No, since the SFS 1.1 specification supports only 2 dimensions with no
> SRS (and ST_AsText() is spec compliant). If you need the SRS then you
> should use the PostGIS-enhanced ST_EWKT() function which will output the
> extra information, but is not spec-compliant.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe
Re: [postgis-users] Does ST_AsText truncate or round
Havard,
 
I think as Mark mentioned  if it did it would violate the spec.  I think somewhere in the spec is some specification of guaranteed precision of WKT and if there isn't - text can never represent floating to complete accuracy.  The AsBinary I think on the other hand is exact fidelity.  So simply trying to make them equal would probably irritate people who need precision higher than what the WKT spec offers.
 
In my particular case of course this would be ideal - but I can't be selfish  :)
 
So I can live with the general rule that 
 
ST_GeomFromText(ST_AsText(geom), srid here) != geom
 
As long as I can override it by  updating my millions of geometries to so and 300 someodd tables with
 
SET the_geom = ST_GeomFromText(ST_AsText(geom))
 
without too many weird side effects.  I may just try it and see if it causes other problems elsewhere.
 
testing with the badly edited records  it seems to at least make my other geometries just as inprecise as the edited ones so I get intersection where I should again.
 
Thanks,
Regina
 
 



From: [hidden email] on behalf of Havard Tveite
Sent: Fri 5/16/2008 2:41 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

Sorry, for not making much sense here.  What I wanted to
say was that ST_AsText(geom) should be equivalent to geom,
meaning that if you go from the database/binary
representation of the geometry to the text representation
of the geometry (using ST_AsText) and then back to the
database/binary representation (using ST_GeomFromText),
you should end up with the same geometry that you
started out with.  This is important for applications
that use when WKT when talking to PostGIS.

Håvard


Mark Cave-Ayland wrote:


> Håvard Tveite wrote:
>> ST_GeomFromText(ST_AsText(geom)) != geom
>>
>> sounds like a bug to me (ignoring the SRS).
>>
>> Håvard
>
> No, since the SFS 1.1 specification supports only 2 dimensions with no
> SRS (and ST_AsText() is spec compliant). If you need the SRS then you
> should use the PostGIS-enhanced ST_EWKT() function which will output the
> extra information, but is not spec-compliant.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users


The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.


Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper.


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe
In reply to this post by Paul Ramsey-3
Paul,

I think you mistook me for a C programmer if you actually thought I
could figure out my answer from this snippet of code :)

First I can't remember what g means.  I remember seeing fs and gs
somewhere before so I can only assume that f means round and g means
truncate?

Secondly what does lwgi stand-for - I can only guess it means
light-weight geom or something along that  - so does that mean that as
far as I'm concerned - .8g is the loop I'm interested in?  Do we even
use non-light weight anymore?

Thanks,
Regina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Paul
Ramsey
Sent: Friday, May 16, 2008 10:39 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

It all falls down into this function:

write_double(double val){
        ensure(32);
        if (lwgi)
                sprintf(out_pos,"%.8g",val);
        else
                sprintf(out_pos,"%.15g",val);
        to_end();
}



On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]>
wrote:
> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting
no
> longer intersecting and that still have the same AsText
representation.
>
> My hope is to reduce the precision of my geometry in the database so
the
> edits don't break the topology of my lines by doing something like
this
>
>
> Update sometable
>        SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>
>
> But I fear that if AsText is doing a rounding rather than a
truncation, that

> I run the risk of breaking things that used to intersect.  I am more
> concerned about under intersecting than over intersecting.  Although I
> probably haven't thought this out enough so maybe it's a non-issue.
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
Paragon
> Corporation
> Sent: Friday, May 16, 2008 12:01 AM
> To: 'PostGIS Users Discussion'
> Subject: [postgis-users] Does ST_AsText truncate or round
>
> Hopefully this is a simple question.  I know that ST_AsText returns a
> geometry that is not necessarily as prescise as what is actually
stored in
> the geometry field.  I have an editor that relies on WKT
representation.
>
> Anyrate just wanted to know if the ST_AsText does a rounding of the
points
> or it does a truncation of the points.  Also would be nice to know if
I
> could control the precision of this since I will need to truncate my
actual

> geometry accordingly so that both are in agreement.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Gregory Williamson
RE: [postgis-users] Does ST_AsText truncate or round

Regina --

I think the lwgi is testing for whether the installation has the "light-weight" postGIS stuff -- fewer decimal places resulting (%f and %g are formatting options in a print statememnt for decimal representation -- so 8 or 15 places respectively.

(I think -- never crawled into the guts of postGIS' C code).

(Sorry for top posting and the disclaimer -- only one per thread, I promise!)

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)



-----Original Message-----
From: [hidden email] on behalf of Obe, Regina
Sent: Fri 5/16/2008 12:33 PM
To: PostGIS Users Discussion
Subject: RE: [postgis-users] Does ST_AsText truncate or round

Paul,

I think you mistook me for a C programmer if you actually thought I
could figure out my answer from this snippet of code :)

First I can't remember what g means.  I remember seeing fs and gs
somewhere before so I can only assume that f means round and g means
truncate?

Secondly what does lwgi stand-for - I can only guess it means
light-weight geom or something along that  - so does that mean that as
far as I'm concerned - .8g is the loop I'm interested in?  Do we even
use non-light weight anymore?

Thanks,
Regina

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Paul
Ramsey
Sent: Friday, May 16, 2008 10:39 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

It all falls down into this function:

write_double(double val){
        ensure(32);
        if (lwgi)
                sprintf(out_pos,"%.8g",val);
        else
                sprintf(out_pos,"%.15g",val);
        to_end();
}



On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]>
wrote:
> Slight clarification about what I am trying to solve.
>
> After edits I am coming back with lines that used to be intersecting
no
> longer intersecting and that still have the same AsText
representation.
>
> My hope is to reduce the precision of my geometry in the database so
the
> edits don't break the topology of my lines by doing something like
this
>
>
> Update sometable
>        SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>
>
> But I fear that if AsText is doing a rounding rather than a
truncation, that
> I run the risk of breaking things that used to intersect.  I am more
> concerned about under intersecting than over intersecting.  Although I
> probably haven't thought this out enough so maybe it's a non-issue.
>
> Thanks,
> Regina
>
>
>
> -----Original Message-----
> From: [hidden email]
> [[hidden email]] On Behalf Of
Paragon
> Corporation
> Sent: Friday, May 16, 2008 12:01 AM
> To: 'PostGIS Users Discussion'
> Subject: [postgis-users] Does ST_AsText truncate or round
>
> Hopefully this is a simple question.  I know that ST_AsText returns a
> geometry that is not necessarily as prescise as what is actually
stored in
> the geometry field.  I have an editor that relies on WKT
representation.
>
> Anyrate just wanted to know if the ST_AsText does a rounding of the
points
> or it does a truncation of the points.  Also would be nice to know if
I
> could control the precision of this since I will need to truncate my
actual
> geometry accordingly so that both are in agreement.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Andy Anderson-3
In reply to this post by Regina Obe
f & g are output formatting codes, f is the normal double-precision  
format, while g produces scientific notation (mmmE+xx) if the number  
is < 0.0001. The 8 and 15 represent the number of significant digits  
to print (for g).

-- Andy

On May 16, 2008, at 3:33 PM, Obe, Regina wrote:

> First I can't remember what g means.  I remember seeing fs and gs
> somewhere before so I can only assume that f means round and g means
> truncate?
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of  
> Paul
> Ramsey
> Sent: Friday, May 16, 2008 10:39 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>
> It all falls down into this function:
>
> write_double(double val){
>        ensure(32);
>        if (lwgi)
>                sprintf(out_pos,"%.8g",val);
>        else
>                sprintf(out_pos,"%.15g",val);
>        to_end();
> }
>
>
>
> On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]>
> wrote:
>> Slight clarification about what I am trying to solve.
>>
>> After edits I am coming back with lines that used to be intersecting
> no
>> longer intersecting and that still have the same AsText
> representation.
>>
>> My hope is to reduce the precision of my geometry in the database so
> the
>> edits don't break the topology of my lines by doing something like
> this
>>
>>
>> Update sometable
>>       SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>
>>
>> But I fear that if AsText is doing a rounding rather than a
> truncation, that
>> I run the risk of breaking things that used to intersect.  I am more
>> concerned about under intersecting than over intersecting.  
>> Although I
>> probably haven't thought this out enough so maybe it's a non-issue.
>>
>> Thanks,
>> Regina
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
> Paragon
>> Corporation
>> Sent: Friday, May 16, 2008 12:01 AM
>> To: 'PostGIS Users Discussion'
>> Subject: [postgis-users] Does ST_AsText truncate or round
>>
>> Hopefully this is a simple question.  I know that ST_AsText returns a
>> geometry that is not necessarily as prescise as what is actually
> stored in
>> the geometry field.  I have an editor that relies on WKT
> representation.
>>
>> Anyrate just wanted to know if the ST_AsText does a rounding of the
> points
>> or it does a truncation of the points.  Also would be nice to know if
> I
>> could control the precision of this since I will need to truncate my
> actual
>> geometry accordingly so that both are in agreement.
>>
>> Thanks,
>> Regina
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe
Thanks Andy and Greg for the clarification,

Sorry for being so dense.

So I take it sprintf would never ever do any rounding (they merely print
% significant digits).  So g and f always truncate but g can flip to
scientific if < .001

http://www.cplusplus.com/reference/clibrary/cstdio/sprintf.html

Thanks,
Regina


 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Andy
Anderson
Sent: Friday, May 16, 2008 4:36 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

f & g are output formatting codes, f is the normal double-precision  
format, while g produces scientific notation (mmmE+xx) if the number  
is < 0.0001. The 8 and 15 represent the number of significant digits  
to print (for g).

-- Andy

On May 16, 2008, at 3:33 PM, Obe, Regina wrote:

> First I can't remember what g means.  I remember seeing fs and gs
> somewhere before so I can only assume that f means round and g means
> truncate?
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of  
> Paul
> Ramsey
> Sent: Friday, May 16, 2008 10:39 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>
> It all falls down into this function:
>
> write_double(double val){
>        ensure(32);
>        if (lwgi)
>                sprintf(out_pos,"%.8g",val);
>        else
>                sprintf(out_pos,"%.15g",val);
>        to_end();
> }
>
>
>
> On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]>
> wrote:
>> Slight clarification about what I am trying to solve.
>>
>> After edits I am coming back with lines that used to be intersecting
> no
>> longer intersecting and that still have the same AsText
> representation.
>>
>> My hope is to reduce the precision of my geometry in the database so
> the
>> edits don't break the topology of my lines by doing something like
> this
>>
>>
>> Update sometable
>>       SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>
>>
>> But I fear that if AsText is doing a rounding rather than a
> truncation, that
>> I run the risk of breaking things that used to intersect.  I am more
>> concerned about under intersecting than over intersecting.  
>> Although I
>> probably haven't thought this out enough so maybe it's a non-issue.
>>
>> Thanks,
>> Regina
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
> Paragon
>> Corporation
>> Sent: Friday, May 16, 2008 12:01 AM
>> To: 'PostGIS Users Discussion'
>> Subject: [postgis-users] Does ST_AsText truncate or round
>>
>> Hopefully this is a simple question.  I know that ST_AsText returns a
>> geometry that is not necessarily as prescise as what is actually
> stored in
>> the geometry field.  I have an editor that relies on WKT
> representation.
>>
>> Anyrate just wanted to know if the ST_AsText does a rounding of the
> points
>> or it does a truncation of the points.  Also would be nice to know if
> I
>> could control the precision of this since I will need to truncate my
> actual
>> geometry accordingly so that both are in agreement.
>>
>> Thanks,
>> Regina
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Andy Anderson-3
Sorry, given the subject I should have said that they -will- round  
off/half up (format ~ %field_width.precision):

%6.6f  %6.5f  %6.2g  %6.1g

0.000014  0.00001  1.4e-05   1e-05
0.000015  0.00002  1.6e-05   2e-05
0.000016  0.00002  1.6e-05   2e-05

Note, however, that rounding-versus-truncating won't mean much at the  
limits of precision (16 digits for double), because that last digit  
is soemtimes inaccurate anyway:

        http://en.wikipedia.org/wiki/Double_precision

I don't know if the choice of a precision of 15 is just to be careful  
or is part of a spec.

-- Andy

P.S. the code for the above table:

#include <stdio.h>

main()
{
         double round_down = 0.000014;
         double round_up = 0.000016;
         double round_half = 0.000015;

         char format[] = "%6.6f  %6.5f  %6.2g  %6.1g\n";

         (void) puts(format);
         (void) printf(format, round_down, round_down, round_down,  
round_down);
         (void) printf(format, round_half, round_half, round_up,  
round_half);
         (void) printf(format, round_up, round_up, round_up, round_up);
}


On May 16, 2008, at 4:56 PM, Obe, Regina wrote:

> Thanks Andy and Greg for the clarification,
>
> Sorry for being so dense.
>
> So I take it sprintf would never ever do any rounding (they merely  
> print
> % significant digits).  So g and f always truncate but g can flip to
> scientific if < .001
>
> http://www.cplusplus.com/reference/clibrary/cstdio/sprintf.html
>
> Thanks,
> Regina
>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of  
> Andy
> Anderson
> Sent: Friday, May 16, 2008 4:36 PM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>
> f & g are output formatting codes, f is the normal double-precision
> format, while g produces scientific notation (mmmE+xx) if the number
> is < 0.0001. The 8 and 15 represent the number of significant digits
> to print (for g).
>
> -- Andy
>
> On May 16, 2008, at 3:33 PM, Obe, Regina wrote:
>> First I can't remember what g means.  I remember seeing fs and gs
>> somewhere before so I can only assume that f means round and g means
>> truncate?
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Paul
>> Ramsey
>> Sent: Friday, May 16, 2008 10:39 AM
>> To: PostGIS Users Discussion
>> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>>
>> It all falls down into this function:
>>
>> write_double(double val){
>>        ensure(32);
>>        if (lwgi)
>>                sprintf(out_pos,"%.8g",val);
>>        else
>>                sprintf(out_pos,"%.15g",val);
>>        to_end();
>> }
>>
>>
>>
>> On Fri, May 16, 2008 at 3:23 AM, Paragon Corporation <[hidden email]>
>> wrote:
>>> Slight clarification about what I am trying to solve.
>>>
>>> After edits I am coming back with lines that used to be intersecting
>> no
>>> longer intersecting and that still have the same AsText
>> representation.
>>>
>>> My hope is to reduce the precision of my geometry in the database so
>> the
>>> edits don't break the topology of my lines by doing something like
>> this
>>>
>>>
>>> Update sometable
>>>       SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>>
>>>
>>> But I fear that if AsText is doing a rounding rather than a
>> truncation, that
>>> I run the risk of breaking things that used to intersect.  I am more
>>> concerned about under intersecting than over intersecting.
>>> Although I
>>> probably haven't thought this out enough so maybe it's a non-issue.
>>>
>>> Thanks,
>>> Regina
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>> Paragon
>>> Corporation
>>> Sent: Friday, May 16, 2008 12:01 AM
>>> To: 'PostGIS Users Discussion'
>>> Subject: [postgis-users] Does ST_AsText truncate or round
>>>
>>> Hopefully this is a simple question.  I know that ST_AsText  
>>> returns a
>>> geometry that is not necessarily as prescise as what is actually
>> stored in
>>> the geometry field.  I have an editor that relies on WKT
>> representation.
>>>
>>> Anyrate just wanted to know if the ST_AsText does a rounding of the
>> points
>>> or it does a truncation of the points.  Also would be nice to  
>>> know if
>> I
>>> could control the precision of this since I will need to truncate my
>> actual
>>> geometry accordingly so that both are in agreement.
>>>
>>> Thanks,
>>> Regina
>>>
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> [hidden email]
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> [hidden email]
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>> -----------------------------------------
>> The substance of this message, including any attachments, may be
>> confidential, legally privileged and/or exempt from disclosure
>> pursuant to Massachusetts law. It is intended
>> solely for the addressee. If you received this in error, please
>> contact the sender and delete the material from any computer.
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Havard Tveite
In reply to this post by Regina Obe
I checked the OGC Simple Feature Access specifications.
<URL: http://www.opengeospatial.org/standards/sfa >, and
could not find anything that limits the precision of WKT.

The SFA 1.1.0  spec
<Point> := <x> <y>
<x> := double precision literal
<y> := double precision literal

Double precision literal does not seem to be defined further,
but I would assume that this does not make it impossible to
represent the PostGIS coordinate precision.

The SFA 1.2.0 spec:
<point> ::= <x> <y>
<x> ::= <signed numeric literal>
<y> ::= <signed numeric literal>
<signed numeric literal> ::=   {<sign>}<unsigned numeric literal>
<unsigned numeric literal> ::= <exact numeric literal>
                                     |<approximate numeric literal>
<approximate numeric literal> ::=          <mantissa>E<exponent>
<mantissa> ::=                 <exact numeric literal>
<exponent> ::=                 <signed integer>
<exact numeric literal> ::=    <unsigned integer>
                                   {<decimal point>{<unsigned integer>}}
                                   |<decimal point><unsigned integer>
<signed integer> ::=           {<sign>}<unsigned integer>
<unsigned integer> ::=         (<digit>)*

This BNF gives no limit to the number of digits used before or after
the decimal point.  I have not found anything that limits the number
of digits.


Håvard

Obe, Regina wrote:

> Havard,
>  
> I think as Mark mentioned  if it did it would violate the spec.  I think
> somewhere in the spec is some specification of guaranteed precision of
> WKT and if there isn't - text can never represent floating to complete
> accuracy.  The AsBinary I think on the other hand is exact fidelity.  So
> simply trying to make them equal would probably irritate people who need
> precision higher than what the WKT spec offers.
>  
> In my particular case of course this would be ideal - but I can't be
> selfish  :)
>  
> So I can live with the general rule that
>  
> ST_GeomFromText(ST_AsText(geom), srid here) != geom
>  
> As long as I can override it by  updating my millions of geometries to
> so and 300 someodd tables with
>  
> SET the_geom = ST_GeomFromText(ST_AsText(geom))
>  
> without too many weird side effects.  I may just try it and see if it
> causes other problems elsewhere.
>  
> testing with the badly edited records  it seems to at least make my
> other geometries just as inprecise as the edited ones so I get
> intersection where I should again.
>  
> Thanks,
> Regina
>  
>  
>
>
> ------------------------------------------------------------------------
> *From:* [hidden email] on behalf of
> Havard Tveite
> *Sent:* Fri 5/16/2008 2:41 PM
> *To:* PostGIS Users Discussion
> *Subject:* Re: [postgis-users] Does ST_AsText truncate or round
>
> Sorry, for not making much sense here.  What I wanted to
> say was that ST_AsText(geom) should be equivalent to geom,
> meaning that if you go from the database/binary
> representation of the geometry to the text representation
> of the geometry (using ST_AsText) and then back to the
> database/binary representation (using ST_GeomFromText),
> you should end up with the same geometry that you
> started out with.  This is important for applications
> that use when WKT when talking to PostGIS.
>
> Håvard
>
>
> Mark Cave-Ayland wrote:
>  > Håvard Tveite wrote:
>  >> ST_GeomFromText(ST_AsText(geom)) != geom
>  >>
>  >> sounds like a bug to me (ignoring the SRS).
>  >>
>  >> Håvard
>  >
>  > No, since the SFS 1.1 specification supports only 2 dimensions with no
>  > SRS (and ST_AsText() is spec compliant). If you need the SRS then you
>  > should use the PostGIS-enhanced ST_EWKT() function which will output the
>  > extra information, but is not spec-compliant.
>  >
>  >
>  > ATB,
>  >
>  > Mark.
>  >
>  > --
>  > Mark Cave-Ayland
>  > Sirius Corporation - The Open Source Experts
>  > http://www.siriusit.co.uk <http://www.siriusit.co.uk/>
>  > T: +44 870 608 0063
>  > _______________________________________________
>  > postgis-users mailing list
>  > [hidden email]
>  > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> ------------------------------------------------------------------------
>
> * The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure pursuant
> to Massachusetts law. It is intended solely for the addressee. If you
> received this in error, please contact the sender and delete the
> material from any computer. *
>
> ------------------------------------------------------------------------
>
> * Help make the earth a greener place. If at all possible resist
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe-2
It would be interesting to know what various vendors do when they get the
data in WKT and when they send it back in WKT.  What assumptions do they
make about precision if there is no universally defined guideline for that.

For example if I'm sending the data in 15 decimal precision and the other
side has standardized on 7 or 8 or whatever., it really does me no good.
The transport back and forth is going to cause issues.  So I would want to
reduce the precision of my data to 8 or whatever to agree or be lower than
the other side.

Frankly we are discussing that we don't even want all those digits we want
to truncate down to about 5 decimals for our need.  So I guess as long as
that is lower than what the other side is expecting presumably when we
truncate what they give us it will be fine.

It would be nice as Kevin mentioned if PostGIS had a truncation function -
e.g. pgis_GeomTruncate(geom, 8)
That would force all your geometries to a lower precision, and not round but
truncate - because the point is I don't trust those digits out there.

Part of the problem is that the Transformation step we have is introducing a
lot more digits and digits we don't really trust than we care to keep.
While we are raising gotchas here.  The issue of ST_Transform not quite
being reversible (not sure if this is the case in all cases - I know some it
doesn't even make sense) is a bit troubling.

E.g. If you have say your data in srid1  

SELECT ST_Transform(ST_Transform(the_geom, srid2), srid1)

It is off a bit from what you started out with.  It gets progressively worse
the more transformations you pile on.  Perhaps there is no easy solution to
it.  
A large part of it I assume is just accumulation of floating point errors.

And one time I even saw it break the topology of my data (e.g. things that
intersected before no longer do after 4 layers of transforms)

Thanks,
Regina






 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Havard
Tveite
Sent: Friday, May 16, 2008 5:45 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

I checked the OGC Simple Feature Access specifications.
<URL: http://www.opengeospatial.org/standards/sfa >, and could not find
anything that limits the precision of WKT.

The SFA 1.1.0  spec
<Point> := <x> <y>
<x> := double precision literal
<y> := double precision literal

Double precision literal does not seem to be defined further, but I would
assume that this does not make it impossible to represent the PostGIS
coordinate precision.

The SFA 1.2.0 spec:
<point> ::= <x> <y>
<x> ::= <signed numeric literal>
<y> ::= <signed numeric literal>
<signed numeric literal> ::=   {<sign>}<unsigned numeric literal>
<unsigned numeric literal> ::= <exact numeric literal>
                                     |<approximate numeric literal>
<approximate numeric literal> ::=          <mantissa>E<exponent>
<mantissa> ::=                 <exact numeric literal>
<exponent> ::=                 <signed integer>
<exact numeric literal> ::=    <unsigned integer>
                                   {<decimal point>{<unsigned integer>}}
                                   |<decimal point><unsigned integer>
<signed integer> ::=           {<sign>}<unsigned integer>
<unsigned integer> ::=         (<digit>)*

This BNF gives no limit to the number of digits used before or after the
decimal point.  I have not found anything that limits the number of digits.


Håvard

Obe, Regina wrote:

> Havard,
>  
> I think as Mark mentioned  if it did it would violate the spec.  I
> think somewhere in the spec is some specification of guaranteed
> precision of WKT and if there isn't - text can never represent
> floating to complete accuracy.  The AsBinary I think on the other hand
> is exact fidelity.  So simply trying to make them equal would probably
> irritate people who need precision higher than what the WKT spec offers.
>  
> In my particular case of course this would be ideal - but I can't be
> selfish  :)
>  
> So I can live with the general rule that
>  
> ST_GeomFromText(ST_AsText(geom), srid here) != geom
>  
> As long as I can override it by  updating my millions of geometries to
> so and 300 someodd tables with
>  
> SET the_geom = ST_GeomFromText(ST_AsText(geom))
>  
> without too many weird side effects.  I may just try it and see if it
> causes other problems elsewhere.
>  
> testing with the badly edited records  it seems to at least make my
> other geometries just as inprecise as the edited ones so I get
> intersection where I should again.
>  
> Thanks,
> Regina
>  
>  
>
>
> ----------------------------------------------------------------------
> --
> *From:* [hidden email] on behalf of
> Havard Tveite
> *Sent:* Fri 5/16/2008 2:41 PM
> *To:* PostGIS Users Discussion
> *Subject:* Re: [postgis-users] Does ST_AsText truncate or round
>
> Sorry, for not making much sense here.  What I wanted to say was that
> ST_AsText(geom) should be equivalent to geom, meaning that if you go
> from the database/binary representation of the geometry to the text
> representation of the geometry (using ST_AsText) and then back to the
> database/binary representation (using ST_GeomFromText), you should end
> up with the same geometry that you started out with.  This is
> important for applications that use when WKT when talking to PostGIS.
>
> Håvard
>
>
> Mark Cave-Ayland wrote:
>  > Håvard Tveite wrote:
>  >> ST_GeomFromText(ST_AsText(geom)) != geom  >>  >> sounds like a bug
> to me (ignoring the SRS).
>  >>
>  >> Håvard
>  >
>  > No, since the SFS 1.1 specification supports only 2 dimensions with
> no  > SRS (and ST_AsText() is spec compliant). If you need the SRS
> then you  > should use the PostGIS-enhanced ST_EWKT() function which
> will output the  > extra information, but is not spec-compliant.
>  >
>  >
>  > ATB,
>  >
>  > Mark.
>  >
>  > --
>  > Mark Cave-Ayland
>  > Sirius Corporation - The Open Source Experts  >
> http://www.siriusit.co.uk <http://www.siriusit.co.uk/>  > T: +44 870
> 608 0063  > _______________________________________________
>  > postgis-users mailing list
>  > [hidden email]
>  > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> ----------------------------------------------------------------------
> --
>
> * The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended solely for the
> addressee. If you received this in error, please contact the sender
> and delete the material from any computer. *
>
> ----------------------------------------------------------------------
> --
>
> * Help make the earth a greener place. If at all possible resist
> printing this email and join us in saving paper. *
>
> * *
>
> * *
>
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Paul Ramsey-3
On Sat, May 17, 2008 at 6:45 PM, Paragon Corporation <[hidden email]> wrote:

> SELECT ST_Transform(ST_Transform(the_geom, srid2), srid1)
>
> It is off a bit from what you started out with.  It gets progressively worse
> the more transformations you pile on.  Perhaps there is no easy solution to
> it.
> A large part of it I assume is just accumulation of floating point errors.

All of it is (if you stay entirely inside the database).

If you go outside the database, as a client application developer, you
should not be transiting your data in WKT, you should be doing it in
WKB. Make use the the PostGIS ST_AsBinary() functions to get true
representations of the internal data, and the PostgreSQL encode()
function to turn that byte array into a packed text format. Then do
the reverse in your client-side software.

Precision models are a topic of some debate, whether they improve the
situation inside the database or not. They can improve apparent
consistency in some cases, and reduce it in others. A proper precision
model would probably have to be applied after every transformation, so
that fully functional tests were consistent
centroid(transform(transform(X))) == centroid(X), but that would leave
some interesting issues hanging around, like: if my precision model is
a 0.001m grid in UTM, what is it in WGS84?

Carefully application of snapping in an application can help reduce
these issues, but they still manage to creep through. Kevin probably
has some interesting examples.

Try wrapping your calls in

ST_SnapToGrid(geometry, 0, 0, 0.0001, 0.0001)

Or place that as an insert/update trigger, to force everything into an
externalized grid. Note that you'll get bad results in places where
shared edges have un-matched co-linear vertices.

P.
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Does ST_AsText truncate or round

Kevin Neufeld
In reply to this post by Regina Obe-2
Hi Regina,
Sorry I didn't respond sooner ... I was out camping for the weekend.
Fun, fun :)

Right, this is what I was thinking with my previous post recommending
snaptogrid - force your geometries through WKT :
geomfromtext(astext(the_geom)).  Essentially, this would make all your
geometries only as precise as their WKT representation.  In a way, this
enforces a very fine precision model on all your geometries.  This
should elicit the data consistency you were after ... assuming of course
that all your table edits are performed using geomfromtext().  Bear in
mind, though, that if you have a client program that modifies the table
using WKB, you may be left with data in an inconsistent state.  If this
is the case, put a simple trigger on your tables forcing all UPDATES and
INSERTS through WKT.

I agree with Paul R, however, that a client application should not be
transiting data using WKT, but rather WKB.  It may take some work, but I
would recommend that you upgrade your apps to perform all data edits
using WKB.

He was right when he mentioned that I fought with this for a while.  I
had a large database that utilized the full precision of PostGIS. I did
some data editing using a simple WKT editor and suddenly found that
geometries that used to touch no longer touch or they intersect
incorrectly.

I guess it boils down to:
* A database that does not enforce any precision model, by default uses
full precision - thus, all data edits should be done using full precision.
* A database that enforces a precision model (including the one you
suggested where X = GeomFromText(AsText(X)) must be true), could be
edited using a editor with an equivalent precision model.  In your case,
a WKT enforced database could be edited using a WKT editor.  However, if
you can't guarantee that all editing is performed using WKT (including
updating a geometry using transform() ), then triggers should probably
be constructed enforcing the model on your spatial tables.


Cheers,
Kevin



Paragon Corporation wrote:

> Kevin,
>
> Actually this would help me with the second phase, but for the first phase I
> just need consistency which I was hoping AsText would do for me.  It doesn't
> even need to be that good since I'm sure the other side is using AsText in
> some fashion.  So I just need consistency more than correctness.
>
> Where I start off with
>
> Orginal geometry X
>
> I think I need to guarantee that
>
> X =  GeomFromText(AsText(X))
>
> Seemed like the easiest way to assure that was to just force all my Xs to X
> = ST_GeomFromText(AsText(X), somesrid)    which I presume should be the same
> as
>
> ST_SetSRID(AsText(X), somesrid)  
>
> The back end editor I'm assuming is just taking the AsText(geometry)
> representation and just returning that back when no edits on a particular
> point,  and so its being poisoned by its own database query.  I'm not
> working on that part so that's just my general observation.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kevin
> Neufeld
> Sent: Friday, May 16, 2008 11:15 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>
> Have you considered using ST_SnapToGrid() and make all geometries in you
> database respect a specified tolerance?
>
> Warning, snaptogrid may not behave as you might expect - this is not a
> simple precision_reducer method (which I think would be valuable).
>
> Consider:
> select
>    'POINT(0.877 0.778)'::geometry ~=
>    snaptogrid('POINT(0.87689017271623 0.777984935324639)'::geometry, 0.001);
>
>   ?column?
> ----------
>   t
> (1 row)
>
> No problem there, but then there's this:
> select
>    'POINT(0.956 0.66)'::geometry ~=
>    snaptogrid('POINT(0.956079571507871 0.659502930939198)'::geometry,
> 0.001);
>
>   ?column?
> ----------
>   f
> (1 row)
>
>
> To deal with this (I know it looks like a hack, but it works), I convert to
> text and then back to a geometry.  Wrapping this in a trigger on your
> geometry tables will guarantee any geometry edits are automatically reduced
> to a certain precision.
>
> select
>     'POINT(0.956 0.66)'::geometry ~=
>     geomfromtext(astext(snaptogrid('POINT(0.956079571507871
> 0.659502930939198)'::geometry, 0.001)), -1);
>
>   ?column?
> ----------
>   t
> (1 row)
>
>
> Cheers,
> Kevin
>
> Paragon Corporation wrote:
>  
>> Slight clarification about what I am trying to solve.
>>
>> After edits I am coming back with lines that used to be intersecting
>> no longer intersecting and that still have the same AsText representation.
>>
>> My hope is to reduce the precision of my geometry in the database so
>> the edits don't break the topology of my lines by doing something like
>> this
>>
>>
>> Update sometable
>> SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>
>>
>> But I fear that if AsText is doing a rounding rather than a
>> truncation, that I run the risk of breaking things that used to
>> intersect.  I am more concerned about under intersecting than over
>> intersecting.  Although I probably haven't thought this out enough so
>>    
> maybe it's a non-issue.
>  
>> Thanks,
>> Regina
>>
>>  
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Paragon Corporation
>> Sent: Friday, May 16, 2008 12:01 AM
>> To: 'PostGIS Users Discussion'
>> Subject: [postgis-users] Does ST_AsText truncate or round
>>
>> Hopefully this is a simple question.  I know that ST_AsText returns a
>> geometry that is not necessarily as prescise as what is actually
>> stored in the geometry field.  I have an editor that relies on WKT
>>    
> representation.
>  
>> Anyrate just wanted to know if the ST_AsText does a rounding of the
>> points or it does a truncation of the points.  Also would be nice to
>> know if I could control the precision of this since I will need to
>> truncate my actual geometry accordingly so that both are in agreement.
>>
>> Thanks,
>> Regina
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>    
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>  
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

RE: Does ST_AsText truncate or round

Regina Obe-2
Kevin,

Thanks.  This and Paul's comments helps to weight the pros and cons.  

Well unfortunately I don't control the client application - but it will be
the same client application that is always used and since a lot of the
editing is done via javascript (custom open layers and GeoServer mix I think
- I'll have to find out more of the details of that to better weigh the
ramifications). I'm not quite sure how easy it will be to swing a WKB editor
in there or if that would be overkill.  It is not high precision stuff and
for the most part I think all the transformations have already been done
that will be.

Thanks,
Regina

 

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Kevin
Neufeld
Sent: Monday, May 19, 2008 10:57 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Does ST_AsText truncate or round

Hi Regina,
Sorry I didn't respond sooner ... I was out camping for the weekend.
Fun, fun :)

Right, this is what I was thinking with my previous post recommending
snaptogrid - force your geometries through WKT :
geomfromtext(astext(the_geom)).  Essentially, this would make all your
geometries only as precise as their WKT representation.  In a way, this
enforces a very fine precision model on all your geometries.  This should
elicit the data consistency you were after ... assuming of course that all
your table edits are performed using geomfromtext().  Bear in mind, though,
that if you have a client program that modifies the table using WKB, you may
be left with data in an inconsistent state.  If this is the case, put a
simple trigger on your tables forcing all UPDATES and INSERTS through WKT.

I agree with Paul R, however, that a client application should not be
transiting data using WKT, but rather WKB.  It may take some work, but I
would recommend that you upgrade your apps to perform all data edits using
WKB.

He was right when he mentioned that I fought with this for a while.  I had a
large database that utilized the full precision of PostGIS. I did some data
editing using a simple WKT editor and suddenly found that geometries that
used to touch no longer touch or they intersect incorrectly.

I guess it boils down to:
* A database that does not enforce any precision model, by default uses full
precision - thus, all data edits should be done using full precision.
* A database that enforces a precision model (including the one you
suggested where X = GeomFromText(AsText(X)) must be true), could be edited
using a editor with an equivalent precision model.  In your case, a WKT
enforced database could be edited using a WKT editor.  However, if you can't
guarantee that all editing is performed using WKT (including updating a
geometry using transform() ), then triggers should probably be constructed
enforcing the model on your spatial tables.


Cheers,
Kevin



Paragon Corporation wrote:
> Kevin,
>
> Actually this would help me with the second phase, but for the first
> phase I just need consistency which I was hoping AsText would do for
> me.  It doesn't even need to be that good since I'm sure the other
> side is using AsText in some fashion.  So I just need consistency more
than correctness.

>
> Where I start off with
>
> Orginal geometry X
>
> I think I need to guarantee that
>
> X =  GeomFromText(AsText(X))
>
> Seemed like the easiest way to assure that was to just force all my Xs to
X
> = ST_GeomFromText(AsText(X), somesrid)    which I presume should be the
same
> as
>
> ST_SetSRID(AsText(X), somesrid)  
>
> The back end editor I'm assuming is just taking the AsText(geometry)
> representation and just returning that back when no edits on a
> particular point,  and so its being poisoned by its own database
> query.  I'm not working on that part so that's just my general
observation.

>
> Thanks,
> Regina
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Kevin Neufeld
> Sent: Friday, May 16, 2008 11:15 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Does ST_AsText truncate or round
>
> Have you considered using ST_SnapToGrid() and make all geometries in
> you database respect a specified tolerance?
>
> Warning, snaptogrid may not behave as you might expect - this is not a
> simple precision_reducer method (which I think would be valuable).
>
> Consider:
> select
>    'POINT(0.877 0.778)'::geometry ~=
>    snaptogrid('POINT(0.87689017271623 0.777984935324639)'::geometry,
> 0.001);
>
>   ?column?
> ----------
>   t
> (1 row)
>
> No problem there, but then there's this:
> select
>    'POINT(0.956 0.66)'::geometry ~=
>    snaptogrid('POINT(0.956079571507871 0.659502930939198)'::geometry,
> 0.001);
>
>   ?column?
> ----------
>   f
> (1 row)
>
>
> To deal with this (I know it looks like a hack, but it works), I
> convert to text and then back to a geometry.  Wrapping this in a
> trigger on your geometry tables will guarantee any geometry edits are
> automatically reduced to a certain precision.
>
> select
>     'POINT(0.956 0.66)'::geometry ~=
>     geomfromtext(astext(snaptogrid('POINT(0.956079571507871
> 0.659502930939198)'::geometry, 0.001)), -1);
>
>   ?column?
> ----------
>   t
> (1 row)
>
>
> Cheers,
> Kevin
>
> Paragon Corporation wrote:
>  
>> Slight clarification about what I am trying to solve.
>>
>> After edits I am coming back with lines that used to be intersecting
>> no longer intersecting and that still have the same AsText
representation.

>>
>> My hope is to reduce the precision of my geometry in the database so
>> the edits don't break the topology of my lines by doing something
>> like this
>>
>>
>> Update sometable
>> SET the_geom = ST_SetSRID(ST_AsText(the_geom), mysrid)
>>
>>
>> But I fear that if AsText is doing a rounding rather than a
>> truncation, that I run the risk of breaking things that used to
>> intersect.  I am more concerned about under intersecting than over
>> intersecting.  Although I probably haven't thought this out enough so
>>    
> maybe it's a non-issue.
>  
>> Thanks,
>> Regina
>>
>>  
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Paragon Corporation
>> Sent: Friday, May 16, 2008 12:01 AM
>> To: 'PostGIS Users Discussion'
>> Subject: [postgis-users] Does ST_AsText truncate or round
>>
>> Hopefully this is a simple question.  I know that ST_AsText returns a
>> geometry that is not necessarily as prescise as what is actually
>> stored in the geometry field.  I have an editor that relies on WKT
>>    
> representation.
>  
>> Anyrate just wanted to know if the ST_AsText does a rounding of the
>> points or it does a truncation of the points.  Also would be nice to
>> know if I could control the precision of this since I will need to
>> truncate my actual geometry accordingly so that both are in agreement.
>>
>> Thanks,
>> Regina
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> [hidden email]
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>    
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>  
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
12