Re: [Tagging] Best practices regarding implied tags

2020-09-17 Thread Kevin Broderick
+1.

Explicit tagging indicates a level of confidence not generally associated
with implicit tagging. While there's certainly an 'ad nauseum' level of
doing so (e.g. adding surface=paved, motor_vehicle=yes to highway=motorway
in the U.S. would be kinda silly, IMO), there are plenty of cases where a
primary tag generally implies something about the tagged object but doesn't
guarantee it. I'd point to the recent discussion of access= on driveways as
an example; while most driveways allow for certain types of access by
default, it's far from guaranteed—there may be a no-trespassing sign or a
locked gate, and explicitly indicating the lack of such in the access
tagging is helpful. (Adding the implied value without survey or other
definitive knowledge is not, as then you express a higher degree of
confidence than actually exists in the data).

On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson  wrote:

> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Is that completely wrong or mappers could eventually add implied tags if
>> they want to?
>> The proposal currently states they are optional and it won't raise an
>> error if mappers add them beside mandatory tags.
>>
>
> No, it's not wrong to add implied tags explicitly.  It's actually
> encouraged in some cases where the implicit tag is not consumable by
> automated system (such as the "none" default for turn:lanes tends to be
> ambiguous between "you can't turn from this lane" and "you can't use this
> lane" and "there's an implicit but unspecified implication that isn't
> painted on the ground"), or access defaults (such as in the US where
> bicycle=* and foot=* varies a lot on highway=motorway)
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] OHV greater than 50 inches (wide)

2020-09-01 Thread Kevin Broderick
More likely than prohibiting bikes, the USFS could allow
non-street-registered OHVs over 50" on a trail, but keep it closed to
normal street-registered vehicles; in some states, there may also be
implications regarding the requirement to have the vehicle registered as an
OHV, regardless of whether or not it has a street plate.

I'm not sure that we need a separate access tag, though: is there any case
where the USFS (or another land manager) allows only those OHVs over 50"?
In most cases, I think either maxwidth= or atv:maxwidth= would be
appropriate, when the question is a max-width of 50", no?

On Tue, Sep 1, 2020 at 5:03 PM Mike Thompson  wrote:

>
>
> On Tue, Sep 1, 2020 at 2:47 PM John Willis via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> I would say that is a “motor_vehecle”
>>
>> https://wiki.openstreetmap.org/wiki/Key:motor_vehicle
>>
> Sure, it is a motor_vehicle, but it is just a subset of motor vehicles, so
> I don't think that tag would be appropriate.  For example it is possible
> that the FS would say that a given road is open to OHVs >50", but not
> motorcycles, but the tag motor_vehicle=yes implies motorcycle=yes.
>
> Mike
>
>>
>> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Aerialway stations

2020-08-13 Thread Kevin Broderick
On Thu, Aug 13, 2020 at 9:22 AM Colin Smale  wrote:

> Despite the minimal difference the website does indicate that one side is
> the "top station" and the other side is the "bottom station", but that's
> probably not a valid source. Anyway, suppose they were both at exactly the
> same altitude. What's the intrinsic difference between top station and
> bottom station? The location of the drive motors perhaps? That would be an
> objective attribute that we could put into OSM (motor=yes/no?)
>

IMO, I think that tagging drive and return terminals is appropriate, but
the presence or lack of a drive is completely irrelevant to top vs
bottom—some aerialways are top-drive, others are bottom-drive.

If the British English (and thus OSM standard) word used for the facility
at either end is "station", I'd suggest
aerialway:station=drive
aerialway:station=mid
aerialway:station=return
would be appropriate.

-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Aerialway stations

2020-08-12 Thread Kevin Broderick
In the case of Gaislachkoglbahn, it appears to be two separate tramways
(and tagged as such), with adjacent terminals. If the carriers (gondola
cabins, tram cars, chairs, etc) don't continue through the station, I think
it would be a drive or return terminal, not a mid-station; that particular
case would be two terminals (for two different tramways) housed in the same
building.

I'm not aware of any circuit-shaped tramways where the drive/return is
actually the same structure.

On Wed, Aug 12, 2020 at 11:48 AM dktue  wrote:

