Godiva3 default depth

[frizwi]

Hi, Godiva2 used to display the top vertical layer as default, Godiva3 now shows the bottom layer - is that a configuration in ncWMS/WMS or something else? Similarly the vertical profile is inverted. Thanks

[guygriffiths]

The default behaviour should be to pick the closest vertical layer to the surface - i.e. the top vertical layer for a depth axis, but the bottom vertical layer for a height axis.

It looks like this is currently not working for axes with units of pressure, which are also being incorrectly labelled as "Depth", when pressure is generally used as a substitute for height. I'll fix this bug - can you confirm that that's the issue you're seeing?

If you're getting this problem with a genuine depth axis (e.g. ocean levels) then it will need further investigation.

[frizwi]

Not entirely sure on the conventions but here are the attributes of the vertical coordinate:

zc: Array of 64 bit Reals [k = 0..46] units: m positive: up long_name: Z coordinate axis: Z coordinate_type: Z

i.e. the values are negative for depth in the ocean. Anyway, I guess my point is that the same exact file behaves differently in the Godiva2 vs Godiva3 or maybe more accurately, ncWMS vs ncWMS2.

Let me know if you'd like any more info.

Cheers,

-Farhan

---

From: Guy Griffiths notifications@github.com Sent: Thursday, June 1, 2017 6:35 PM To: Reading-eScience-Centre/edal-java Cc: Rizwi, Farhan (O&A, Hobart); Author Subject: Re: [Reading-eScience-Centre/edal-java] Godiva3 default depth (#89)

The default behaviour should be to pick the closest vertical layer to the surface - i.e. the top vertical layer for a depth axis, but the bottom vertical layer for a height axis.

It looks like this is currently not working for axes with units of pressure, which are also being incorrectly labelled as "Depth", when pressure is generally used as a substitute for height. I'll fix this bug - can you confirm that that's the issue you're seeing?

If you're getting this problem with a genuine depth axis (e.g. ocean levels) then it will need further investigation.

- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Reading-eScience-Centre/edal-java/issues/89#issuecomment-305427820, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYosE4ukPAiMZRu-RrbWUmeJjU9A4H0Jks5r_nfhgaJpZM4NsjB7.

[guygriffiths]

Is it possible for you to make the file available for me to download? If not, I can mock it up, but it's a lot easier with (at least a sample of) the real data.

[frizwi]

Sure, you should have access to this one:

http://data1.tpac.org.au/thredds/catalog/tascem/setas/catalog.html?dataset=tascem/setas/setas_simple_2017-04.nc

---

From: Guy Griffiths notifications@github.com Sent: Thursday, June 1, 2017 8:47 PM To: Reading-eScience-Centre/edal-java Cc: Rizwi, Farhan (O&A, Hobart); Author Subject: Re: [Reading-eScience-Centre/edal-java] Godiva3 default depth (#89)

Is it possible for you to make the file available for me to download? If not, I can mock it up, but it's a lot easier with (at least a sample of) the real data.

- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Reading-eScience-Centre/edal-java/issues/89#issuecomment-305458287, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYosE1wbQAbU-ACou7CzBYEyXteYtWi7ks5r_pbUgaJpZM4NsjB7.

[guygriffiths]

OK, I've made it so that coordinates are sorted in the correct way. I'll probably do a 2.2.8 release in the next couple of days, which will include this change.

Another way to work around this is to provide your z axis values as positive depths (as opposed to negative heights)

[frizwi]

Thanks, I'll wait for the next release.

---

From: Guy Griffiths notifications@github.com Sent: Tuesday, June 6, 2017 1:54 AM To: Reading-eScience-Centre/edal-java Cc: Rizwi, Farhan (O&A, Hobart); Author Subject: Re: [Reading-eScience-Centre/edal-java] Godiva3 default depth (#89)

OK, I've made it so that coordinates are sorted in the correct way. I'll probably do a 2.2.8 release in the next couple of days, which will include this change.

Another way to work around this is to provide your z axis values as positive depths (as opposed to negative heights)

- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Reading-eScience-Centre/edal-java/issues/89#issuecomment-306225662, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYosE6VV3cpJ6FfRVdXd8Pw4OJG8SApwks5sBCSvgaJpZM4NsjB7.

[guygriffiths]

Released