Split access field into car access field and walk access field

[brendanheywood]

These are mutually exclusive, the car access is generally from the nearest towns / city to the parking, and the walk is from there to the various cliffs. Each cliff would share the same car approach but have a different walk approach, it's not overriding but augmenting. I've seen a couple guide books which also show these separately with different icons, ie a car icon and next to it says '2 hour drive from brisbane' and then some text, and then the next section is '20 min walk'. If we have a small crag with a single cliff then these would be side by side on the crag node page, but if there is 5 cliffs with the same parking then we'd only show the walk in field on the cliff node. This would mesh perfectly with the car park poi in #108

[rouletout]

I wonder how useful this is - I rather would just have the closest parking and a button to get directions on google or whatever people prefer. I don’t see the value in managing car access, public transport access, etc. - there are sites that do only that and we should just provide the “end-point”

On 04 Jan 2017, at 17:54, Brendan Heywood notifications@github.com wrote:

These are mutually exclusive, the car access is generally from the nearest towns / city to the parking, and the walk is from there to the various cliffs. Each cliff would share the same car approach but have a different walk approach, it's not overriding but augmenting. I've seen a couple guide books which also show these separately with different icons, ie a car icon and next to it says '2 hour drive from brisbane' and then some text, and then the next section is '20 min walk'. If we have a small crag with a single cliff then these would be side by side on the crag node page, but if there is 5 cliffs with the same parking then we'd only show the walk in field on the cliff node. This would mesh perfectly with the car park poi in #108 https://github.com/theCrag/website/issues/108 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/2507, or mute the thread https://github.com/notifications/unsubscribe-auth/ASRnSOzMxULMW3SgkUeeAClWfUae8N56ks5rPE1ugaJpZM4LbRDA.

—————————————————— Ulf Fuchslueger Head Business Development @ theCrag ulf@thecrag.com mailto:ulf@thecrag.com www.thecrag.com http://www.thecrag.com/

https://www.thecrag.com/climber/rouletout https://www.thecrag.com/climber/rouletout

Follow us on Facebook https://www.facebook.com/thecragcom/?fref=ts Follow us on Linkedin https://www.linkedin.com/company/thecrag?trk=biz-companies-cym ——————————————————

[brendanheywood]

The road access is often not a public road, eg a fire road or whatever. The instructions cover things like gates, and river crossings

If it is a public road then yes just the gps coordinates of the car park is sufficient.

[MelwinQ]

While rouletout is right, that there are websites that can do the routing in the desired mode of transport, I still think a field "approach from closest point of public transport" would be useful: If I don't have a car (or try to avoid using one) I would like to filter my destinations accordingly.

[georg-d]

@MelwinQ: I cannot imagine how you'd like to filter destinations based on a longer text (i.e. free text, not a tag "10min walk in time from nearest public transport stop position"). Could you please provide a short example so I can better imagine? Thank you :)

@brendanheywood:

These are mutually exclusive, the car access is generally from the nearest towns / city to the parking, and the walk is from there to the various cliffs. Each cliff would share the same car approach but have a different walk approach, it's not overriding but augmenting.

At least in the regions I am climbing, these are not that often exclusive respecitively augmenting, but you'd use different parkings or public transport stop position for different cliffs - be it, because 1) parkings / stops are very nearby single cliffs like in Sella (switch to OSM map layer to see cliffs & parkings) or 2) because the the cliffs of an valley / mountain ridge stretch over such a long distance that you'd want to drive to the nearer end like at Valle di Rian Cornei and neighbouring Boragni (switch to terrain map layer to clearer see the valley structure), i.e. either in the south at "Via San Giorgio" XOR the north in Orco. The 1st case is simple to solve, namely showing both access infos side by side, like you described for a small crag. But how would you like to handle the 2nd case? Adding a grouping or re-usage feature for cliffs to support common parking / stop seems high effort for the case. Would we reference "manually" in the free text, e.g. in "Sasso Crazy brothers" telling "see 'Bastionata Boragni Crag' for car/bus access"? Bad luck if someone only has only one of the two in the PDF guide.

[MelwinQ]

Indeed, filtering in free text would be tricky and or require stricter regulations in the vocabulary, essentially making this a tag like the existing "approach time"-tag. Could that be an option?

[georg-d]

@MelwinQ: Option? Sure :) For implementation, we need to become way more specific, so what would be the purpose / time aspect of the filtering. Time in the meaning of frequency of public transport (tricky to tackle via tag because of big variances, think daytime vs morning/evening, weekdays vs weekends vs holidays, summer vs winter,...), driving time to the relevant stop position (tricky because multiple "major start points" are common, think of cities Nürnberg/Forchheim/Bamberg/Bayreuth and target Mittleres Wiesenttal, and thus driving times differ strongly depending on start point), walking time from the stop position to the crag (tricky if different stop positions are relevant depending on where you come from, think of a mountain between 3 valleys and buses driving through the valleys),... Personally, I do not see much use to tag the "best variant" of each single aspect, because such a mix is not helpful for real life; an "extreme" example to illustrate my point: Imagine 2 stop positions of 2 bus lines are useful. The crag has the tags "frequency 10min" (of bus 1) and "walk in time 5min" (from stop of bus 2), but bus 1 has 2 hours walk in time (so you can't really exploit it's high frequency) and bus 2 is a ski bus and thus drives only when much snow is around (so you can't really exploit short walk in time for rock climbing 10 months of the year).

Personally, I am fine with a solution where 1) a textual description of approach by public transport exists in the same field as for approach by car, bike, canoe, foot, ski,... mentioning the relevant bus/train/aerialway numbers/names and 2) stop positions would also be a POI in the sense of https://github.com/theCrag/website/issues/108 - like this, in an area known to me, I can roughly estimate traveling time & frequency from my position, I can easily copy & paste stop position names into routers to get exact timings, I can easily find crags reachyble by "a good" (from my position) bus/train/aerialway by clicking their stop position POIs on the map which would show a pop up of crags using this POI (like clicking a POI in hikr.org shows all reports & photos etc linking to that POI)

[MelwinQ]

Thanks for the detailed analysis. I totally agree that things can be complicated - but this is not different from the "approach time from parking": Is the close-but-tiny parking already full so I have to use the remote option? Do I have a 4WD and can get closer? Should I take the other parking when I am eying the south face? Do I carry a full alpine rack or just a chalkbag uphill? ... So, these time are rough estimates anyway. Also, I agree that they hardly make sense above the level of sectors. Thus, I am still in favour of duplicating the way it works for cars. Anything else - POIs, time schedules, routes, ... - I am fine with getting from other sources.

[georg-d]

@MelwinQ Do I understand you correctly that you'd like only to "dublicate" the "walk in time" tag (e.g. "5-10min"), so it exists once from relevant public transport, once from relevant parking? IMHO that makes sense:

1. Current "walk in time" does not even explain from where the time shall be measured (car parking, bus stop,...), so two dedicated tags make it more clear.

2. I do not see we'll flood the system with many "walk in time" tags because other means of transportation have too often too big variances in how far you can go (e.g. a racing motorbike / bicycle will often park where car parks, while an enduro / e-MTB may go rugged paths directly to the cliff).

[MelwinQ]

Exactly, that hits the point. +1

[rouletout]

In the near future we will update the Add/Edit Area form and we have added 2 walk-in times as an enhancement to the current structure. Thanks for the valuable discussion.

[rouletout]

+1 from support email to have a structured field for GPS of nearest parking for better car navigation to the crag