yongrenjie
commented
2 months ago Happy to merge, just some side thoughts
We only really expect these geobuffs to have a the geometry and the id though
- would there also be region names?
- how do we want to store geometries at different levels (in which case there would be more than one set of (index + names)? I recognise this might touch on some of the stuff in my upstream issue so happy to defer to a later discussion
so perhaps we just change this function to extract the id as a known type rather than trying to expose a mapping of properties
Very much in favour of this — 'closed' data structures are good
None of this blocks merging so feel free to do that whenever you're ready (or request a review and I'll do it)
Adds a function that allows us to request geometries from a remote flatgeobuff file with optional filtering within a bounding box.
Have added tests to ensure we get the right results with a mock server and mock data.
One improvement which might be good to consider is that we get the properties back as a HashMap<String,String> and it might be worth mapping those values to Float, String, Bool etc. We only really expect these geobuffs to have a the geometry and the id though so perhaps we just change this function to extract the id as a known type rather than trying to expose a mapping of properties.