hd parameter not working for APOD

[dinizthiagobr]

The 'hd' parameter on APOD's API is not being accepted, it returns:

{
  "msg": "Bad Request incorrect field passed. Allowed request fields for apod method are 'concept_tags', 'date'",
  "service_version": "v1"
}

But on your website it is still listed as a valid parameter.

[brianthomas]

I don't thing "HD" is an allowed parameter. My reading of the source shows that neither the code nor the docs (README) show that parameter as allowed.

[jovrtn]

The 'hd' parameter was working in the previous version of the API, and is still listed on the APOD documentation: https://api.nasa.gov/api.html#apod

[brianthomas]

Interesting. I just grepped the repo for the code and couldn't find it. Perhaps there is some kind of service interceptor at work here or perhaps it passes that parameter through to the underlying service somehow? I can't find anywhere in the codebase where it actually grabs from a different base url. @danhammer will have to answer this one.

[jovrtn]

The return parameter was hdurl if that helps, but it was definitely work just yesterday before the "service_version": "v1" update.

The return values from yesterday's picture for reference:

{
  "url": "http://apod.nasa.gov/apod/image/1601/CatalinaBorrellyArcturus2016-01-01_Hemmerich600w.jpg",
  "media_type": "image",
  "explanation": "This timely, telescopic, two panel mosaic spans about 10 full moons across planet Earth's predawn skies. Recorded as the year began from Tenerife, Canary Islands, near the top of the frame are the faint coma and tail of Comet Borrelly (P/19). A comet with a seven year orbital period, Borrelly's nucleus was visited by the ion propelled spacecraft Deep Space 1 near the beginning of the 21st century. Anchoring the scene at the bottom is brilliant star Arcturus (Alpha Bootes) and Comet Catalina (C/2013 US10) a first time visitor from the Oort Cloud. Catalina's yellowish dust tail extends below and right. Buffeted by winds and storms from the Sun, the comet's complex ion tail sweeps up and toward the right, across most of the field of view. Remarkably, one of the composition's 30 second exposure subframes also caught the trail of a bright meteor, slashing toward the left between comets and bright star.",
  "title": "Comets and Bright Star",
  "hdurl": "http://apod.nasa.gov/apod/image/1601/CatalinaBorrellyArcturus2016-01-01_Hemmerich.jpg",
  "concepts": [
    "Comet",
    "Asteroid",
    "Sun",
    "Jupiter",
    "Planet",
    "Solar System",
    "Moon",
    "Earth"
  ]
}

[Also note that media_type seems to be gone from the new version, too.]

[brianthomas]

I have a partial answer now. Looking at the apod code, its passing the high resolution image along by default. Make a call to the service for today, and you will see that the returned image url is the high resolution one.

[brianthomas]

When I transferred the code over, I put in parameter validation. I believe (and Dan can correct me) that the prior service didnt validate the input query parameters, and 'hd' was simply passed through. It doesn't appear to have any effect (in the old code); you always got the high resolution image.

[jovrtn]

@brianthomas Thanks for looking into it, however just checking against the APOD webpage, today's returned image is definitely the low res one:

API-returned image:
http://apod.nasa.gov/apod/image/1601/PIA20061NuSTARAndromeda600h.jpg

High res image from clicking on the picture on the webpage: http://apod.nasa.gov/apod/image/1601/PIA20061NuSTARAndromeda.jpg

[dinizthiagobr]

Can't agree with you, @brianthomas , there was a difference. And by calling the service today you get the low resolution image.

[jovrtn]

@brianthomas I haven't observed that to be the case using the API up until now—there was usually a difference between the url and hdurl return values.

[dinizthiagobr]

And as @jovrtn said, you used to get the high resolution image in 'hdurl' return parameter if using 'hd=True' during the call.

[brianthomas]

Well, perhaps Dan was deploying from a different repo; I can only go with the code I see. Media_type is not present, neither is hdurl (I'd show you all the 'evidence' but the repo is private, unfortunately)

[dinizthiagobr]

So that must be it. Media_type and hdurl was present for sure.

[dinizthiagobr]

#36

Check this issue opened a while ago, might be helpful for you guys to figure it out.

[brianthomas]

Well, unless I can nail down the exact code which was deployed, the best I can do is to try to restore the functionality in the current service. Does media_type ever return any other value than "image"? The HD parameter should be straightforward to implement, but I wonder if is simply would be better to always supply the 'url' and 'hdurl' values instead (its not exactly a lot of extra bytes).

I am unaware of other issues (yet)

[dinizthiagobr]

Suplying both 'url' and 'hdurl' seems good.
'Media_type' returns "image" or "video" in my limited experience with the API.