| 1 | = How can I get the browse images (jpeg, png, gif, etc) for observations? = |
| 2 | |
| 3 | == WARNING: Prototype == |
| 4 | |
| 5 | The current implementation is much more obfuscated than it should be, as it is a prototype, and is not consistently implemented |
| 6 | between data providers. |
| 7 | |
| 8 | The 'browse products' are served as metadata attached to VSO records -- the VSO message format allows User Interfaces |
| 9 | to add extra elements to the request, which the VSO will pass on to the Data Provider that seem to be able to handle the |
| 10 | request based on the elements that the VSO knows about. The Data Providers can then vary their behaviour based on the |
| 11 | new parameters. |
| 12 | |
| 13 | We ask those Data Providers who wish to do this to either prefix the element with their provider id, or to ContactUs, so that |
| 14 | we can make sure two different Data Providers don't use the same name for different features. |
| 15 | |
| 16 | The only element currently in use is 'field', which is passed an array of strings, requesting extra fields to return with the |
| 17 | metadata. If the array contains an item named 'thumbnail', it will return one of the following with the rest of the returned record. |
| 18 | |
| 19 | 1. Absolutely nothing. Not all data providers have browse images to return, and even if they do, they may not have complete coverage. |
| 20 | 1. A complex type 'extra', with an element 'thumbnail'. Please note that this is ''not'' part of the formal VSO API, and it might change as this is a prototype. |
| 21 | |
| 22 | The return structure looks like one of the three following, when deserialized using Perl's SOAP::Lite: |
| 23 | |
| 24 | {{{ |
| 25 | extra => { |
| 26 | thumbnail => 'url_string' |
| 27 | } |
| 28 | extra => { |
| 29 | thumbnail => { |
| 30 | lowres => 'url_string', |
| 31 | hires => 'url_string', |
| 32 | } |
| 33 | } |
| 34 | |
| 35 | extra => { |
| 36 | thumbnail => { |
| 37 | lowres => { |
| 38 | loc => 'url_string', |
| 39 | w => 'width_in_pixels', |
| 40 | h => 'height_in_pixels', |
| 41 | }, |
| 42 | hires => { |
| 43 | loc => 'url_string', |
| 44 | w => 'width_in_pixels', |
| 45 | h => 'height_in_pixels', |
| 46 | }, |
| 47 | } |
| 48 | } |
| 49 | }}} |
| 50 | |
| 51 | The first format is deprecated, and to the best of my knowledge, is no longer in use. |
| 52 | |
| 53 | Both 'lowres' and 'hires' are optional -- It is |
| 54 | possible that they data provider may only have one size of images. If they're both not there, |
| 55 | the data provider hopefully won't send the structure, but it is a possibility. |
| 56 | |
| 57 | The 'lowres' should be somewhere near 128x128, and the 'hires' ones are |
| 58 | something larger, but it's up to the individual data providers. If they use the last format, |
| 59 | they will specify the size of the browse images in pixels. |