Klaus

As in https://github.com/OpenBeta/openbeta-graphql/pull/252 I suggest - adding new field "bolts" with String array that contains no of bolts per pitch - changing "grade" to String array to include difficulty per...

I guess in that case one multi-pitch route could have several sub-routes, with individual difficulty, bolts, description. Sounds neat. Yet, I have to admit, viewed from my central European climbing...

Maybe a misunderstanding (I am aware of `Climb.grades`). Anyway, I have been thinking about this and have come to a different conclusion altogether - I am trying to recap the...

I would say parentClimb could be misunderstood as top-level parent, I’d rather call it prequelClimb or similar. But I see some downsides with that solution: mixing Climb and Pitch would...

Sure. To recap, a `Climb` would be extended with `pitches` of Type `Pitch`: ``` type Climb { id: ID! uuid: ID! name: String! ... pitches: [Pitch]! # add this line...

> Will the climbs still have a description, or is that moved to the pitches? > […](#) Mostly data for multi pitch routes will lack a per-pitch description, so I...

Climb.grade could take the max difficulty of its pitches’ grades. Guidebooks on alpine routes often speak of “obligatory difficulty” one needs to pass. Most often, that's the max grade. In...

> > Climb.grade could take the max difficulty of its pitches’ grades. Guidebooks on alpine routes often speak of “obligatory difficulty” one needs to pass. Most often, that's the max...

update: working on finalising the frontend. what's there already: * json schema validation * dynamic gql query creation (using mutation `bulkImportAreas`) * user guide