Re: [Tagging] me Di get y st, Vol 13 , Issue 49

[Alan Grant]

Long time No. P. 0.?pxo.llkjkt


On Fri 7 Aug 2020, 21:55 ,  wrote:

> Send Tagging mailing list submissions to
> tagging@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
> tagging-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> tagging-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
>
>
> Today's Topics:
>
>1. Re: Feature Proposal - RFC - more parking types (Tobias Knerr)
>2. Re: Feature Proposal - RFC - more parking types (Tobias Knerr)
>3. Re: Electric scooter parking (Jan Michel)
>4. Re: Feature Proposal - RFC - more parking types (Jan Michel)
>5. Re: Feature Proposal - RFC - more parking types (Philip Barnes)
>6. Feature Proposal - RFC - Takeaway drinks shops (德泉 談)
>7. Re: Electric scooter parking (Matthew Woehlke)
>8. Re: Feature Proposal - RFC - more parking types (Matthew Woehlke)
>
>
> --
>
> Message: 1
> Date: Fri, 7 Aug 2020 19:11:31 +0200
> From: Tobias Knerr 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - more parking types
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> On 06.08.20 22:52, Matthew Woehlke wrote:
> > https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking
>
> I like it, thanks for working on this topic! Two suggestions:
>
> Could you add a short definition of "compact"? I can guess that it's
> supposed to mean parking spaces for compact cars, but the first Google
> result for me is some parking system for trucks at motorways. Better to
> avoid the ambiguity.
>
> Also, I guess we need to decide if we need to be able to map something
> that fits more than one class, like a takeaway parking spot reserved for
> users with disabilities. If so, we could consider a solution something
> like parking_space:takeaway=yes, or a clearly defined meaning for
> semicolon-separated values.
>
>
>
> --
>
> Message: 2
> Date: Fri, 7 Aug 2020 19:13:24 +0200
> From: Tobias Knerr 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - more parking types
> Message-ID: <8741af4a-79d9-33f9-1cb6-3f0914445...@tobias-knerr.de>
> Content-Type: text/plain; charset=utf-8
>
> On 07.08.20 15:36, Matthew Woehlke wrote:
> > That said... now I'm on the fence. FWIW, the amenity=parking page
> > mentions parking_space=disabled as being supported by at least one
> > renderer, while one has to do quite some digging for how to use
> > access:*. Clearly we *do* need to improve the documentation here! Also,
> > it's less obvious how one would apply access restrictions for e.g.
> > charging, compact.
>
> I've always felt that using "disabled" as an access _key_ (i.e.
> disabled=* or access:disabled=*) was somewhat at odds with the usual
> logic of putting groups of users in the _value_ of access tags.
>
> I like that parking_space=disabled sidesteps this issue.
>
>
>
> --
>
> Message: 3
> Date: Fri, 7 Aug 2020 20:13:03 +0200
> From: Jan Michel 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Electric scooter parking
> Message-ID: <116a04ad-52ba-2c38-e3e9-675956709...@mueschelsoft.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 07.08.20 19:09, Paul Johnson wrote:
> > On Fri, Aug 7, 2020 at 12:00 PM Mateusz Konieczny via Tagging
> >  > > wrote:
> > Aug 7, 2020, 18:05 by ba...@ursamundi.org
> > :
> > On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging
> > mailto:tagging@openstreetmap.org>>
> > wrote:
> > amenity=parking + vehicle=no + electric_scooter=yes
> > seems like a terrible idea to me
> > Why?  That's actually pretty good.  amenity=parking is for motor
> > vehicle parking, electric scooters are a part of that.
> > Mostly because it will break all current users of amenity=parking
> > and at least for me place to place
> > electric scooter is not the same object as a car parking (in the
> > same way as bicycle parking
> > is not the same object as a car parking).
> > I feel like a data consumer unable to deal with access tagging is
> > already broken in advance.
>
> +1 from my side.
>
> It might be useful to have two different top-level amenity tags for
> parking lots for large and small vehicles, but not one tag for every
> type of vehicle.
>
> Any new tagging scheme must be able to support parking lots that are
> dedicated to several types of vehicles - at least those of similar size.
> We must be able to tag a shared motorcycle/moped/electric scooter
> parking area.
>
> If we really need a new 

Re: [Tagging] Missing access value (access=license / authorization?)

[Alan Grant]

On Sat, 28 Jul 2018, 00:28 Warin, <61sundow...@gmail.com> wrote:

>
> For me a 'licence' implies a certain level of skill or knowledge is
> required -
> e.g. licences for driving a vehicle, having a gun all should have tests of
> skill and/or knowledge.
> It is a formal process.
>
> A permit, on the other hand,  does not carry the same level of authority
> and implied skill/knowledge as a licence.
> It is usually a much less formal process to obtain a permit.
>

Obtaining a TV licence in the UK or Ireland does not require demonstrating
the ability to operate a television! I don't think the "less formal"
distinction holds either - obtaining a residence permit or an employment
permit is often a very formal process.

