Proposal talk:Mtb access

Current Progress

For this one I'm almost sure we could merge allready established hour of opening and temporarily closure which allready exist in other way. See : Key:opening_hours or more probably Key:access ( shit, why is there two tags for the same thing ??) However, and then why not, if there is a sense into saying some trail is closed for mtb only at some hours :

Then I'll agree with something like :

• mtb:date_on=YYYY-MM-DD
• mtb:date_off=YYYY-MM-DD

or if it is a per day basis :

• mtb:hour_on=HH:MM:SS
• mtb:hour_off=HH:MM:SS

Sletuffe 21:37, 20 November 2008 (UTC)

Yeah I think so too. But currently those Acces Restrictions seem to be under major rewrite.

Sorry to insert into you comment, where did you heard that ? who said it ? Sletuffe 23:30, 20 November 2008 (UTC)

This looks to me like a big rehaul: Proposed_features/Access_restrictions

It's completley unclear how things will progress to me. Maybe we should put mtb_acces on hold for the moment concerning the voting aspect. I don't think it's of major importance for the moment anyhow, so for the moment a general guideline should be enough?

I would add

* mtb:off=YYYY-MM-DD for temporary interuptions (maybe propose a better key. mtb:temporary_off would be quite reasanable too to me). (as well for hour but I don't think its needed there--Extremecarver 22:17, 20 November 2008 (UTC)

I don't think this of course the most important, we should focuss for now on mtb_scale, but letting a page here is good for other people to give ideas Sletuffe 23:30, 20 November 2008 (UTC)

Yeah, let's leave it as it is as a draft. Maybe sometimes the other more important proposals have been agreed onto and accepted we can come back here. For the moment this is a bit too complex I think. I would wait what this brings to us.Proposed_features/Access_restrictions Maybe we could try the content of this page over there?--Extremecarver 23:37, 20 November 2008 (UTC)

As the person who wrote most of Proposed_features/Access_restrictions: it's progressing slowly. I'd like to get some good discussions going on to see if it can handle anything (or eventually anything, as it is more about creating a structure that works and can be used to for example define shorthand ways so you don't need to tag everything with complex relations). So, given that it's a structure, it doesn't really matter what tags are in use by then or will be in future, and if you want to propose a mtb vehicle type for access rules, then please do, as it's completely independent from things like vehicle types, or which restrictions there are exactly. But if you are creating tags with time access rules specifically for this tag, then it's better to wait with that. Caveat: the proposal will probably include some tree-like definition of vehicle types (likely country-dependent as well), so "mtb" would be a part of "bicycle", which in turn is a "vehicle". But again, it needs a lot of thinking first :-) --Eimai 14:06, 21 November 2008 (UTC)

I have read all of you proposal, I have thought of doing it for a while, but I felt too weak to be able to deal with that, so man, yeah, your work is awsome ! But still, even if I find it hard, I am going to help. At first, before just "jumping" into legal access restriction which looks an enormous work, I made a first try with smoothness=* that make use of a "member grouping idea" of physical usability of ways. This project is to my mind a 80% victory, but it's far easier when it comes to physical than to legal rights, because with physics, where a car can drive, a tractor can too ! With legal restrictions, this is not always the case. Keep up the good work, grouping by members of same categorie is the only way we can manage things, without having hundreds of tags to say bicyle=yes, mtb=no, car=no, 4wd=yes, bus=permissive, etc....

Stay tunned, I'm comming to solve this problem with you.... at least before year 2018 ;-( Sletuffe 14:27, 21 November 2008 (UTC)