[postgis-users] Does ST_AsText truncate or round
Chris Hermansen
chris.hermansen at timberline.ca
Tue May 20 11:23:56 PDT 2008
Some random thoughts on Regina's comments;
* one of the problems with something like WKT is that it's easy to
end up with a text representation of an internal floating point
number that isn't exactly equal to that number. for example,
"0.1", "0.2", "0.3", among many others, cannot be exactly
represented in IEEE floating point.
* certain products (Microstation comes to mind, but I believe also
SDE though I could be wrong there) don't use IEEE floating point
for storing coordinates, and so their ability to handle precision
is different than products that do use IEEE floating point
* let's say you have a device that measures your location in UTM to
the nearest metre. that is its precision. let's say further that
this device has a measurement error of ± 10 metres. that is its
accuracy - sort of. furthermore, your measurement of a given
location is just an approximation of the true location. stating,
or thinking, that the true location is (543,754.3 2,546,549.2) is
just like stating, or thinking, that pi is equal to 22/7. it's a
fallacy.
* throwing away precision is a bad idea. besides the inexact nature
of the IEEE (or other) internal number format, there are a number
of ways additional digits to the right of the decimal can arise:
o coordinates measured to the nearest 10cm can be thought of
as living on a grid with 10cm spacing. however coordinates
subsequently interpolated between those points do not live
on that grid, and reducing precision on those (ie fitting
them to the grid) is just throwing good information away
o transformation from e.g. UTM to Albers will introduce more
digits to the right of the decimal point. reducing
precision on those introduces errors. it's like "double
rounding", and the accuracy of the information becomes
compromised.
o storing in geographicals (for projection - on - the - fly)
will introduce lots more digits to the right of the decimal
point. again, reducing precision on those will introduce
errors.
* it is worse to truncate than to round. the error introduced by
always truncating is double that of rounding.
* some arithmetical operations lead to numerical instability. a
good example is subtraction:
o take two numbers approximated to six digits and subtract them:
+ 543195 - 543193 = 2
o now take the same two numbers approximated to 14 digits and
subtract them:
+ 543194.54987161 - 543193.49198324 = 1.05788837
o hmm, about a metre different. could hit the old gas line
with that kind of error.
o also, note that the subtraction operation on two nearly
equal numers of six digits left one digit of precision,
whereas on 14 digits, it left 9 digits of precision.
o the obvious conclusion from the above is that reducing
precision causes errors that accumulate in subsequent steps
and compromise the answers.
* transformations themselves may introduce errors, due to
inaccuracies in the coefficients of the transformation or various
approximation techniques (e.g. iteration). or there may be
accuracy issues in the transformation. these kinds of errors can
accumulate in a problematic fashion; for example, one data set may
go through three transformations to get to WGS84, another through
only two. presumably at that point there is little likelihood
that two different measurements made of the same fire hydrant
location would be coincident in the final dataset
Paragon Corporation wrote:
> 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
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
--
Regards,
Chris Hermansen mailto:chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5
More information about the postgis-users
mailing list