So I really don't think there is any systematic distinction to be drawn
between permit and license/licence. I think I would slightly favour licence
because potential confusion between licence and license is less important
than between permit and permissive - in the former case the intention is
obvious, whereas if someone mixes up permit and permissive there is no way
for other mappers to know. That is a minor point though, either way I think
this is a useful access category.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Golf wiki page

[Alan Grant]

But why do these discussions/controversies/ambiguities matter for golf
courses? Are we talking about how to tag areas of tree cover that may exist
between the fairways and greens?

On Mon, 16 Jul 2018 at 22:21, Paul Allen  wrote:

> On Mon, Jul 16, 2018 at 9:00 PM, Kevin Kenny 
> wrote:
>
>> On Mon, Jul 16, 2018 at 3:46 PM Mateusz Konieczny
>>  wrote:
>> > landuse=forest in OSM is for tree-covered area, not for area used for
>> logging-related purposes
>>
>> And we will keep having this discussion as long as there is no tag
>> that denotes the latter that doesn't get repurposed for the former.
>>
>
> As I recall (recollection may be flawed) the last go-round, the following
> seemed to be the case:
>
> 1) landuse=forest was intended for forestry, but the value (forest) was
> badly chosen.  Growing trees to be logged
> is a use of the land.
>
> 2) landcover=trees wasn't currently rendered (my recollection may be
> particularly bad on that).
>
> 3) Because landuse=forest is badly named (should have been forestry) and
> therefore misleading, and because
> landcover=trees isn't rendered, landuse=forest was being used for two
> things.
>
> 4) Usual arguments about what constitutes a forest versus a wood and other
> noise as the whole thread
> degenerated.
>
> My take on it: tag trees for logging purposes as landuse=forestry (note
> spelling) and trees not for logging
> purposes as landcover=trees or natural=wood as preferred (we can have that
> argument another time).  Then
> change the wiki to say that landuse=forest is deprecated because it gets
> misunderstood and misused, and point
> to the alternatives.  Introducing two new tags that supersede an existing
> tag used ambiguously is the only hope of
> making this sort of thing work.
>
> Landuse=forestry is less likely to be misused because "forestry" means
> logging and because we'd have
> landcover=trees (which might even constitute something named "XYZ Forest".
>
> None of this stands a chance of happening unless OSM Carto agrees to
> implement landuse=forestry and
> landcover=trees.  People don't use tags that don't render.  Well, for
> small, specialized things they do, but for big
> areas of trees they won't.  OSM Carto often won't implement new tags
> because they're not used much; people don't
> use new tags that don't render.  Rinse, wash, repeat.  What a shame we
> don't have a forum like a mailing list where
> we could all agree on sensible things to do and then they happen.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Canoe route

[Alan Grant]

I think there is an analogy with an aspect of hiking trails that I have
never been sure how to map. Sometimes a waymarked hiking route crosses a
beach, or follows an ephemeral river bed. There may be no physical footway,
path, or track across these areas that can be mapped. Following the ideas
above, maybe a way could be drawn with route=hiking and included in the
route relation. Has anyone done this or seen it used in the context of
hiking or other land-based route types?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

[Alan Grant]

On 22 June 2018 at 11:01, Paul Allen  wrote:

>  If I'm right, the only downsides are that I have to map two distinct
> objects (platform and
> stop position) and I have to repeat information (the name of the stop, at
> least) for both.
>
>
I have found that the downside is not so much in the initial mapping as in
the subsequent maintenance. Mapping two distinct objects from scratch is
tedious but do-able, especially if done by one mapper who takes a
consistent approach. But at least in my city, urban bus routes and their
stops change a lot and thus require a lot more maintenance than trams and
railways (without even getting into repairing relations that get broken by
other mappers working on something other than public transport). If the
stop moves and another mapper decides to update the map, you have to hope
they realise that the position and maybe the name and reference tags need
to be changed for 2 objects (or maybe 3 if there is a stop_area relation),
as well as updating the route relation itself.

Another downside, and apologies for going on about this but I haven't seen
a clear answer, is that you have to decide whether to add "bus=yes" to the
platform node (and indeed highway=bus_stop if you want to give it a good
chance of being generally rendered), and again hope that other mappers
agree with your approach.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

[Alan Grant]

On Wed, 20 Jun 2018, 21:03 marc marc,  wrote:

>
>
> For my part, I have an intermediate/pragmatic position.
> I find that bus=yes on a platform is incoherent.
> but if it is there, I keep it to avoid any ping-pong for this.
>

Yes, I have been doing something similar. Probably influenced by the JOSM
preset which doesn't prompt for transport mode when creating a new
platform. But like you I wouldn't delete it if already there.

I guess my question is whether this affects the proposed rendering. Is the
idea to have a generic platform rendering that is the same for buses,
trams, and trains? From the github page I get the impression that there
will be a specific bus stop rendering, but how can this work if there is no
obligatory tag indicating the transport mode? However I may not be
interpreting the github page correctly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

[Alan Grant]

On 20 June 2018 at 19:53,  wrote:

>
> So, valid minimal tagging under PTv2 is very simple:
>
>
>
> You have one node (if there is no clear platform) or a way (along the
> platform edge) or area (the whole platform), which is tagged as
> public_transport=platform (plus whatever mode of transport is served at the
> platform, so bus=yes or tram=yes, or …)
>
>
>
But adding bus=yes or tram=yes to the platform doesn't seem to be mentioned
on the wiki. These tags are mentioned only for stop_position. Are mappers
expected to know that these tags should be added to platforms? I'm sure I
have mapped lots of bus stops without adding this tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roundtrip

[Alan Grant]

>
>
> Message: 1
> Date: Mon, 28 May 2018 14:46:09 +0200
> From: Peter Elderson 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] roundtrip
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Nice to know.
> Do they have "trailheads" as well? That is, areas with amenities like
> parking space, bicycle clamps, toilets, guideposts, infoboards, ice  cream
> vending spot, waste containers, horse food dispenser, soda machines,
> blister service, ... well, some of of those anyway, clearly meant as
> starting/ending point of one or more trails? I'm told there are official
> trailheads in the United States, and we have those in Nederland as well,
> called TOP's.
>
>
In Ireland the only thing I would typically expect to find at the official
start point of a trail is an information board. The other things can be
found in some cases, but only if the trail starts somewhere that has these
amenities for other reasons (e.g. a park, castle or other tourist
attraction). I have never heard of a blister service! When I map hiking
trails I try to map the information board if there is one, as well as
mapping the relation. I often find the other amenities, if they exists,
have already been mapped by non-hikers.

