#33 Wider than 360 degree GNC/JNC CADRG bug

[Anonymous]

Summary: It seems (some?) GNC/JNC datasets are more
than 360
degrees wide, and this is causing some errors in extracting
subareas.

The problem was reported by Ralf Lauker (laukner *at*
aerodata.de).

Ralf writes:

At present, I am testing the RPF function with a
GNC/JNC map and detect that there is scaling error in
longitude:
As an example, I requested the following area:
Lat 52°
Lat 53°
Lon 10°
Lon 11°
(centered in Braunschweig :-) )
The result is correct for latitude but for the
longitude an error of about 2° occured. The error
increases with increasing longitude.
At Lon= -180° the result is okay.
Did you detect any similiar problem ?

...

I don't know how to use ogdi_import but I did not buy
the GNC/JNC charts because I download the charts from
http://geogratis.cgdi.gc.ca/download/cadrg/. A tool
like wget is very useful for download.

I analysed at the last weekend this problem and
detected the main problem.
Every layer has a coverage from -180° to 180° but the
actual range is greater than 360° (the first and the
last tile is overlapping).
The driver however divides the range with the number of
tiles of the layer. This is not correct and generate
the problem of scaling error (you must use the decoded
value from the chart/layer).
The next problem is that you have to manage the
correlation of tiles otherwise use a incorrect tile (I
think tilewidth or something like that).
I have after these changes a small offset in the
longitude -:(

[Frank Warmerdam]

Logged In: YES
user_id=17655

Note, actually submitted by me (warmerda) on Ralf's behalf.
I don't have time to dig into this now, but I didn't want to
lose
track of the details.

[Gregory Rouxel]

Logged In: YES
user_id=1204607

I think i'm having the some problem.
some of my Jnc/gnc file have 180W 189.32E boundary but the
Table of content (a.toc) report a 180W 180E ( may be it 's a
limitation of the a.toc file format ? ).

I found in the file driver/rpf/utils.c line 267, that the
east longitude boundary of a tile is taken from the A.toc
file and the longitude resolution is caculated using the
number of pixel, the resolution and the east/west boundary:
long_res = (east-west) / nbPixel

To fix my problem I change this part of code to use the
longitude resolution of the A.toc file and calculate the
east boundary using the west boundary, the number of
pixel, and the resolution :
east = west + long_res* nbPixel

I work fine for me now.

Now the question is if this is The solution or just a
workaround.