SimpleDALRegExt: maxImageSize

[Ray Plante]

Hi again,

I report on the results of our discussion of maxImageSize (see 
previous message quoted below) in Sao Paulo.  

A fourth suggestion was proposed by the group which is a variation on 
option 2 below in which we represent the limit as a single number.  
While there was broad concensus on this, there was much discussion 
about whether this number should represent the maximum number of 
pixels on a side or the maximum total number of pixels in the image.  
(We note that this value is primarily relevant for implementations 
that will create images on the fly, either as a cut-out or otherwise 
generated to the user's spec from source data).  While there were 
arguments for both sides, it was observed that which is the 
fundemental measure of the limit is implementation specific.  I also 
noted that this metadatum was recommended by the SIA v1 spec; further, 
Doug Tody suggested that it was likely that a new extension will 
likely be developed for SIA v2.  

Without clear consensus, the group endorsed the recommendation that 
the value be represented by a single number and that I be charged with 
choosing the meaning that most closely matches what is defined in the 
SIA v1 spec for consistancy.  

I looked at the SIA spec which says, 

   MaxImageSize: The maximum image size in pixels, e.g., "8192 8192". 

I conclude that the most consistent definition for the value would be 
that it represent the maximum length in pixels of one side of the 
image.  When a service is in fact limited by the total 
number of pixels (and able to produce non-square images), this number 
should be set to the square-root of that total number so that requests 
whose sides are all less than the maxImageSize value will be do-able.  

I will update the document and post it to the twiki, letting the list 
know when it is there.  Very soon after that, it will be submitted for 
TCG review.  Objections should be raised ASAP.

cheers,
Ray


On Wed, 24 Oct 2012, Ray Plante wrote:
> Hi folks,
> 
> I have responded to all of the comments from the SimpleDALRegExt RFC 
> but one; I'm presenting this last issue today in Sao Paulo.  I 
> summarize here as well for you folks at home.  
> 
> The capability metadatum, maxImageSize, provides a way to indicate the 
> maximum image size that the SIA service can return.  The schema 
> currently in use and what was in the RFC version provides markup that 
> allows one to give the size in pixels along longitudinal and 
> latitudinal axes (i.e. with <long>, <lat>), and then has vague 
> weezel words about images that don't line up on conical axes.  
> 
> Several people correctly pointed out that its not really important 
> to know which is "longitudinal" or "latitudinal"--i.e. its 
> orientation; we just need to know the extent and shape in pixels (and 
> maybe shape is not important either).  Randy Thompson, wearing 
> his publisher hat, suggested that this is likely how publishers have 
> filled it in--i.e. not being concerned which number goes where.  I 
> think this is closer to the original intent expressed in the SIA spec.  
> 
> I see three possible ways to do this to bring the maxImageSize 
> definition closer to this intent: 
> 
>   1.  Keep the XML schema definition as it is, but put in the document 
>       words that say that it doesn't matter which number goes in 
>       <long> and which goes in <lat>.  
> 
>   2.  Change the definition of maxImageSize to take an array of pixel 
>       lengths, as in:
> 
>         <maxImageSize>4000 6000</maxImageSize>
> 
>       (or even,
>         <maxImageSize>4000 6000 100</maxImageSize>
>       )
> 
>   3.  Change the definition of maxImageSize to mark up the individual 
>       axis lengths:
> 
>         <maxImageSize>
>            <axisLength>4000</axisLength>
>            <axisLength>6000</axisLength>
>            ...
>         </maxImageSize>
>         
> Here are some considerations:
> 
>   a.  (1) has the advantage of being backward compatible with the 
>       current schema in use.  This, in general, means it has no impact 
>       on existing records.  (2) and (3) would require that existing 
>       records be updated.  
> 
>   b.  Very soon, we will be updating all of these DAL records anyway 
>       to comply with the update VODataService; thus, we might argue 
>       that we shouldn't worry about being backward-compatible with the 
>       capability part.  My only concern is in the period where some 
>       registries have upgrade and others have not.  Will the fact that 
>       we have two versions (with different namespace URIs, of course)
>       of the schemas running around out there be a problem for either 
>       applications or registry providers.  
> 
>   c.  While (2) is more compact (good for consuming applications), its 
>       harder to validate and might be harder for applications like our 
>       publishing interface.  (3) solves this problem.  I doubt that 
>       there are any consuming applications that make use of this 
>       metadata, so the bigger concern might be for consuming registry 
>       apps. 
> 
> For my own opinion, I think I prefer option (3); however, I am 
> concerned about the possible disruptions to registries with such a 
> change.  I discussed this with my VAO colleagues, we gravitated toward 
> (3), but we would like hear from others.
> 
> thanks,
> Ray
> 
> 
> 
>   
>