[postgis-users] Does ST_AsText truncate or round
Paragon Corporation
lr at pcorp.us
Sat May 17 18:45:54 PDT 2008
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: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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:* postgis-users-bounces at postgis.refractions.net 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
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> 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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
More information about the postgis-users
mailing list