What is the reason for mandatory requestParameters about metolib

[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.