Area coordinates should be nullable and null should be default

[musoke]

Steps to Reproduce

1. Create a new area
2. Check the coordinates

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

[vnugent]

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:

1. Introduce [lat,lng] field in create area form (pre-fill with the parent's values)
2. Make it easier to enter lat,lng eg introducing a coordinates picker, users can place a drop pin on the map.

[musoke]

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.

[vnugent]

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:

1. Introduce lat/long field in the create area form
2. Update the map component: if the area is a crag/boulder then show the lat/long as a drop pin. If it's a container area then show either its bbox or polygon, highlighting its child crags if available.

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)

[vnugent]

depends on OpenBeta/openbeta-graphql#378

[vnugent]

Backend PR OpenBeta/openbeta-graphql#387 partially addresses this issue.

• Area lnglat field is nullable
• Only use coordinates of leaf nodes (crags and boulders) when calculating bbox's and boundary polygons