> Hi,
>
> 1) maybe "station=lower_station" would be clearer
> 2) I couldn't find any real-world example
> 3) Probably this would be the definition of a mid-station.
>
> Interesting example:
> https://www.openstreetmap.org/node/1613091788
>
> Here within the same building we have "Talstation" ("valley station") and
> "Bergstation" ("mountain station") of the aerialway "Gaislachkoglbahn"
> wheres the arealway itself is separated in to sections name
> "Gaislachkoglbahn I" (lower) and "Gaislachkoglbahn II" (upper). I think
> because people have to get out and change the aerialway to proceed furtuher
> to the top it's correct that this is not a mid-station. I would expect from
> a mid-station that I can get off but I might be able to stay and go further.
>
> Cheers
> dktue
>
> Am 12.08.2020 um 17:02 schrieb Mateusz Konieczny via Tagging:
>
> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit tagging?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Aerialway stations

2020-08-12 Thread Kevin Broderick
>From an 'information about aerial tramways" standpoint, I believe that it
would be preferable to label the drive, midstation, and return terminals as
such. While they are often for vertical-oriented transport, aerialways are
sometimes used for horizontal transport, e.g.
https://www.openstreetmap.org/way/46351339#map=18/44.53063/-72.78456=D
terminal=drive
terminal=return
terminal=mid

It is worth noting that ski lifts are often described as "top-drive" or
"bottom-drive" (i.e. the powered bullwheel is at the top in some cases and
at the bottom in others), but it doesn't take a ton of tramway knowledge to
figure out which is which (drive infrastructure is usually pretty obvious).

If the concern is for routing, that's a slightly bigger challenge—some
tramways load only at one end, some load at both (e.g. the gondola linked
above), others load primarily at one end with limited loading at the other
in various special conditions, sometimes event-specific, and often with
different capacities (many, if not most, ski lifts have higher uphill than
downhill capacities). one_way=* seems to be a possible solution, but I
don't know how you'd tag "one_way=yes; except when hosting a wedding at the
top, or for employees to get down at the end of the shift"

On Wed, Aug 12, 2020 at 11:04 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> 1) is bottom station always in valley?
> (This should be fixable)
>
> 2) is there case of 2 and more middle
> stations?
>
> 3) is there case of one station being both
> top and bottom station at once?
>
> Also, it uses single known tag, not
> new discussion purpose ones.
>
> Though, yes processing would be
> much more complicated.
>
> I would consider also tagging elevation
> (ele tag from what I remember).
>
>
> 12 Aug 2020, 16:31 by em...@daniel-korn.de:
>
> Am 12.08.2020 um 16:28 schrieb Niels Elgaard Larsen:
>
> dktue:
>
> Hi,
>
> I was wondering why there's no way to distinguish valley and upper
> stations of
> aerialways in OpenStreetMap.
>
> Usually an aerialway consists of
>
>  * one valley station
>  * zero or more mid stations
>  * one upper station (or "mountain station")
>
> What do you think you tagging this information with
>
>
> You could tag the aerialway with incline=up/down
>
>  station=valley_station/mid_station/upper_station
>
> ?
>
> Cheers
> dktue
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:aerialway=station
>
> That's true but I think it would be very hard for consumers to extract
> this information (think of an overpass-query to find all mid stations).
> Would there be any advantage in following your suggestions instead of
> explicit tagging?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

2020-07-28 Thread Kevin Broderick
Re: the discussion of driveways that are public ways, there *are* a fair
number of such things in New England, particularly Vermont. I suspect there
may be other places with similar situations, but I'm not sure; Vermont has
a particular set of laws around town right-of-ways that have preserved
public access to a lot of ways that you wouldn't necessarily think are a
public roadway by looking at them.

