Subscribe to this thread
Home - General / All posts - Location precision revisited
tjhb
10,094 post(s)
#20-Jul-17 02:17

Background

The Manifold 8 manual note is not quite correct when it states

All spatial computations are done using the location precision parameter taken from the drawing of the first argument if it is an object ID, or the maximum possible precision if it is a geometric object.

The underlined words should read "or the default precision of 0.000001 if it is a geometric object".

If a drawing has default precision of 0.000001 (1e-6), then operations using an object ID for the first argument apply the same precision as operations using Geom (I): there is no difference. Otherwise the difference depends on the (non-default) location precision of the source drawing.

On the other hand, operations where the first argument is a synthetic or derived metric, such as the result of ConvexHull([Geom (I)]) or, equally, the result of ConvexHull([ID]), always use default location precision 1e-6. There is no choice of precision in those cases, unless the arguments can be rearranged so that an object ID appears first.

If we want finer precision than the default then we must use object IDs, and they must be taken from a drawing having location precision finer than 1e-6.

The maximum possible precision for the underlying double-precision data type is roughly 17 decimal digits; the maximum possible location precision depends on how many digits are used for the whole part of each coordinate. For example, using projected coordinates with false eastings and northings that use 7 digits, we have roughly 10 decimal digits left for location precision. In that case, the maximum location precision is 1e-10, and specifying a precision finer than 1e-10 makes no difference. (In practice, working at maximum decimal precision can cause problems with some geometric operations and unusual geometry. A magnet for corner cases.)

By comparison, Radian currently allows specifying tolerance for all geometric operations individually, whether synthetic, derived, or taken directly from an existing table. It does work at the maximum possible floating-point precision by default, or if a tolerance of 0 is specified; I don't know of any geometry problems working at that scale in Radian. So, an advance on Manifold 8 in at least 3 ways. (Adam has said that the UI for tolerance is currently undergoing some changes, so we will see what comes next.)

So much for the background.

Question

What happens in Manifold 8 if we perform an operation like

UnionAll([ID])

if the objects represented by IDs are taken from two or more drawings, which have different location precision properties? That question has never occurred to me before. I am testing this but haven't found out a full answer yet.

tjhb
10,094 post(s)
#20-Jul-17 03:41

A partial answer.

Test data: drawing A has location precision 0.1, drawings B to F have default precision 0.000001.

Query (simplfied):

SELECT

    CoordCount(UnionAll([ID])) -- queries 1, 2

--  CoordCount(UnionAll([Geom (I)])) -- queries 3, 4

        AS [CoordCount]

FROM 

    A UNION B UNION C UNION D UNION E UNION F -- queries 1, 3

--  B UNION C UNION D UNION E UNION F UNION A -- queries 2, 4

;

Results:

Query 1: UnionAll([ID]), drawing A listed first -> CoordCount 2123306

Query 2: UnionAll([ID]), drawing A listed last -> CoordCount 2123949

Query 3: UnionAll([Geom (I)]), drawing A listed first -> CoordCount 2123948

Query 4: UnionAll([Geom (I)]), drawing A listed last -> CoordCount 2123948

The difference of 1 coord between Q2 and Q3/Q4 is possibly interesting, but putting that to one side...

Tentative conclusion: if an aggregate operator is applied to a group of object IDs from separate drawings having different location precisions, the location precision of the first listed object(s) governs the operation.

We should not rely on this, since in theory the order of objects passed to a function is arbitrary. (In practice it can be controlled in Manifold SQL, but that is not guaranteed.)

For a controlled result we should usually ensure that all source drawings share the same location precision, if their IDs are to be treated as one set in a geometry operation.

adamw


10,447 post(s)
#20-Jul-17 07:23

In Manifold 8, UnionAll(...) takes the precision from the *last* encountered geom, not first. Since the order of geoms is never guaranteed to be preserved (UnionAll and other aggregates are free to reorder them as they wish), this does not matter much.

tjhb
10,094 post(s)
#20-Jul-17 09:06

"Last encountered" and "first listed" could be reconciled by a stack. Thanks for checking but please don't waste any more of your time! The important thing is that "aggregates are free to reorder" records--which means we should simply not mix ID sets backed by different precisions in one column.

adamw


10,447 post(s)
#20-Jul-17 07:26

The underlined words should read "or the default precision of 0.000001 if it is a geometric object".

I don't think this is true.

I checked and the documentation appears correct.

With a drawing named [Drawing] with the location precision set to 0.001 - just to differ from the default 0.000001, in this query:

--SQL

SELECT ConvexHull(ID) FROM [Drawing]

...ConvexHull uses the precision of 0.001 - from the drawing.

With an intermediate call that dissociates the geom from the drawing:

--SQL

SELECT ConvexHull(BoundingBox(ID)) FROM [Drawing]

...ConvexHull uses the precision that depends on the object (on an object I created, which used coordinates in the range of 0 - 1000, the precision was much smaller than 0.001).

Now, it does not make much difference for ConvexHull, because it is going to return the same result for a wide range of the precision values. Maybe that's why it looked that the "maximum possible precision" bit in the documentation wasn't having an effect.

tjhb
10,094 post(s)
#20-Jul-17 09:07

I will do more homework tomorrow. If I find anything interesting perhaps better by email.

tjhb
10,094 post(s)
#21-Jul-17 01:27

Adam, on reading your post, I think you misunderstood me, my fault. (And I still think the documentation is incorrect, in the one respect I mentioned.)

I will be back soon and try to put it more clearly with examples.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.