You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently some resources support the usage of a geo filter such as OGDWienJSON and KMLGhent, however it would be nice to have this on a higher level (just like the OSpec filter).
This can be done by adding another Filter, which inherits from AFilter (found in model/filters). The filter() function must be implemented, for examples look at the RESTFilter or the SearchFilter.
The usage of the filter comes in the RController ( GET-function ). Starting from line 109 the filters are 1 by 1 called upon, I suggest the geo filter be placed after the opensearch filter, this will already narrow down the amount of entries in the returned object, because the geo-filter will require some triangulation math (which is imho more intensive than the average OSpec filter) so the less entries, the less work the geo filter will require.
The text was updated successfully, but these errors were encountered:
Currently some resources support the usage of a geo filter such as OGDWienJSON and KMLGhent, however it would be nice to have this on a higher level (just like the OSpec filter).
This can be done by adding another Filter, which inherits from AFilter (found in model/filters). The filter() function must be implemented, for examples look at the RESTFilter or the SearchFilter.
The usage of the filter comes in the RController ( GET-function ). Starting from line 109 the filters are 1 by 1 called upon, I suggest the geo filter be placed after the opensearch filter, this will already narrow down the amount of entries in the returned object, because the geo-filter will require some triangulation math (which is imho more intensive than the average OSpec filter) so the less entries, the less work the geo filter will require.
The text was updated successfully, but these errors were encountered: