Welcome to the BEAM Forum!

We encourage you to sign in our forum and participate in the BEAM community. The forum is maintained by the BEAM project team who will most likely answer your questions within 24 hours (except during common holidays) - if not done by other community members. Collaborate, share your knowledge and learn from other users!

If you don't find what you are looking for, please also consider the following external forums:

Combination View Flat View Tree View
Threads [ Previous | Next ]
AbstractNetcdfReaderPlugin and final methods
Hi devs,
I'm investigating on the capability to support NCML on BEAM.
Does any work has already be made on such a context?
Checking a bit the code I see there are some reader plugins which deal with an Helper class to open Netcdf files (in order to simplify the process which open the files). That NetcdfFileOpener only deals with a subset of specific format.

I could both update that helper class OR develop my NCMLNetcdfReaderPlugin by extending the AbstractNetCdfReaderPlugIn.
In case of the second approach (which I could prefer to make it self contained) is there any reason why some methods of that abstract class are final?
Do you think it would be possible to relax that constraint by removing the final specifier on getDecodeQualification so that I can override it in my subclass?

If affirmative, I can open a ticket and provide a pull request.
Please, let me know what do you think about that.

Flag Flag
RE: AbstractNetcdfReaderPlugin and final methods
4/14/16 9:00 AM as a reply to Daniele Romagnoli.
Hi Daniele,

first of all thank you for interest in developing for BEAM. But as you might have already seen on the home page, BEAM has entered its maintenance phase and will not be further developed.
The development is now going on in SNAP. Things haven't changed too much. Packages have been renamed, some old classes were removed, etc.

Regarding you question (still valid for SNAP):
The NCML format is not yet supported nor any work has been done in this direction.
The NetcdfFileOpener has been introduced, because the default detection, if a file can be opened, took way too much time. That's why we restricted it to just the necessary formats.

Yes, there is a reason why getDecodeQualification(Object input) is final, because there is a getDecodeQualification(NetcdfFile netcdfFile) which should be used instead.

Making the NetcdfFileOpener known of the NCML format might be a way to support this format.

Flag Flag
RE: AbstractNetcdfReaderPlugin and final methods
4/14/16 10:05 AM as a reply to Marco Peters.
Hi Marco,
thanks for the reply.
I'm going to move to SNAP then emoticon

Flag Flag
RE: AbstractNetcdfReaderPlugin and final methods
4/14/16 3:07 PM as a reply to Daniele Romagnoli.
Hi Daniele,

We would be happy if you would move to SNAP and contribute a new data reader for it!

However, I would not suggest to create any dependency to the existing netCDF I/O SNAP code (which is basically the same as the BEAM code). Please go on and write your own, independent reader plugin, you can still use some of the existing code as a template.

The reason is, we have some software design issues specifically in the snap-netcdf module and will likely re-code it from scratch once our time and resources allow for this.

Flag Flag