Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1435 closed defect (invalid)

Petascope_NetCDF wrong imported bounding box

Reported by: Bang Pham Huu Owned by:
Priority: major Milestone: 9.3
Component: petascope Version: development
Keywords: Cc: Vlad Merticariu, Dimitar Misev
Complexity: Medium

Description

I imported the file ​http://flanche.net/geodata/nc-201003.nc with this recipe ​http://pastebin.com/C9bhSiB7

then compare in Panoply (left is encoded netCDF output, right is the input file). There are different

​http://rasdaman.org/attachment/ticket/1409/diffrent_netcdfs.png

The bounding box of Lat and Long axes are extended than (-90:90) and (-180:180).


Coverage V2_monthly_cci_uncert_combined_beta_bounds_test is of type ReferenceableGridCoverage with 3 axes:

    Lat (measured in degree ) with domain extent from -123.33333333347065 to 90.00000000003335.

    Long (measured in degree ) with domain extent from -180.00000000033336 to 203.99999999997385.

    ansi (measured in d ) with domain extent from 149444 to 149444.

Change History (9)

comment:1 by Bang Pham Huu, 8 years ago

ncks will not update metadata for a subsetted output coverage, so the recipe if using wcst_import built-in variables (e.g: ${netcdf:metadata:geospatial_lon_min}) to extract metadata will ingest the wrong bounding box (this is not the problem of this ticket, just for information).

ncks -d lat,-30.0,-20.0 -d lon,-30.0,-20.0 example.nc -O cropped_example.nc

check the output file with ncdump

	:geospatial_lat_max = 90.f ;
		:geospatial_lat_min = -90.f ;
		:geospatial_lat_units = "decimal degrees north" ;
		:geospatial_lon_max = 180.f ;
		:geospatial_lon_min = -180.f ;

so fixed the recipe to use the subsetted bounding box (https://www.diffchecker.com/SHMmy4Ap) and import the subsetted coverage, the output will be like: instead of (lat:-30,-20, long-30,-20).

    Lat (measured in degree ) with domain extent from -60.96 to -20.
    Long (measured in degree ) with domain extent from -30 to 10.96.

The problem seems to be due to the tiling option (REGULAR) and it was cached then have affect when inserting new coverage

  "tiling": "REGULAR [0:0, 0:1023, 0:1023]"

the grid bounding box of coverage above is changed to
             <low>0 0 0</low>
            <high>0 1023 1023</high>

If I changed this tiling to

 "tiling": "REGULAR [0:0, 0:10, 0:10]"

it will have nearly correct bounding box (theres is only 240 points for lat and long, so should be 0-239 for interval).

        <lowerCorner>-29.68 -30 149444</lowerCorner>
        <upperCorner>-20 -20.32 149444</upperCorner>

         <low>0 0 0</low>
         <high>0 241 241</high>

If I changed to use ALIGNED ( "tiling": "ALIGNED [0:0, 0:100, 0:100]"), it describe correct bounding box

        <lowerCorner>-29.6 -30 149444</lowerCorner>
        <upperCorner>-20 -20.4 149444</upperCorner>
        <low>0 0 0</low>
        <high>0 239 239</high>

@vlad: any idea why the tiling option here can change significant data (is that must have to define the tiling with REGULAR according to the coverage's bounding box as well ?)

comment:2 by Dimitar Misev, 8 years ago

REGULAR will always result in an array sdom that is a multiple of the tile sdom.
ALIGNED will always have a real array sdom. ALIGNED doesn't work well with 3D and partial 2D updates, so then REGULAR is preferred.

You can learn more here: wiki:Tiling

Version 0, edited 8 years ago by Dimitar Misev (next)

in reply to:  2 comment:3 by Bang Pham Huu, 8 years ago

Replying to dmisev:

REGULAR will always result in an array sdom that is a multiple of the tile sdom.
ALIGNED will always have a proper array sdom. ALIGNED doesn't work well with 3D and partial 2D updates, so then REGULAR is preferred.

You can learn more here: wiki:Tiling

thanks, but the constraint to set correctly tile interval is must have as well? (not random tile intervals for REGULAR ?). I don't know about this requirement.

comment:4 by Dimitar Misev, 8 years ago

What do you mean by random tile intervals, where do you see random? If you use REGULAR tiling you need to be careful and know how it works, it's explained in the wiki page. ALIGNED is default and it works as expected with respect to this.

in reply to:  4 comment:5 by Bang Pham Huu, 8 years ago

Replying to dmisev:

What do you mean by random tile intervals, where do you see random? If you use REGULAR tiling you need to be careful and know how it works, it's explained in the wiki page. ALIGNED is default and it works as expected with respect to this.

I normally don't regard to the tile intervals (I just type random interval here

"tiling": "ALIGNED [0:0, 0:10, 0:20]" or "tiling": "ALIGNED [0:0, 0:130, 0:150]"

Yeah, I see REGULAR has adventage and I should know the grid bounding box before and set it in tiling, is that correct?

comment:6 by Dimitar Misev, 8 years ago

Yes that's correct. Please learn more about tiling (and don't just use random tiling intervals), the tiling is very important to the operation of rasdaman, it's not some irrelevant setting.

in reply to:  6 comment:7 by Bang Pham Huu, 8 years ago

Resolution: invalid
Status: newclosed

So the problem of this ticket is due to from Olly's recipe which used not correct tiling size for REGULAR (the coverage has Lat: 4320 points and Long: 8640 points).

Then the tiling should be divisors of total points respectively (e.g: "tiling": "REGULAR [0:0, 0:431, 0:863]").

comment:8 by Dimitar Misev, 8 years ago

Do we need to notify Olly?

in reply to:  8 comment:9 by Bang Pham Huu, 8 years ago

Replying to dmisev:

Do we need to notify Olly?

It was fixed here http://earthserver.eu/trac2/ticket/165 as I expected.

Note: See TracTickets for help on using tickets.