Extend crag node with fields for seasonal closures

[theSCRAG]

Today: You could only add a seasonal closures as a textual description to field "Access Issues"

Improvement: add two date fields ("from" and "til") below field "Access Issues".

Then we have the possibilty to work with these datas in future:

• grey out closed crags or add "forbidden sign"-icon to crag and overviews.
• get list of closed crags over API and so on

Background: In some areas are many seasonal closures. e.g. in Frankenjura ( http://www.ig-klettern.com/natur/sperrungen.php ) the seasonal closures change weekly.

Sample: Access Issues ["bird protection"] From: ["01.02.2014"] til: ["30.07.2014"]

[brendanheywood]

I'm wondering how this data ever be kept up to date? Unless we're the primary source and the people setting the dates are editing it directly there will always be a lag and more probably just stale info unless there are really committed editors.

Also on the data model we're basically making an availability calendar for a crag, so to do it properly you'd want to be able to set recurring dates, or multiple future dates, etc

An alternate idea to kick around: a bit of magic markdown something like:

2013-Mar-20 - 2013-Jul-11 #Closed because of nesting Peregrines
2013-Nov-01 - 2013-Dec-31 Total fire ban #no-fires

It's a bit more flexible as it can handle important info that isn't necessarily about closures, and builds upon the existing tag data. While ever you are inside that date period that chunk of content could get parsed and highlighted in some way. And for people reading the raw text it's still really clear what's going on.

[scd]

I am for the markdown magic. I really like the way git is developing their markdown and think that would be really cool for us to develop climbing standard markdown. There are a number of issues developing this way. Maybe we need one collector issue to make sure there are no overlapping contours.

[theSCRAG]

@brendanheywood Keeping up to date is always a problem. < irony > How should a worldwide route database works?</ irony > Add the new dates at the beginning of the year shouldn't be a problem. I know someone who could do that. :-) Of course, the main problem is to keep up to date during seasonal closures. At the moment we have 5(!) lists of different providers. And some have a big lag. Therefore it should no problem to be better than the worst.

Maybe, if a crag list of seasonal closures are available through a API it could be interessing to use theCrag as central database and service in the future. This is a good promotion for us.

@scd I have no experience in 'magic markdowns' - but then it's working it's also okay for me.

[scd]

Making it available through the api is an interesting idea.

The "Access" field is an important field. Already it propagates down the index so you see access comments made at the crag level are seen at cliff level.

I think also making this field freely available via the API may be a worthwhile. Maybe with a badge, so that any third party site can use it. So the third party site just needs to know the crag id plus a bit of javascript code.

I guess we are also showing our scars a little bit as well. We have been going at this on and off for just under 15 years and it takes a lot of work to convince people to do things differently. It is actually starting to happen now. It is nice that you are dragging us through this issue.

Talking about irony, the four of us developers, don't really have time to keep information up-to-date all around the world so it absolutely relies on us convincing the community to do it.

@theSCRAG it sounds like you are up for it.

[brendanheywood]

Ok so this has been roughly scheduled in the 'uber markdown' iteration in 1st quarter next year.

Example HTML output with microformat:

<div class="vevent" id="hcalendar-event-title">
  <time datetime="2013-11-01" class="dtstart">2013-Nov-01</time>
  –
  <time datetime="2013-11-31" class="dtend">2013-Dec-31</time>
  <span class="summary">
    <a rel="tag" href="/article/Tagging/Closed#Closed" class="tags">#Closed</a> because of nesting Peregrines
  </span>
</div>

Note:

• datetime attr is machine date, text date is whatever was entered as-is (eg could be in any language, try and parse as many formats as possible)

See also: http://microformats.org/wiki/hcalendar http://microformats.org/wiki/rel-tag

[lordyavin]

+1

[brendanheywood]

The new warning system can be used for temporary closures and the warning can then be dismissed when season is over. The next year the same warning could be reopened again with 1 click to save some typing.

Bonus points we can add fields to the warnings to accept an expiry date, which we did discuss but pushed back out of MVP.

[Mdemaillard]

reopened under #3422

New feature to set a date range for (scheduled) crag closures. In Germany we have a lot of scheduled closures due to nature conservation. It would be neat to just enter the official dates once and the closed tag is set and removed automatically.

So if someone wants to log an ascent from the past it has to be outside of the date range of the closure.

Originally posted by @lordyavin in #3421 (comment)

[scd]

Realistically I don't think we will implement predefined dates in time for helping the current series of closures.

There are quite a few components required to put dates in closure field because it is currently implemented with a tag. Potentially it is a complet re-implementation which touches a lot of code and testing and data migration. Alternatively there is a trigger to remove the tag, so existing code will continue to work, but we have to manage a layer for automatically removing tags.

Maybe we should think differently and add an alert date to a warning.

[rouletout]

This is covered by the following functionality and processes:

1) Warning system to display the closures 2) Automated (opr if small manual) updates from advocacy groups that take the responsibility to "own the data an dates"

Closing

[lordyavin]

Don't understand point 2

[rouletout]

It means that Advocacy groups that take the responsibility to maintain the data can do that manually or via API.

[lordyavin]

I see, are there any prepared snippets for common CMS?