If you look at the GetFindes documentation
http://project-gc.com/doxygen/lua-sandbox/classPGC__LUA__Sandbox.html you will notice that there are build in filter options in the api call
Use them because they will be translated to SQL where statements that is used to fetch the user finds. It is faster/easier to use them then to implement your own in LUA
The code to add the filter options from the config is as simple as below if the options are in the top level of the tag. If you require a filter table in the config it is even easier when conf.filter can be used directly in the API call
I have not testet to send an empty array to the filter so i would not require "county": [ ] If you allow it to be missing the checker will work lite most others checker
Most checker uses the filter options named as in the GetFinds directly in the config tag
One thing consider is to add code that allows known config option it the config and result in an error if other tags is added. That will reduce the risk of a misspelled .
I have an extended GetFinds in this checker template that can be used. It haves more filter options.
http://project-gc.com/Tools/Challenges?edit&scriptId=936
I will extend it with attributes, FP, %FP, %wilson, elevations and perhaps other options. A polygon filter might be used
The core i have often used is the one below. You can if you want set local filter=conf and it will still work but that dont look as nice in my eyes
local filter={}
filter['country'] = conf.country
filter['region'] = conf.region
filter['county'] = conf.county
filter['minVisitDate'] = conf.minVisitDate
filter['maxVisitDate'] = conf.maxVisitDate
filter['minHiddenDate'] = conf.minHiddenDate
filter['maxHiddenDate'] = conf.maxHiddenDate
filter['types'] = conf.types
filter['sizes'] = conf.sizes
filter['difficulties'] = conf.difficulties
filter['terrains'] = conf.terrains