Agorakit : Développeurs.euses et utilisateurs.trices
Agorakit : Développeurs.euses et utilisateurs.trices
Location considerations
Agorakit enables collaborative groups. Given this focus, location considerations are inescapable. Some groups will be geographically based. Others may not be. How should location be modelled in Agorakit?
Currently, we have:
- User locations, which are mapped.
- Event locations, which are text.
Part of the question comes down to: what, if any, should be the geographic model of a particular Agorakit instance? Clearly, one way to address locality is to assume one instance per locality. So, for example, a given city has an instance, and all groups on that instance are de facto associated with that locality.
But this model quickly raises challenges. Even a city may have different neighbourhoods or boroughs.
So, maybe, we introduce an (optional) location for a group. But ideally we'd make that location (region?) an entity in its own right. One of my primary interests as a site user might be: what groups exist in my area? For that, we need the ability to filter by location. But what is a location? What scale does it exist on? Is it something that's derived from some geographic data set? Are regions nested?
Should event locations (venues) be a distinct entity, also mappable, and able to be linked to multiple events, even events of multiple groups?
Groups already have a location. Have you seen the recently updated global map : https://app.agorakit.org/map ?
The small houses represent groups.
We could make proximity search based on a user location and suggest nearby groups, people, and events.
I'd like to keep the DB schema simple as it is now with a latitude and longitude field added to users, groups & events, but am open to any enhancements.
To be honest the mapping feature has not been used that much. It's still a very nice dashboard of activity of an instance. Here are two others :
https://transition.agorakit.org/map
https://participer.toutautrechose.be/map
Search for nearby groups is part of what I was thinking. But also, assigning a group to a named place, such as a city. Then I can bring up a list of groups in my city/place.
Meetup.com is an example. They have a max of three levels to location: country; for certain countries, administrative division like state/province; and city.
Openki uses a "region". AFAIK, these are not nested in a hierarchy.
How regions are created, and by whom, becomes a question.
Some possible approaches, not all of which would be needed:
Proximity is helpful in many cases. But it's not the same as a named place.
For example, if I'm browsing a site anonymously, I might want to know what groups are in my town or place . Since I'm not yet registered, I don't have a location. Yes, we could add IP-based geolocation, but as an anonymous user I might not choose to share that.
Beyond that, for all kinds of physical and legal reasons, proximity doesn't always map closely to an accessible and relevant place. For example, I live on an island. If it's on my island, I can get to it without too much effort. If it's not, no matter how close, I probably can't.
So both named places and geographic proximity are useful.
In this case I'd be tempted to first implement proximity searching and see where this leads us. Since it's arather big task, I keep it on hold until the rest is rock solid, maybe post v1.0
@philippe
Sounds good!
issue here : https://github.com/philippejadin/agorakit/issues/195