I'd say it is pretty much the same in the south of Spain where I also hike
a bit, except for the famous Caminito del Rey where entry is controlled by
tickets with timed entry slots. This is truly a oneway route. It is not
just that the waymarks only point one way: it is actually prohibited to go
backwards. You enter by the northern end and are expected to emerge at the
southern end.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC proposed water property key 'ephemeral '

[Alan Grant]

>
> > From: Mateusz Konieczny 
>
> > I consider it as an useful information to distinguish permanent
> waterways and waterbodies
>
> > from nonpernament.
>

I agree. As a point of reference, the standard 1:25000 topographic maps of
Spain produced by IGN, the national geographic institute, distinguishes
between these two categories of water course. In the legend they are
labelled as "curso de agua: permanente, intermitente". I think that is a
good indication that this is a meaningful distinction. And I believe it is
very similar to how things are already mapped in OSM.

It is fine to give mappers ways to add finer details of seasonality,
ephemerality and so on, but the basic distinction that already exists seems
to be useful in its own right.

As an aside, dictionary definitions of "intermittent" tend to say something
like  "occurring occasionally or at regular or irregular intervals" (example
from Collins) which covers all forms of non-permanence, seasonal or
otherwise. So current OSM usage of the tag, as well as being meaningful and
useful, matches usage in everyday English.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roundtrip

[Alan Grant]

>
>
>
> I agree that it sounds round, but looking at google results I find that
> this use of circular route is extremely common.
>
>
That doesn't surprise me in the context of hiking/cycling trails (I am not
commenting on public transport). A specific example I am familiar with: the
national organisation responsible for trails in the Republic of Ireland (
irishtrails.ie) systematically labels trails as either "format: linear" or
"format: circular". Its counterpart in Northern Ireland (walkni.com)
similarly uses "route shape: linear" or "route shape: circular".

Of course many of the linear trails are far from a geometric straight line,
and the circular trails often do not resemble geometric circles. Readers
are trusted to understand that "circular" means that if you follow the
waymarks for the stated distance, you will return to the same point without
backtracking on your own footsteps (or not much, often there may be a short
section at the start that is covered in both directions). While "linear"
means that if you walk the official distance you will end up some way from
your start point. It may well be possible to return by the same route, but
that would mean covering twice the official distance.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Still RFC — Drop stop positions and platforms

[Alan Grant]

Same in Ireland, I don't think I ever hear any part of a bus referred to as
a platform, possibly because we didn't have those Routemaster buses with
open boarding areas.

And yes, a bus stop is a bus stop, plain and simple. It is not a platform
because there is normally no raised structure. Rail and bus have different
physical infrastructure so it is not surprising they use different words.
In that sense highway=bus_stop was a lot closer to natural language.

On Sun, 8 Apr 2018, 14:46 Paul Allen,  wrote:

>
> On Sun, Apr 8, 2018 at 12:49 PM, ael  wrote:
>
>>
>> In the context of buses, it tends to refer to the part of the vehicle
>> where people may stand to alight or board.
>>
>> In my part of the UK, we never referred to that part of a bus as a
> platform.
>
> The old AEC Routemaster buses operated in London did refer to that as a
> platform.
> But that was because it was not just an entranceway but also an area for a
> few
> passengers to stand when it was crowded.  Also there was no door, so
> people could
> hop on or off while the bus was moving (not legal, but people did it).  See
> https://en.wikipedia.org/wiki/File:Heritage_Routemaster.jpg
>
> In general, though, I wouldn't consider buses to have platforms.  And I
> would
> never refer to a bus stop as a platform unless it were raised higher than
> the
> pavement/causeway/sidewalk leading up to it.  A bus stop is a bus stop.
> Unless
> it's at a bus station, in which case it's a stance.  Unless it's at a bus
> station in Wales,
> in which case it's a Safle.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging