Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we get rid of metadata JSON? #5

Open
gampleman opened this issue Oct 30, 2018 · 3 comments
Open

Can we get rid of metadata JSON? #5

gampleman opened this issue Oct 30, 2018 · 3 comments
Labels
enhancement New feature or request

Comments

@gampleman
Copy link
Contributor

Currently, this needs a little json file that looks like this:

{
  "source": "http://nomads.ncep.noaa.gov",
  "date": "2016-11-20T00:00Z",
  "width": 360,
  "height": 181,
  "uMin": -21.32,
  "uMax": 26.8,
  "vMin": -21.57,
  "vMax": 21.42,
  "tiles": ["wind/{z}.png"]
}

I wonder if we use not just the r and g channels in the image, but use some of the other channels if we can get the velocity encoded into the image without these values, in which case we could dispense with the need for this file.

@cleanasmud any ideas?

@gampleman gampleman added the enhancement New feature or request label Oct 30, 2018
@cleanasmud
Copy link
Contributor

Fundamentally the information is already in the image, as the r and g values represent the u and v values just scaled to uint8, which actually raises interesting question from my point of view of how the vector direction is dealt with?

@gampleman
Copy link
Contributor Author

gampleman commented Oct 31, 2018

Well that's why we need the metadata file with the range, because that way we can recover the absolute value (see https://github.com/astrosat/windgl/blob/master/data/prepare.js#L23-L24). However, I wonder if we can just use an absolute range and potentially use two uint8 to increase the resolution. For example wikipedia says that the highest recorded wind speed was 408km/h. So if our absolute range went from -500 to 500, it should be pretty safe. 16 bits should give us 0.015km/h increments which seems precise enough for me. Of course we can adjust these values or even do something crazy like use a nonlinear scale.

That's assuming the units are in km/h, which they probably are not...

@cleanasmud
Copy link
Contributor

cleanasmud commented Nov 5, 2018

Comment from Slack by myself:

yeah, I think that it requires some research to do an alternative to the json file, whereas it will be trivial to implement the json file option. If it is not too much an inconvenience from a front end point of view and time is critical then we should probably just go with the JSON file approach

Briefly discussed with @marksmall this morning, due to the limitation in time and the unknowns in how to do an alternative, we will stick with the JSON approach for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants