[Gdal-dev] RE: too precise projection comparison

Ed McNierney ed at topozone.com
Tue Oct 19 23:17:26 EDT 2004


Ben -

Certainty is risky business <g>.  One might very reasonably expect the "correct" value here to be:

PARAMETER["standard_parallel_1",61.66666666666667]

Which is why this sort of business is the minefield that it is, and why, for all their faults, I find EPSG projection codes very reassuring to deal with <g>.

     - Ed

Ed McNierney
TopoZone.com

-----Original Message-----
From: gdal-dev-bounces at xserve.flids.com [mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of Ben Discoe
Sent: Tuesday, October 19, 2004 11:14 PM
To: 'Matt, Kim, Cole & Danni'
Cc: 'gdal-dev'
Subject: [Gdal-dev] RE: too precise projection comparison


Matt,

I debugged into it, and found that GDAL (or OGR in this case) is actually very picky about projection parameters matching exactly.

It's not the text in the "degree" field, and it's not the cell size.  It's
this:
  PARAMETER["standard_parallel_1",61.66666666666672]
  PARAMETER["standard_parallel_1",61.66666666666673]

Yes, that's enough to cause OGRSpatialReference::IsSame to return false.

So, Matt, in lieu of OGR adding some kind of epsilon test, i'd recommend that you track the changes back to find where the projections diverged in your tool chain, and/or simply fix the text in your .prj files.  For example, it's certain that the correct value above is actually:
  PARAMETER["standard_parallel_1",61.66666666666666]

-Ben

> -----Original Message-----
> From: Matt, Kim, Cole & Danni [mailto:patawi at polarcom.com]
> Sent: Sunday, October 17, 2004 2:57 AM
> To: Ben Discoe
> Subject: Re: too precise projection comparison
> 
> >>Bug (sort of): VTBuilder comparing projections is too precise. It 
> >>offers to convert projections when the mismatch is down on the 14th 
> >>decimal place:
> 
> Ahh, I was led astray by the error message. I assumed that because 
> there was a difference in the numbers in the message, that was the 
> entire extent of the difference. After manually comparing the .prj 
> files I found another difference:
> 
> A.prj:
> UNIT["degree"
> 
> B.prj:
> UNIT["degree (supplier to define representation)"
> 
> And of course the cell sizes differ. There must be another one in 
> there too though because when I manually edit the "supplier..." text I 
> didn't get the message. Sample data attached.
> 
> I can't remember how I generated B, it was either vtconvert or 
> gdal_translate back in early May.
> 
> -matt

_______________________________________________
Gdal-dev mailing list
Gdal-dev at xserve.flids.com
http://xserve.flids.com/mailman/listinfo/gdal-dev




More information about the Gdal-dev mailing list