This final task is even more of a reach. So far we have provided the user with the ability to make a WFS request with a specific date, or a date range. What other information is available to us in geoserver?
Outside of report_date
there are the following properties:
id
country
state
cases
geometry
id
and geometry
are not very valuable as search parameters, however, cases
, state
, and country
are viable search parameters.
For this task you will need to work with the cases
property and allow the user to dictate if they want to see cases that are GreaterThan, LessThan or EqualTo a number of cases entered by the user.
This is going to take some work on our part. We will have to provide the user with the ability to make a LessThan, GreaterThan, or EqualThan based on some input (like a select box) AND we will have to provide the user with the ability to provide us with a number of cases that will be used in the filter.
In essence it will be similar to what we did when implementing the date range picker, but now we will be working with cases
instead of report_dates
, and we will have to provide them two means of input for the comparison operator, and cases number.
You will need some information about your geoserver container in order to make the WFS().writeFeature request object, and to make the network request.
'https://zika.devops.launchcode.org'
'zika'
['locations_with_cases_by_date']
'application/json'
'http://localhost:8080/geoserver/zika/wfs'
This information will be necessary for you to make the WFS write feature request and the network request that are necessary to receive a feature collection represented by geojson which can be loaded into the source of a layer.
This task will be difficult, but in essence the steps are very similar to the previous tasks we have completed.