Dear all,
What is - I think - missing in your new API definition is a resolution parameter for the output. There is only width/height in pixel. But resX/resY is available in the OGC API. Will sinergise add those parameters to the new API later?
Dear all,
What is - I think - missing in your new API definition is a resolution parameter for the output. There is only width/height in pixel. But resX/resY is available in the OGC API. Will sinergise add those parameters to the new API later?
Hi,
yes, we plan to add an option to specify spatial resolution (instead of width and height) of outputs.
Current support for these in our OGC API enables one also to specify resx/resy in units different from units of bbox’s crs (= crs of output image). For example, coordinates of bbox can be given in EPSG:4326 and resx/resy in meters. While this probably simplifies the requesting of the data for the user, it also hides the complexity of this transformation and (as we’ve learned) may lead to wrong expectations/confusion on user’s side (e.g., it is not possible to have an uniform spatial resolution for the whole output). We are thus leaning towards an option that resx/resy parameters in API would always need to be given in units of bbox’s crs; i.e. in degrees when requesting data in EPSG:4326. This is also how OGC standard specifies these two parameters.
Would you be willing to elaborate a bit more on how this would influence your workflows? Would you find resx/resy useful even if you had to specify them in degrees when you request data in EPSG:4326?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.