In Vermont, the typical case is that a house was built on an old road. The
town then decided to stop maintaining said road, but didn't release the
right-of-way. The homeowner now maintains the driveway (or sometimes more
than one homeowner maintains a shared driveway), but the right-of-way
remains open to the public, even beyond the regularly maintained driveway.
One such example is Orchard Road / Town HIghway 17 in Lincoln, Vermont
(c.f. https://www.openstreetmap.org/way/242164910); the legal right of way
continue from the driveway across the lawn and then into the woods, where
it becomes a typical woods road / Jeep trail. I'm not sure about the
history in this case, but the evidence on the ground is consistent with the
pattern (and it happens to show up pretty well on imagery). Where the ROW
dead-ends with the driveway, it's more likely that the town will go through
the steps to release the ROW back to the landowner (particularly if the
landowner is seeking to transfer the property).

In that case, I felt that it was most appropriate to tag the public ROW as
way=residential leading to the house and the continued way as
highway=track. IMO, I don't think service=driveway is appropriate for a
public right-of-way that allows access to other properties or roadways,
even if the *primary* usage is accessing a particular property.

On Tue, Jul 28, 2020 at 1:27 PM Matthew Woehlke 
wrote:

> On 28/07/2020 03.15, Martin Koppenhoefer wrote:
> > Never use the driveway tag on public ways
>
> Uh... IIUC, "public" driveways are just fine. A driveway is a minor
> service road leading to a residential *or business* property. I've
> tagged plenty of things that aren't really "roads" (entrances to parking
> lots, especially) as service=driveway.
>
> ...OTOH they probably aren't technically *public* roads, even though
> there are generally open to the public.
>
> For example: https://www.openstreetmap.org/way/378672974.
>
> --
> Matthew
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Path or track with many fallen trees

2020-06-26 Thread Kevin Broderick
Are they natural deadfall or human-cut?

I've seen photos of places where the USFS has felled a substantial number
of trees across a road that's being decommissioned (or just razed, as it
was never properly part of the forest road system to begin with). I believe
the intent is to both eliminate illicit motorized use and to discourage
environmental impacts that might occur if the road remained in place.

On Fri, Jun 26, 2020 at 9:59 AM Mike Thompson  wrote:

> Thanks for all of the great suggestions. I have used many of them.
>
> This is the way in question: https://www.openstreetmap.org/way/819638979
>
> Trees have been there sometime by the looks of them, and are unlikely to
> be cleared. To the FS this track no longer exists (they have blocked its
> only junction with the larger network with a mount of earth), so they will
> not be removing the trees.  Way seems to get little traffic, even foot
> traffic.
>
>
> Mike
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Path or track with many fallen trees

2020-06-26 Thread Kevin Broderick
As you've described it, I generally agree with Andrew's suggestions.

I do also think that expected local conditions matter; I've mapped some old
woods roads that are primarily used by Jeep and ATV traffic at this point.
Generally speaking, folks traveling those types of roads expect to find
varying conditions, including the possibility of deadfall. Many, if not
most, carry at least a hand saw. On those types of roads, I don't generally
try to keep track of deadfall, as it tends to be there until someone
happens to come through with a saw; if I see evidence of somewhat-recent
(i.e. last 12 months) cutting, I tend to ignore deadfall that happened to
land since then.

On Thu, Jun 25, 2020 at 8:58 PM Andrew Harvey 
wrote:

> It's a tricky one, but whatever is done I would need re-checking
> frequently to know when it was cleared.
>
> You could just add a single barrier=log somewhere as a rough
> approximation, or add barrier=log to the way segment which is affected.
> https://wiki.openstreetmap.org/wiki/Tag:barrier=log says it should only
> be used on a node, but if you don't know exactly where then I'd say using
> it on the way would be fine.
>
> You could also consider using one of the stages of decay lifecycle prefix
> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix#Stages_of_decay eg
> disused:highway=track, where disused is "Not currently available for use,
> but could be reinstated easily".
>
> For a path my rule of thumb is sac_scale=demandig_mountain_hiking means
> you need to use your hands and arms to get over something, so if that's the
> case because of logs, then I'd tag it that way.
>
> Lastly you can add a description so users could be presented with a text
> notice about the way http://wiki.openstreetmap.org/wiki/Key:description
>
> On Fri, 26 Jun 2020 at 09:46, Mike Thompson  wrote:
>
>> Hello,
>>
>> How would you recommend tagging a path or track that has many fallen
>> trees across it? There are too many to map each one with a node tagged
>> barrier=log.  Foot travel is legal, but physically difficult.  Horse and
>> bicycle travel are legal but probably physically impossible.  Motorized
>> travel is prohibited, and would probably be physically impossible anyway.
>>
>> Thanks in advance for your input.
>>
>> Mike
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Kevin Broderick
k...@kevinbroderick.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging