Lot pooling + coordinate query

[kiliankoe]

As discussed in Slack (and elsewhere), it appears to be a good idea moving the lot data away from their city of origin to a pool-based approach.

Lots would require a geographical coordinate and will be returned given a query based on a coordinate and radius. Additionally the may be grouped into pools based on the previous cities.

This should make the implementation of #109 much easier. The addition of new cities should also be somewhat simplified.

[sibbl]

Some notes about this very good idea!

1. do we want to query by coordinate + radius or rather by a bounding box? The latter would make it harder for server owners to track users. For my Windows app, it also has a map view and I'd rather like to make a request for the whole area which is visible in the map view instead of calculating the outer circle of my screen each time - which would also mean that I might get parking lots which are outside the map viewport if you know what I mean. Of course, we could also implement a REST endpoint supporting both query types.
2. how shall we implement it technically? I love the current approach with the JSON description files for data providers. If we want to keep this, should each request go through all JSON files again or should we cache it some where (or do we already do it?). I don't know how it affects the response times if we go through all parking lots and their coordinates for each request.
3. maybe an idea for the future: perhaps we could also use this to decouple the data a bit more. Imagine you have a QR code on a website, you scan it and a new endpoint is added to your app's server list. Each endpoint could provide one more multiple "lot pools" and each time you refresh in the app, it submits a request to all servers and merges the responses. Duplicates could be merged by IDs so that only the most recent data is visible. This would make it easier for cities to only host a server exposing their own parking lot data, especially for citites. (Where should I open this issue as it's rather a client side thing?)

[kiliankoe]

1. Didn't even think about the possibility, I'm all for it! I think I'd prefer being able to support both types of queries for simplicity though.
2. Had this in the back of my head, definitely unsure about that. The sane approach would be dropping the default JSON based model, but it's actually kinda nice...
3. 👍