We should consider adding a regional search to the API #234
Replies: 6 comments 8 replies
-
|
Thanks for starting this discussion! I'll add some of my thoughts here. It really seems to be a non-trivial problem with no obvious solution especially when trying to think of a global approach. To be honest I'm not too familiar with how districts, cities and regions are organized in different countries. I guess my first (maybe naive?) approach would be relying on geo-coding in some way. To me this seems to be the cleanest and most unambiguous solution. Ideally, every venue would have its coordinates attached to it somehow. Then, searching for events in a specific region, one could enter a city name and define a radius. All events that either match the city name or whose venue is within the specified radius around this city would be returned. This assumes that a city can always be pinned to a specific geo location. Not sure if this is the case and makes sense. Another issue with this approach would be how to assign coordinates to each venue and how exactly this is represented in the database/event-api? Despite some issues and without having having thought this through entirely, to me this seems to be a reasonable approach that kind of bypasses the difficulties related to definition of what exactly an agglomeration or a region is. Linking a related issue just for completeness: jakopako/croncert-web#29 |
Beta Was this translation helpful? Give feedback.
-
|
For instance MongoDB supports geospatial queries which might be what we need in this case, see https://www.mongodb.com/docs/manual/geospatial-queries/ |
Beta Was this translation helpful? Give feedback.
-
|
This looks really promising. It's less accurate than doing it by venue, but still pretty good. |
Beta Was this translation helpful? Give feedback.
-
Maybe it would be possible to default to the geolocation for the city, and then as contributors ad them, for the venue. This increases complexity for mutli-venue sources though. |
Beta Was this translation helpful? Give feedback.
-
|
We could indeed default to the geolocation for the city and do the lookup at insert time. We only do this 'enrichment' if no geolocation is provided by the client, so in a second step goskyr can be updated to support this and finally the croncert-config can (incrementally) be updated. This is one part of the feature. The other part would be to enable search by city + radius. I guess the ux of croncert.ch would also have to change slightly because right now a search is triggered after each typed character. But a radius search would only make sense once the user has typed (probably with autocomplete feature) the entire city name. |
Beta Was this translation helpful? Give feedback.
-
|
Believe it or not I had forgotten that I raised that issue. I realize now that it's more properly an API issue anyway. |
Beta Was this translation helpful? Give feedback.
-
|
yeah I guess you're right and it's mostly an API issue |
Beta Was this translation helpful? Give feedback.
-
|
Just fyi: I am working on a possible solution, see https://github.com/jakopako/event-api/tree/jakopako/issue19 |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! |
Beta Was this translation helpful? Give feedback.
-
|
The radius thing should be working now. Check it out! I still have to do some documenting in the various repos and extend goskyr to be able to define venue specific geolocations. Right now the event-api derives the coordinates from city and if necessary country as a default. |
Beta Was this translation helpful? Give feedback.
-
|
Perfect ! Brilliant ! I'm absolutely thrilled. This is really great.
|
Beta Was this translation helpful? Give feedback.
-
|
Very cool indeed! |
Beta Was this translation helpful? Give feedback.
-
Since this is probably the most central of the code repositories for all croncert-adjacent projects I'm raising it here instead of in an issue against the event-api project.
@jakopako's idea for an event-API is probably the best approach I've seen after several more decades in the space than I care to claim. I love its speed, and I hope it can scale to millions of events.
That said, there's something a little lacking in the search capability when searching by city. Cities are in fact quite different from one another. Some are gigantic metropolises with many districts. In those cases concert goers might care about the district for some kinds of events, and not for others. London comes to mind here, and New York, but to a degree maybe even Berlin.
Other cities are parts of an agglomeration, like the San Francisco - Oakland - Berkley - San Jose agglomeration, or closer to home for me, Lausanne - Morges - Lutry - Cully (plus maybe Vevey and Montreux, and as a stretch goal Nyon).
So in order to increase usability for those of us who live in agglomerations I'd like to propose that we add a feature to the API. The problem is that I don't exactly know what shape that should take. Should it be a new search flag, like agg, or perhaps region? Or should it have some geo-coded quality? I'm not sure which would make more sense on a global scale.
On a side note. "London" as an official designation of the metropolis is pretty recent, and was created by adding an administrative layer and a tiny poltical office with some small amounts of authority over an agglomeration, which consists of a number of cities like London, Westminster, Camden, Dalton, Islington, Hackney, Tower Hamlets, etc. So it's cool that the political world decided to fix our issue for us there, but that took hundreds of years of debate and I wouldn't count on it happening elsewhere.
Beta Was this translation helpful? Give feedback.
All reactions