Additional Fields for Areas (Approach, Aspect, Access)

[btmccord]

What would you like to be able to do? Please describe.

In addition to the location/approach field suggested in #1051 as a user and a LCO board member I think two more fields would be very helpful.

Access - This would be useful to communicate if an area has access issues (i.e. seasonal bird closures) or if it is closed to climbing entirely. This could be a state (Open, Sensitive, and Closed) and a description (Optional).

Aspect - As a climber the aspect of a wall is a very important piece of information. We could show this right below the coordinates.

Here is a little mock-up (An appropriate icon for the alert and aspect would be needed)

How important is this to you (Please pick one)

• Important

[vnugent]

How about this schema? I imagine once it's set at the parent level and child areas can inherit the field.

access: {
   description:  text
   status: open | sensitive | closed
   lastUpdated: timestamp
   lastUpdatedBy: userUuid
}

[btmccord]

Looks good.

I am wondering if we should have an expire date too? Use case would be for temporary closures where an end date is know. Once the date has passed the notice will not show on the page.

I have noticed a lot of out of date access info on MP, which causes one to ignore the alerts.

[vnugent]

I think we should break it up into 2 separate sections:

1. General access info: general information about access issues/closures if any. This information is generally static.
2. Alert: time sensitive updates with expiration date.

[btmccord]

Something like this

access: {
   headline: text
   description:  text
   status: open | sensitive | closed
   lastUpdated: timestamp
   lastUpdatedBy: userUuid
   alert: {
      headline: text
      description: text
      expiresOn: timestamp
      lastUpdated: timestamp
      lastUpdatedBy: userUuid
}

[btmccord]

Just thinking that this info (Aspect and Access) should also be implemented at the climb level. Generally inheritance is fine but I can see cases where just one route is closed or has a drastically different aspect from the rest of the area.

[vnugent]

What about keeping the Access and alert data at the area level where it makes sense and adding an optional list of affected climbs? The benefits are twofold: increase awareness and ease of implementation. We have this similar design for Local Climbing Orgs - climbs & areas inherit the LCO defined higher up. The org also has an optional excluded list. In this case we have an optional affected list.