Re: [Tagging] Access by permit

[Kevin Kenny]

On Sun, Sep 24, 2017 at 7:11 PM, Kevin Kenny 
wrote:
>
> I'm not sure that http://www.dec.ny.gov/outdoor/2574.html doesn't ever
> overlay atop another permit scheme, although it wouldn't surprise me.
>

And for what it's worth, that would be motor_vehicle:no
atv:conditional=permit @ disabled (or whatever is posted - not all the
routes have exactly the same restrictions.)

That is, motor vehicle access by disabled permit holders only - and the
permit is special to the routes, it isn't an ordinary handicapped tag.

I think. I've not tagged any MAPPWD routes yet, so I'd have to review the
actual requirements. (I have mapped a couple of the tracks, but not applied
the tagging for MAPPWD.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access by permit

[Kevin Kenny]

On Sun, Sep 24, 2017 at 6:02 PM, Mark Wagner  wrote:

> On Sun, 24 Sep 2017 14:20:57 -0400
> Kevin Kenny  wrote:
>
> > On Sat, Sep 23, 2017 at 9:35 PM, Warin <61sundow...@gmail.com> wrote:
> >
> > By the same token it's possible to imagine separate
> > foot:permit:website=*, snowmobile:permit:website=* - separated by
> > transportation mode.
>
> The Inland Empire Paper forests around Mount Spokane:
>
> permit:website=https://www.quality-service-inc.com/
> inland-empire-paper-company/
> ski:permit:website=http://parks.state.wa.us/147/Sno-Park-Permit-Vendors
>
> (Incidentially, "access:snowmobile=no".)
>

I'm not astonished. As I said, there used to be examples around here.
I'm not sure that http://www.dec.ny.gov/outdoor/2574.html doesn't ever
overlay atop another permit scheme, although it wouldn't surprise me.
Except that 'snowmobile' is usually a top-level transportation mode, so
just 'snowmobile=no' in your case.


> Seems to me that "permit:ski:website" makes more sense, though.
>
> Putting it in the 'permit' namespace rather than the 'ski' namespace.
Yeah, I guess given the subtags, that makes sense. Not something I
feel strongly about, so let's make it so.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access by permit

[Warin]

On 25-Sep-17 04:20 AM, Kevin Kenny wrote:
On Sat, Sep 23, 2017 at 9:35 PM, Warin <61sundow...@gmail.com 
> wrote:


access=permit Yes
operator=* ... no - the permit organisation may not be 'operator'.
I much prefer the permit:*=* system as that does signify that it
is strictly related to the permit.
If a fee is required then permit:fee=* might be suitable ...
similar to the contact details permit:phone/website/email=* ?


I'm absolutely fine with permit:operator if needed. In a great many 
cases, the permit contact is the same as the general contact for the 
site, and in that case, I don't see the need for double tagging. Can 
we agree that the permit contact uses permit:operator=*, 
permit:addr:*=*, permit:phone=*, etc? and falls back on the 
corresponding tags without 'permit:' if the more specific tagging is 
not present?


By the same token it's possible to imagine separate 
foot:permit:website=*, snowmobile:permit:website=* - separated by 
transportation mode. I don't think I have a current example, because 
New York went to a scheme where snowmobile registration fees give 
permission to use most of the trails, but there used to be examples 
where the snowmobile access permits were contracted to a different 
servicer than the summer permits.


That makes sense to me.

I too have no example where the transport nature determines the method 
of obtaining a permit. But a provision for it does no harm?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access by permit

[Kevin Kenny]

On Sat, Sep 23, 2017 at 9:35 PM, Warin <61sundow...@gmail.com> wrote:

> access=permit  Yes
> operator=* ... no - the permit organisation may not be 'operator'. I much
> prefer the permit:*=* system as that does signify that it is strictly
> related to the permit.
> If a fee is required then permit:fee=* might be suitable ... similar to
> the contact details permit:phone/website/email=* ?
>

I'm absolutely fine with permit:operator if needed. In a great many cases,
the permit contact is the same as the general contact for the site, and in
that case, I don't see the need for double tagging. Can we agree that the
permit contact uses permit:operator=*, permit:addr:*=*,  permit:phone=*,
etc? and falls back on the corresponding tags without 'permit:' if the more
specific tagging is not present?

By the same token it's possible to imagine separate foot:permit:website=*,
snowmobile:permit:website=* - separated by transportation mode. I don't
think I have a current example, because New York went to a scheme where
snowmobile registration fees give permission to use most of the trails, but
there used to be examples where the snowmobile access permits were
contracted to a different servicer than the summer permits.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Setting a preferred routing

[Greg Troxel]

Dave Swarthout  writes:

> I came across an interesting routing problem the other day. A section of
> the Richardson Highway in Alaska was relocated in 2015 by the Alaska DOT in
> anticipation of erosion or flooding by the nearby Delta River. However, the
> old highway is still present, is still paved, and is shorter than the new
> highway that replaced it. OSM mapper Will Lenz classified the old highway
> as a track to "persuade" his GPS's routing algorithm into using the new
> section. See the following changeset and the conversation I had with Will
> here: http://www.openstreetmap.org/changeset/47049836.

Changing tags to make a router do something, when the tags are not
accurate is "tagging for the router" and not ok, in the same sense that
"tagging for the renderer" is not ok.

Certainly as sections become unpaved, bridges no longer work, those
features should be reflected in the map, and that will pretty quickly
(instantly in the case of bridges) cause routing to flip to the new way.
So perhaps this is already no longer an issue.

> Clearly, the old highway is not a track using the Wiki's definition. I
> might be tempted to tag it as highway=unclassified, or perhaps service, but
> none of these solutions is ideal. Will's idea works but is not, strictly
> speaking, proper.

unclassified, or maybe even tertiary (assuming AK 4 is secondary, being a
state highway) seems ok.  The real point is lanes, surface, maxspeed and
maxspeed:practical, in terms of how routers behave.

A big question is how the authorities view use of the road.  If it's
perfectly ok to use it, then it seems that it's just a matter of
preference for someone to want to use the new section instead.   If it's
posted not to use it, then access tags are in order.

A router ought to be constructing an estimate of how long it takes for a
given path, and the distance.  Then allocating penalties for things that
are not about time/distance, like bumps endured, and then choosing a
path with some minimum of a compound metric.  Generally highway
classification will have little to do with this, but surface, lanes,
speeds, traffic lights, etc. will of course matter.

The obvious experiement is to drive both ways and record the experience,
and then figure out how the map data transforms into time/distance
estimates, and see where those estimates are incorrect, and if there are
serious instances of that, fix the map.

But if the old road is faster and shorter, a router saying to take it
is not wrong.

Someone who prefers a route that is longer is not wrong to have that
preference.  But they need to be able to communicate that preference to
the router, rather than expecting their preference to be encoded in a
subtle, hard-to-follow manner in the map.  An obvious method is to
select an intermediate waypoint along the new road.  I do this when I
want to force a particular route (because I know about
traffic/construction, or just because I find a less crowded road more
pleasant, even if it does take longer).
.




signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping of Subway Stations

[Michael Reichert]

Hi Ilya,

Am 2017-09-24 um 10:49 schrieb Ilya Zverev:
> I had a task of extracting subway infrastructure from OpenStreetMap, and
> I found out that some things cannot be mapped at all (e.g.
> interchanges), and some are unclear or mapped differently in different
> countries.
> 
> Please consider this proposal that clarifies tagging and mapping of
> subway stations:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping

I don't understand what's the aim of your "proposal". There are almost
no new tags. Is it intended as a write-up of what could and should be
mapped and tagged and how that should happen?

It is a good write-up, it gives a good overview but does not answer the
questions of the differences between railway=subway, railway=train,
railway=light_rail and railway=tram.

I am not against a long and structured write-up for mapping public
transport but I would prefer if people would invest the time into
cleaning up existing pages on the wiki. There is already an overview
page: https://wiki.openstreetmap.org/wiki/Public_transport
I started cleaning it up (based on the German version which was cleaned
up and reviewed more than a year ago).

> I have already started improving the mapping of several metro systems in
> different cities. Mostly that involves adding stop_area and
> stop_area_group relations.

I thought that stop_area_group is a dead branch of the "Oxomoa" public
transport tagging scheme which influenced the current tagging scheme (I
prefer the term PTv2 – Public Transport version 2 – for it), isn't it?

> Adhering to this document would greatly simplify using subway data from
> OpenStreetMap in applications — both for multi-modal routing and for
> formatting pretty schemes.

That's a goal everyone had who wrote a tagging guide or proposal for
public transport. The key problem is a lack of guidance by tools using
the data. While other topics have lots of map styles/routing engines and
quality assurance tools, public transport has only very few tools which
are up to date and still maintained. (I currently work on public
transport validator)

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> If you know the location and length of a platform for a subway station, map 
> it as a way Way. Using a node is pretty meaningless, and drawing a platform 
> as an area is an overkill, though possible. You can see an example of such 
> thoroughly drawn platforms here. 

A way is better than nothing but if a mapper is able to draw an area
because the station is pretty simple or he used a laser distance meter
[1], this should not hinder him to draw an area.

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> The modern public transport tagging schema introduces stop positions: points 
> on rails where trains actually stop. These should be placed in the middle of 
> a hypothetical train, that is, near the center of the platform.

Adding them always near the centre of the platform is wrong and useless.
A machine could that do, too. From my point of view they should be added
where the centre of the train is. If a platform is three MU long but
trains are only three MU long during peak hours and short trains stop
near one end of the platform, the stop position node should be located
where the centre of the shortest train will be. Many train, tram, subway
and light rail systems have signs in the track or along the track which
tell the driver where to stop depending on the length of his train. This
signs can also be used by mappers and passengers who know how to
interpret them.

https://wiki.osm.org/wiki/Proposed_features/Metro_Mapping writes:
> When it is possible to go from a station to another station without leaving 
> the metro system, that is, without passing a railway=subway_entrance node, 
> these stations are considered to be in an interchange. To mark it, create a 
> public_transport=stop_area_group relation, and add stop_area relations (not 
> station nodes!) of all stations that are part of the interchange. 

I am not a fan of stop_area_group relations. They tend to be collective
relations (like stop area relations). The practical use of
stop_area_group relations is limited.

Classic public transport routing engines need a manually produced set of
"virtual" connections between two stations which are within a walkable
distance, e.g. from Weinheim(Bergstraße) to Weinheim Hbf [2] because
they only calculate routes based on the timetable. Nowadays multi-modal
public transport routing engines are available, even as open source
software. That's why I think that any suggestions for interchanges
should not be mapped. It is a problem which solveable by a computer
programme. Suggestions are non-factual information which do not fit into
the goals of OpenStreetMap which is based on facts.

Best regards

Michael


[1] https://youtu.be/5T5zH-zanXI?t=10m48s
[2] https://www.openstreetmap.org/#map=17/49.55290/8.66625

-- 
Per E-Mail kommuniziere ich bevorzugt 

Re: [Tagging] Mapping of Subway Stations

[José G Moya Y .]

Hi!
After the 2004 Atocha station bomb it is illegal in Spain taking photos of
metro/railway stations to avoid helping terrorist find weak points/escape
routes (despite of this, metro/railway photo contests take place); I think
that, for the same reason, it is illegal, or at least problematic, to map
inside Spanish metro stations.

(This said, a mapping of metro stations would be of citizen interest, cause
it would show problems due to oversizing, out-of-station exchange routes
that are faster than inside-station exchange routes, accesibility issues,
and so on).

El 24/9/2017 10:52, "Ilya Zverev"  escribió:

> Hi,
>
> I had a task of extracting subway infrastructure from OpenStreetMap, and I
> found out that some things cannot be mapped at all (e.g. interchanges), and
> some are unclear or mapped differently in different countries.
>
> Please consider this proposal that clarifies tagging and mapping of subway
> stations:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping
>
> I have already started improving the mapping of several metro systems in
> different cities. Mostly that involves adding stop_area and stop_area_group
> relations.
>
> Adhering to this document would greatly simplify using subway data from
> OpenStreetMap in applications — both for multi-modal routing and for
> formatting pretty schemes.
>
> Thanks,
> Ilya
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Mapping of Subway Stations

[Ilya Zverev]

Hi,

I had a task of extracting subway infrastructure from OpenStreetMap, and 
I found out that some things cannot be mapped at all (e.g. 
interchanges), and some are unclear or mapped differently in different 
countries.


Please consider this proposal that clarifies tagging and mapping of 
subway stations:


https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping

I have already started improving the mapping of several metro systems in 
different cities. Mostly that involves adding stop_area and 
stop_area_group relations.


Adhering to this document would greatly simplify using subway data from 
OpenStreetMap in applications — both for multi-modal routing and for 
formatting pretty schemes.


Thanks,
Ilya

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Access by permit

[José G Moya Y .]

Ok, Warin
My suggestion was only a last resorce if "access=permit" loses the vote
process again. I understand a permit is not a fee, is "some kind of
paperwork done in advance"

- José Moya

El 24/9/2017 3:37, "Warin" <61sundow...@gmail.com> escribió:

On 21-Sep-17 04:01 PM, José G Moya Y. wrote:

Hi
I agree with the permit system as it is discused here. I found it useful
for National Parks, specially for World Heritage Biosphere Reservations,
 where a small amount of people has to book in advance.
If it keeps getting a strong opposition, you could consider mapping as
access=fee and adding a "book" tag somewhere in the fee system, such as
fee=book, to make users know the access needs booking in advance.
But I prefer access=permit.


'fee' is an already established key. Don't change its use. fee=book makes
no sense considering the present use of 'fee'.
access is not used to signify fee. Don't change that.

access=permit  Yes
operator=* ... no - the permit organisation may not be 'operator'. I much
prefer the permit:*=* system as that does signify that it is strictly
related to the permit.
If a fee is required then permit:fee=* might be suitable ... similar to the
contact details permit:phone/website/email=* ?


Definitions??? Something like?
A permit is a formal process required to gain access, typically resulting
in a issue of a paper form.
It is not the membership of an organisation (e.g. sporting culb).


El 21/9/2017 4:48, "Warin" <61sundow...@gmail.com> escribió:

> On 21-Sep-17 11:24 AM, Dave Swarthout wrote:
>
> I am in total agreement with the proposal as it's been developed in this
> thread.
>
> I too am unfamiliar with structuring the voting process but it may be
> enough to simply add a new section "Voting" at the end of the page, copying
> some boiler-plate from some other proposal, and advertising on this list.
> The voting, just like any discussion we engage in on these mailing lists,
> is open to debate and the result is AFAIK non-binding. People can do as
> they wish afterward.
>
> NO. The formal process is to;
> 1) create a proposal page -
> 2) then call for comments as a new subject here on this list.
> 3) After at least 2 weeks consider any comments made, modify the proposal
> and if that looks good
> 4) then call for votes as a new subject here on this list.
> 5) after another 2 weeks and some number of votes consider if it passes
>
> OR
> You can simply use the tag. There are some 235 uses from taginfo now, so
> it has been used.
> As there are few of these tags around then it should be documented  -
> create a new wiki page.
> 235 is not large but it does establish a use.
>
> Taginfo also has use of 'permit' .. no explanation of what these are for
> and the numbers are small.
>
> Comment - there are a few that use it for car parks in the US. But no
> information on where to obtain a permit.
> I do think that the permit contact details need to be available, and this
> should be suggested a a 'recommendation'? on the wiki page.
>
>
> Many thanks to Kevin for the work you've done on this tag.
>
> On Thu, Sep 21, 2017 at 5:39 AM, Warin <61sundow...@gmail.com> wrote:
>
>> On 21-Sep-17 06:01 AM, marc marc wrote:
>>
>>> Le 20. 09. 17 à 20:39, Kevin Kenny a écrit :
>>>
 Is this a minimal proposal that we can all tolerate?

