Open musoke opened 6 months ago
We can leave newly created areas' [lat,lng] null therefore, inheriting their immediate ancestor's lat,lng. However, things can get tricky when creating grand child areas. Unless we update the db schema, we can't pass the parent's [lat,lng] down beyond its immediate children.
Perhaps, if you elaborate more on the user journey when creating new areas, we can make changes to the create area form? Some options:
I am thinking about times when I create an area but don't know useful coordinates. In these cases, adding coordinates is actively misleading.
Introducing an optional lat/long field in the create area form would be helpful. Dropping a pin on a map would also be helpful. However, both are separate from my issue here.
Ah I didn't think it through. It makes sense for crags and boulders to have coordinates whereas parent areas are simply logical groupings similar to OSM relations. Some immediate and longer term proposals:
Immediate:
Long term (backend changes required) Introduce a more comprehensive location/GIS object to area (#1051) a. approach trails (can be gpx / reference to OSM trails) b. parkings and trail heads c. overview data (selected crags climbs to be highlighted in the area's overview map)
Backend PR https://github.com/OpenBeta/openbeta-graphql/pull/387 partially addresses this issue.
Steps to Reproduce
Screenshots
Expected Behavior
I expect that the coordinates for new areas are left unset unless there are known-good coordinates. In addition, the coordinates should not default to those of the parent area. It does make sense to display the map corresponding to a parent area when the coordinates are unknown.
Current Behavior
When creating a new area, the app assumes its location is the same as the parent area. This is not very helpful and is particularly frustrating once the assumed coordinates propagate down a few levels.
Browser & version
All
Operating system
All