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

[codesite-noreply at google.com]

Comment #2 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,

Thanks for the prompt reply.  Didn't really expect anyone to look at this  
until 2009.
  Answers to your questions ...

1. Documentation re. new method of handling issue?  First, I noticed that  
proj's
"cs2cs" utility does NOT throw an error (or even a warning) in this  
situation --
rather, it simply performs the transform (which is no transform in this  
case) without
the grid shift.  I then read cs2cs's relevant code and pretty much  
plagiarized it for
my patch.

Three other supporting elements:

(a) lwgeom_transform.c's "2nd chance" remark in function transform_point().

(b) lwgeom_transform.c's function pj_transform_nodatum(), which does not  
function as
claimed its leading comments.

(c) Very helpful remarks for rev. 1.11 in the revision history contained in  
the
leading comments of proj's pj_transform.c.

2. Why not return null when the transformation is invalid?  In at least  
this case,
NAD83 -> NAD27 transformation, the most useful behavior is to return an  
unshifted
transformation.  I have a large table of broadcast radio station locations  
-- most in
CONUS but some in Alaska and Puerto Rico; aborting processing of the whole  
table
because the transformation of one or two rows will be off by a few hundred  
meters is
very inconvenient, especially because the offending geometry is not  
identified in the
error message (and only the first one is found before abort).

My main argument:  if proj.4 thinks it's useful to return a non-shifted  
transform,
PostGIS should faithfully propagate that behavior.  With my patch, the user  
is warned
of any "transient" error (proj's terminology in pj_transform.c remarks).   
In this
particular case, the warning is misleading ("failed to load NAD27-83  
correction file"
when the real problem is out-of-bounds input), but at least they're warned  
once for
each offending geometry while still getting a useful result table.  If you  
know how
to make that warning actually identify the offending point, that would be a  
great
improvement.  Didn't want to press my luck given my very limited C skills.

3. Wrong diff format.  I thought I'd seen instructions for the preferred  
form of
"diff," but it looks like in updating PostGIS support Web pages to point to
code.google.com, those instructions disappeared ... or at least became  
impossible for
me to find.  I'm now attaching a "diff -u".

Thanks again for the quick response.  Merry Christmas!

Attachments:
	lwgeom_transform.c-1.3.3.diff  3.9 KB

--
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