width and height parameters for WMS

[robertovallone]

In WMS specs the parameters "width" and "height" are mandatory. The final user should be able to choose the output size of the image (a png, a jpeg or anything else) using them. Should we leave to him the possibility to freely fill those parameters or rather prescribe several - reasonable - choices? And in that second case we should force the system to set the height automatically when the height is chosen to prevent "strange" and unintelligible image size:

[...]
<http:paramName>width</http:paramName>
<http:paramValue>800</http:paramValue>
[...]

AND

[...]
<http:paramName>height</http:paramName>
<http:paramValue>600</http:paramValue>
[...]

OR

[...]
<http:paramName>width</http:paramName>
<http:paramValue>1280</http:paramValue>
[...]

AND

[...]
<http:paramName>height</http:paramName>
<http:paramValue>1024</http:paramValue>
[...]

[sgrellet]

I guess the ´human user ´ won ´t choose anything explicitely. The GUI (machine2machine user) will. For WP15 I have not provided this in the mapping file

Le 19 juil. 2017 à 16:52, "Roberto Vallone" notifications@github.com<mailto:notifications@github.com> a écrit :

In WMS specs the parameters "width" and "height" are mandatory. The final user should be able to choose the output size of the image (a png, a jpeg or anything else) using them. Should we leave to him the possibility to freely fill those parameters or rather prescribe several - reasonable - choices? And in that second case we should force the system to set the height automatically when the height is chosen to prevent "strange" and unintelligible image size:

[...]

width 800 [...] AND [...] height 600 [...] OR [...] width 1280 [...] AND [...] height 1024 [...] — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. P Pensez à l'environnement avant d'imprimer ce message Think Environment before printing Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné(s) comme tel(s). En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de contamination à sa réception. The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. This email was scanned for viruses, vandals and malicious content.

[nmtoken]

In WMS specs the parameters "width" and "height" are mandatory,

Only for some operations (GetMap and GetFeatureInfo)

The GetCapabilities of the service can state the maximum size of the image to be requested.

And in that second case we should force the system to set the height automatically when the height is chosen to prevent "strange" and unintelligible image size:

Not explicitly, for example if users want a long thin ribbon then we should allow it. We shouldn't be too presumptive of what a user might want to do with the output of a WMS service. As service providers we should only be concerned with whether the service can cope with the requests, and whether data should be displayed at all at certain scales (to which it is not suitable to be displayed, for example).

[robertovallone]

Sorry, I've forgotten to explicitly cite WMS GetMap request. My mistake. We can even leave the user free to choose his preferred widht & height but it could be useful - at least for non skilled users - to put something like a tooltip, a comment or a pre-compiled field (or all of them).

[sgrellet]

in WP15 - WMS (BoreholeDataIndex_WMS-DCAT-AP.xml) I explicitely stated that the mapping is just done for GetMap GetMap</eposap:operation> for the reasons explained here #32

[nmtoken]

It is rare though I think for a user to explicitly specify width and height for a GetMap request (and any follow up GetFeatureInfo request), even as an expert user this is something that I rarely do. Normally, the request is made through a client, and the client specifies the values of the parameters. As a user I might specify the layer to be displayed, perhaps the format, perhaps the coordinate reference system, and the bounding box by drawing out some area of interest.

[robertovallone]

You're right. Usually a user has to do something with GetCapabilities url only. Anything else is made through the GUI of the client. But the implementation of the full capabilities of OGC services is something really difficult to implement from the scratch (I think), bearing in mind that the validation process of september is approaching. Taking this into account I wrote my xml's (in WP8, "EDSF*") considering only GetMap for WMS and GetFeature for WFS and related parameters (in a slightly different way from @sgrellet for WP15). I'm just trying to find a "reasonable" way to implement those parameters in the GUI in order to give to the final user as much control as possible on the output. Better ideas are more than welcome.

[nmtoken]

The user should be able to use the work flow to build widgets/recipes to query any service, and chain those widgets together to process or do exciting stuff... like create their own SLD to style a WMS map, or even make a GetMap request...

The GUI/API could have a store of preconfigured widgets that users can use/edit to query services, rather than trying to do everything through a single interface. I honestly thought that that was what we were trying to build at the beginning.

This would give users as much control as they would like.

bearing in mind that the validation process of september is approaching

My understanding of the validation process, is to validate whether we have taken the right approach, the fact that we are all looking to do some sort of workaround to map our services, might suggest that that we haven't.

But the implementation of the full capabilities of OGC services is something really difficult to implement from the scratch (I think)

I'm not sure why we have/had to do this from scratch, we could use the existing OGC structure or the structure encoded in the ISO 19139 for (web) services, and datasets (and data series) metadata. In any case this shouldn't be a new realisation, I've been pointing out for some time now that the EPOS (XML/JSON-LD) metadata structure is too flat to map all the operations of an OGC web service, but if anything the structure seems to be getting flatter! Again, the proof of whether the structure is usable will come out in the validation process.

[sgrellet]

'But the implementation of the full capabilities of OGC services is something really difficult to implement from the scratch (I think), bearing in mind that the validation process of september is approaching.'

Why 'from scratch' ? There are plenty of opensource librairies/projects working perfectly well with OGC services. We use them on a daily basis in our projects.