What is the reason for mandatory requestParameters

[Tumetsu]

I need to retrieve all available observation data from any station. I noticed that request parser enforces me to specify the requestParameters list. However, since each station might have different set of observation types, it is troublesome to define all observation types explicitly in the request. The API allows requests without parameters defined (defaulting to retrieve everything). I'd like to know the design reason why requestParameter is always required by the parser? wfsconnection comments just state it as mandatory.

I forked the Metolib and modified request parser to make requestParser optional and according to unit tests and manual testing, it seems to work as expected. The reason I'm asking is that I might have ignored some inobvious reason for requiring the requestParameters and I'm causing problems for myself in the future :)

[tervo]

As far as I recall, the reason has been to encourage users to load only the data they need. The behaviour still conflicts with the WFS API. So, no good reason.

Your modification does not sound to break backward compatibility. We would be very happy if you could push your changes back to master branch!

[Tumetsu]

Sounds good. I'll do pull request if/when I finish the modifications. Looks like SplitterCache relies on the requestParameters more than the parser so I'll look into it to see if I can figure out how to change it to support all parameters retrieval.

[TheKarppinen]

From the production point of view there is no need for mandatory requestParameter when WfsRequestParser is used.

The original purpose of MetOLib was to provide a reference implementation on how to use FMI's WFS services. Also, the implementation has been meant to give useful tips and to guide a developer on things that are good to understand when using the services. Therefore, the implementation contains checks that may not be optimal from the production point of view but may have been good from the tutorial point of view to highlight certain issues. But, of course an additional option to ignore unnecessary checks would be a good thing to have now.

Notice, WfsRequestParser itself may easily be used without requestParameters. But, WfsConnection uses the cache which requires parameter-value before query is made to server. If parameter is not provided when query is made, the data can not be mapped into cache when it is received.

The change proposal mentioned here is useful in WfsRequestParser that can also be used directly instead of WfsConnection. But, we can still make it work via WfsConnection also. This could work similarly to the case when bbox is queried instead of certain place. So, if WfsConnection is wanted to be used, it could just forward query directly to WfsRequestParser. See, wfsconnection.js and in it retrieveSitesData and retrieveSpatialData -functions for example.

It nice to have more developers to contribute here. So, looking forward to your pull request Tumetsu.

[Tumetsu]

I noticed that SplitterCache seems to require the parameters for mapping the data. Your suggestion for WfsConnection seems reasonable as far as I understand the library. Probably will do that.

However, I suppose that it would make splitting the big retrieval tasks impossible when using WfsConnection? For SplitterCache documentation there is mentioned that it is used for

...server middleware for splitting up big retrieval/calculation tasks into smaller tasks...

For my use case I'd like to do a long time span queries of data which require splitting to multiple requests which don't require caching. From preliminary reading of SplitterCache I suppose it would be easier to create a separate "SimpleSplitter" with no cache which is compatible with the modified WfsParser rather than refactoring requestParameters out of the existing SplitterCache. Do you agree?

[TheKarppinen]

I agree that a separate "SimpleSplitter" with no cache is a good way to proceed in this case.