>>> I do not see any difference between access=permit and (not tag for)
>>> access to a sports club : you can go there if you meet certain
>>> conditions and generally any sports club allows you to "buy a permit
>>> according to their formality"
>>> I see no difference with private property either. if you "follow"
>>> my formalities, you will have the right to come at home.
>>> I think that it would be preferable to improve access=private
>>> by adding a tag to describe any means of "overriding" this restriction
>>> rather than inventing a new type of access that is between sports clubs
>>> are public for the moment), access=private and paying infrastructure
>>> like tool roads.
>>>
>>
>> The primary difference between access=private and access=permit
>> is that a formal permit system exists that anyone can easily use.
>> Some permits are easy and free,
>> some you and I cannot get (unless you are the right tribe or have strong
>> cultural connections).
>>
>> Examples;
>> The Kokoda Trail is not 'owned' by the permit authority.
>> Here the Trail goes through many villages and is administered by a
>> government appointed body.
>> The practice here is to get a permit from the authority and not bother
>> with the property owners.
>> Typically normal people will use a guided 'tour' and that organisation
>> will be registered with the authority and get the individual permits.
>>
>> The Woomera Prohibited Areas (e.g. way 436098551) again are not 'owned'
>> by the authority.
>> These areas have both the rocket range and property owners.
>> The range operators have provided the property owners with shelters -
>>  most of the property owners use the shelters as cool places