[postgis-devel] Issue 89 in postgis: transform() grid-shift 2nd chance logic defective

[codesite-noreply at google.com]

Comment #6 on issue 89 by william.... at acm.org: transform() grid-shift 2nd  
chance logic defective
http://code.google.com/p/postgis/issues/detail?id=89

Mark, my previous comment omitted (a) the real root cause of this problem  
and (b)
two possible fixes that might leave us both reasonably satisfied.

Real root cause, highlighted by your last remark:  proj.4's error return  
code
currently makes no distinction between (1) unavailable grid shift files and  
(2)
points that fall outside the boundaries of an available grid shift file.

Best possible fix: PostGIS would throw an error in case 1 and throw a  
warning in
case 2 -- but there's presently no way for PostGIS to distinguish between  
the two
cases.  Any chance you could get the proj.4 team to add a distinct error  
code and
message for case 2?

Second-choice fix: return NULL when proj.4 reports a grid-shift error (in  
either
error case above).  The user who wishes to obtain a non-grid-shifted  
transform as a
fallback could then do so with coalesce().  On the other hand, a user who
unexpectedly has rows with geometries that fall outside the area for which  
the grid
shift is defined could easily identify all such rows in a single SELECT,  
which is
impossible if you throw an error on the first offense.  Finally, users who  
are
missing a necessary grid-shift file at least won't get SLIGHTLY different  
answers
from systems that have the necessary files; this should make it easier for  
them to
find their real problem.

Throwing a generic error like PostGIS now does makes it very difficult for  
a user
whose table contains a subset of rows with geometries outside a grid-shift  
region to
identify those offending rows.  The user must discover the boundaries of  
the grid
shift file (how?), then craft a query to find geometries that fall outside  
tha area.

One last thought about improving the warning in my preferred fix:  my  
current patch
throws a warning for every offending POINT; this increases error-handling  
load by
several orders of magnitude for complex geometries.  Better would be to  
throw one
warning for every GEOMETRY with an offending point, identifying the  
offendor by the
first line of the geometry's summary() plus the coordinates of the first  
point in
the geometry and the first offending point (if different).  I haven't dug  
into the
PostGIS transform code enough to see how difficult this might be.

Sorry to belabor this, but the current generic error behavior really cost  
me a lot
of time, and I'd like to save others the inconvenience.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings