Re: [Tagging] How to Tag Steps in a Bridleway

[Dave F via Tagging]

Could you provide the link to the OSM way please?
DaveF

On 28/04/2024 15:19, Peter Neale via Tagging wrote:

Advice, please.

A local Public Bridleway has a few (3, 4 or 5 from Aerial imagery) 
steps going down before it passes under a road bridge, and a similar 
number up again on the other side.


How can I best tag this? According to the wiki, "highway=steps" seems 
to be *an alternative to*, not *a qualification of * 
"highway=bridleway". I don't want to mislead consumers by breaking the 
bridleway, but I don't want cycling consumers to be unaware of the 
fact that there are a few steps to descend / ascend, which may require 
a dismount.




Regards,
Peter

(PeterPan99)

___
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] The reason to not use loc_name is far too subjective.

[Dave F via Tagging]

The wiki says this:
"but only where this is deemed to be too much of a slang name or 
otherwise unofficial-sounding. Ordinarily though, the name which local 
people use is the name we set in the name=* tag!"


https://wiki.openstreetmap.org/wiki/Names#Local_names_(loc_name)

This is, once again, poor quality tagging. It's far too subjective. I 
mean, what determines the cut off point for a name being too "slangy"?


If it's not on a road sign or in a street gazetteer database then it's 
almost certain not to have a name. If there's no recorded evidence & the 
name used is purely word of mouth in the local area, then it should be 
tagged using loc_name.


DaveF

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

Re: [Tagging] Picnic_table with barbecue table extension.

[Dave F via Tagging]

Made of metal instead of the usual wood, for obvious reasons.
Extended table so hot things don't fall one anyone's knees.

Yes, can also be used by wheelchair users.

DaveF

On 22/05/2023 19:29, Timothy Noname wrote:
Isn't that A wheelchair friendly picnic table? I don't understand the 
BBQ reference?


On Mon, 22 May 2023, 19:06 Dave F via Tagging, 
 wrote:


https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi
I've a leisure=picnic_table but has an extended table top made of
metal to accommodate disposable barbecues.

Can anybody recommend a sub-tag that's more descriptive than
barbecue=yes?

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpicnic_table

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpg

Cheers
DaveF




___
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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Picnic_table with barbecue table extension.

[Dave F via Tagging]

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi
I've a leisure=picnic_table but has an extended table top made of metal 
to accommodate disposable barbecues.


Can anybody recommend a sub-tag that's more descriptive than barbecue=yes?

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpicnic_table

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpg

Cheers
DaveF



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

Re: [Tagging] Perimeter of a pitch

[Dave F via Tagging]

Have you not checked the OSM wiki for pitch?

DaveF

On 21/05/2023 21:08, Raphael wrote:

Hello everyone

Does the area outside the sidelines of a pitch up a board, a fence, a
change in surface or similar belong to a pitch (sports field) or not?
I'm asking because there's [some disagreement][^1] about how to map
`leisure=pitch`: [like this][^2] or [like this][^3]?

Unfortunately, Wikipedia is unclear: in the article on [out of
bounds][^4] it says that 'the sidelines are the white or colored lines
which mark the outer boundaries of a sports field'. However, the
article on [pitch][^5] states that 'the field of play generally
includes out-of-bounds areas that a player is likely to enter while
playing a match'.

Best regards
Raphael

[^1]: https://lists.openstreetmap.ch/pipermail/talk-ch/2023-May/011920.html
[^2]: https://www.openstreetmap.org/#map=19/46.00564/8.96361
[^3]: https://www.openstreetmap.org/#map=18/46.93564/7.42376
[^4]: https://en.wikipedia.org/wiki/Out_of_bounds
[^5]: https://en.wikipedia.org/wiki/Pitch_(sports_field)

___
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] Area of young trees - saplings

[Dave F via Tagging]

That appears to be for commercial purposes.
These samplings are 'out in the wild' planted in a publicly accessible 
field.


Cheers
DaveF

On 16/05/2023 15:27, Anne- Karoline Distel wrote:

A tree nursery? I think there's a tag for it.
My phone won't open the wiki right now, but maybe that helps already.

Anne

--
Sent from my Android phone with WEB.DE <http://WEB.DE> Mail. Please 
excuse my brevity.
On 16/05/2023, 13:49 Dave F via Tagging  
wrote:


Is there a tag for areas where you trees are planted? Too small to be
self supporting they're often individually attached to a pole &
encased
in a protective tube.

natural=wood seems inappropriate, as does scrub.

I thought 'saplings' would be suitable, but taginfo return none

DaveF

___
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] Area of young trees - saplings

[Dave F via Tagging]

Is there a tag for areas where you trees are planted? Too small to be 
self supporting they're often individually attached to a pole & encased 
in a protective tube.


natural=wood seems inappropriate, as does scrub.

I thought 'saplings' would be suitable, but taginfo return none

DaveF

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

Re: [Tagging] Deprecate sport=cricket_nets

[Dave F via Tagging]

I don't

sport=cricket_nets is fine. it's clear. it's specific. It doesn't 
interfere with any other tags.
The argument that it's not, technically, a sport & therefore inaccurate 
is... meh.


DaveF

On 30/01/2023 13:54, Illia Marchenko wrote:

Hello everyone,
I suggest deprecating sport=cricket_nets on the wiki and recommend 
leisure=practice_pitch & sport=cricket as a replacement, since sport=* 
generally refers to a sport, not a physical infrastructure.

Regards,
Illia.



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

Re: [Tagging] Route names being applied to tracks/paths

[Dave F via Tagging]

On 29/12/2022 09:47, Warin wrote:

Hi,

I think the 'names' should be removed from these 'unnamed' things 
..the 'name' is the name of the route not the individual tracks/paths 
some of which existed before some routes were created.


+1

DaveF

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

Re: [Tagging] Route names being applied to tracks/paths

[Dave F via Tagging]

I think this inconsistency is bad for OSM.

Many ways don't have names, even if they have routes along them. They 
are just footpaths, & tracks etc.


This instance on giving them a name tag is fake. It'll mean sections 
with one route will have their name tag rendered, but where additions 
routes join there will be no rendering.


If multiple routes are of equal standing, but you insist on adding a 
name tag to the way, how do you decide which takes precedent?


This thread reinforces my belief there's a lack of understand of route 
relations' purpose.


DaveF

On 30/12/2022 19:15, Yves wrote:
Remove the name of the way, put a name on each relations. Except if it 
makes sense to keep the name also on the way for whatever reason you 
see fit.


Le 30 décembre 2022 18:06:12 GMT+01:00, Dave F via Tagging 
 a écrit :


What do you do if there are two routes?

DaveF

On 30/12/2022 02:19, brad wrote:

+1
If the only name is the route name I think it makes good sense to
put it on the local way too, that's the name of the trail.

Brad

On 12/29/22 08:59, Zeke Farwell wrote:

I've heard the assertion that a way has no name but the route
that passes over it does many times.  While this is true in some
cases, in others it is not. Where the primary purpose of the way
is not for the route, this does make sense.  For example
mentioned by Jmapb where the Appalachian trail follows an
unnamed driveway or sidewalk.  In these cases, the primary
purpose is a driveway or sidewalk for local use, and the
Appalachian Trail just happens to follow it as well.  Here
putting the name Appalachian Trail on the way makes no sense. 
However, there are also dedicated sections of trail built first
and foremost to be a part of the Appalachian Trail and that have
no other name.  Omitting the name Appalachian Trail in a case
like that makes no sense to me.  That section of trail is indeed
called the Appalachian Trail.  The whole route is also called
the Appalachian Trail and that's ok.


On Thu, Dec 29, 2022 at 10:38 AM Jmapb  wrote:

On 12/29/2022 10:13 AM, Zeke Farwell wrote:

Yes, the way name tag should be the most local trail name. 
However, sometimes there is no local trail name and the
long distance route name is the only name.  In this case
putting the long distance route name on the ways also makes
sense.


I've been doing some mapping on the Appalachian Trail lately
and this appears to be the common practice, although the AT
is dominant enough that constituent trails sometimes lose
their local names over time.

Some mappers will take it a little too far and tag sections
of sidewalk and driveway that the AT follows with
name=Appalachian Trail (or even name=Appalachian National
Scenic Trail... IMO this is an official_name, and probably
only belongs on the route superrelation.)

It's common to see ref=AT as well, which is fine on trails
(even locally named ones) and perhaps ok on the sidewalks,
but adding it to a vehicular road seems iffy.

Jason




___
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 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] Route names being applied to tracks/paths

[Dave F via Tagging]

What do you do if there are two routes?

DaveF

On 30/12/2022 02:19, brad wrote:

+1
If the only name is the route name I think it makes good sense to put 
it on the local way too, that's the name of the trail.


Brad

On 12/29/22 08:59, Zeke Farwell wrote:
I've heard the assertion that a way has no name but the route that 
passes over it does many times.  While this is true in some cases, in 
others it is not.  Where the primary purpose of the way is not for 
the route, this does make sense.  For example mentioned by Jmapb 
where the Appalachian trail follows an unnamed driveway or sidewalk.  
In these cases, the primary purpose is a driveway or sidewalk for 
local use, and the Appalachian Trail just happens to follow it as 
well.  Here putting the name Appalachian Trail on the way makes no 
sense.  However, there are also dedicated sections of trail built 
first and foremost to be a part of the Appalachian Trail and that 
have no other name.  Omitting the name Appalachian Trail in a case 
like that makes no sense to me.  That section of trail is indeed 
called the Appalachian Trail.  The whole route is also called the 
Appalachian Trail and that's ok.



On Thu, Dec 29, 2022 at 10:38 AM Jmapb  wrote:

On 12/29/2022 10:13 AM, Zeke Farwell wrote:

Yes, the way name tag should be the most local trail name. 
However, sometimes there is no local trail name and the long
distance route name is the only name.  In this case putting the
long distance route name on the ways also makes sense.


I've been doing some mapping on the Appalachian Trail lately and
this appears to be the common practice, although the AT is
dominant enough that constituent trails sometimes lose their
local names over time.

Some mappers will take it a little too far and tag sections of
sidewalk and driveway that the AT follows with name=Appalachian
Trail (or even name=Appalachian National Scenic Trail... IMO this
is an official_name, and probably only belongs on the route
superrelation.)

It's common to see ref=AT as well, which is fine on trails (even
locally named ones) and perhaps ok on the sidewalks, but adding
it to a vehicular road seems iffy.

Jason




___
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 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] Route names being applied to tracks/paths

[Dave F via Tagging]

On 29/12/2022 15:13, Zeke Farwell wrote:
On Thu, Dec 29, 2022 at 9:15 AM Dave F via Tagging 
 wrote:



The actual way routes progress along often have their own, different,
name. These should be ithe name placed in the way's name tag.


Yes, the way name tag should be the most local trail name.  However, 
sometimes there is no local trail name and the long distance route 
name is the only name.  In this case putting the long distance route 
name on the ways also makes sense.


No, because in your example the way has no name. The name of the route 
is not the name of the way it travels along.
Keep routes within relations. Don't duplicate route names onto ways as 
duplication always leads to errors where only one name is updated.


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

Re: [Tagging] Route names being applied to tracks/paths

[Dave F via Tagging]

On 29/12/2022 12:32, Yves via Tagging wrote:
The simpliest way to map a long route is to give the same name to 
every ways it is composed of.


The reason route relations were created was because long routes share 
the /same/ ways. It avoids cluttering up the name & ref tags


The actual way routes progress along often have their own, different, 
name. These should be ithe name placed in the way's name tag.


DaveF

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

[Tagging] plantation=yes?

[Dave F via Tagging]

Hi

What does plantation=yes represent?

Associated with woods, but nothing in the wiki. 2437  uses worldwide.

Seems too vague to be OSM useful.

DaveF


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

Re: [Tagging] Lyft and nameless sectioning in OSM

[Dave F via Tagging]

On 11/10/2022 19:34, Evan Carroll wrote:


Some examples of these nameless sections are,

* w1101484647 by A_Prokopova_lyft


Not looked at all your examples, but i can't see a problem with your first.
It covers a large area of no just a building but car parking etc, and is 
surround by landuse of another type.


These landuse areas are useful for rendering.
Rendering individual items when zoomed out clutters the map & slows down 
rendering speeds (such as on GPSs), however it's still useful to 
indicated that it is an urbanised area of some description.




None of this is relevant to any areas WITH names: I'm all for these. 
IE, "Braeswood Squre", or "Meyer Park".


Landuse areas such as residential, commercial, retail etc shouldn't have 
names as location names are rarely of one landuse type. Much better to 
add a separate node which can be specifically placed near the centre 
where it can be rendered accurately.


Suburb names include school, parks, shopping areas etc so shouldn't be 
placed on residential areas.


Cheers
DaveF

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

[Tagging] not:brand:wikidata?

[Dave F via Tagging]

Hi

What is 'not:brand:wikidata'?

There are 5000+ in the database. Can't see any wiki details.
I'm struggling to comprehend the logic.

Cheers
DaveF

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

Re: [Tagging] Terminology primary feature, main tag, etc..

[Dave F via Tagging]

On 03/10/2022 09:11, Warin wrote:





2 primary features, identified by feature tags, represented by one 
OpenStreetMap element. Main key for stream is waterway, for road it 
is highway. In the osm2pgsql standard style, both are primary keys.





The guide says 'one feature = one OSM entry'. I would try to map each 
feature as one entry (node/way/what ever).




Isn't that a bit antiquated from the days OSM-Carto said they couldn't 
render multiple objects in one OSM way such as 
landuse=farmland/barrier-hedge etc, which they've now sorted.






A stream would not normal start and finish on a road .. so that would 
be a separate way compared to the road.. and I'd put ford on that 
section of road.




Occasionally they do:

ttps://snipboard.io/TVdf7A.jpghttps://snipboard.io/TVdf7A.jpghttps://snipboard.io/TVdf7A.jpg

If you map them as separate ways the ford & waterway tags aren't conjoined.

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

Re: [Tagging] Terminology primary feature, main tag, etc..

[Dave F via Tagging]

On 03/10/2022 12:55, Volker Schmidt wrote:



On Mon, 3 Oct 2022, 12:20 Marc_marc,  wrote:

imho only one main feature/objet : the stream bed
and car use it, a bit like a bicycle uses a road.

OT, but I cannot let it pass:
Roads, in most cases, are dedicated to vehicles (including bicycles), 
pedestrians, horse riders, ..., unless there are suitable sidewalks 
(for pedestrians), or suitable cycle paths (for bicycles). Most roads 
are not motorroads.


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

Re: [Tagging] Terminology primary feature, main tag, etc..

[Dave F via Tagging]

On 03/10/2022 06:51, Mateusz Konieczny via Tagging wrote:




Oct 2, 2022, 23:30 by dieterdre...@gmail.com:



sent from a phone

On 2 Oct 2022, at 19:40, martianfreeloader
 wrote:

- primary feature [1]
- main key [2]
- primary key [3]
- feature tag [4]

1) Are these synonyms (except for the key/tag distinction)?



yes

what about cases where multiple features are tagged on one object?

For example stream + road tagged on one line?

Or power pole + street lamp + stork's nest?


That's irrelevant to the question that was asked.

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 22:27, Christoph Hormann wrote:
Exactly. It also shows how we in OSM traditionally make decisions 
about tagging. An idea to change tagging practice was suggested - on 
an open channel for everyone to read and comment on without hurdles 
and with an archive that allows us now to read up on things years 
later. It was discussed and arguments and reasoning were provided both 
for and against the idea and based on that we reached consensus that 
it was a bad idea and it was abandoned.


Yes, but the demand was still made & the solution of writing competent 
code to enable the proposal was never implemented, so your point is?


DaveF


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 18:12, Clay Smalley wrote:
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging 
mailto:tagging@openstreetmap.org>> wrote:




Contributing to the database (also *volunteers*) are expected to
map to a certain standard. There shouldn't be a reason to expect
develops not to do the same.


If it's so easy, why don't you write the "few lines of code" necessary 
to fix this issue?

I did. Note the response.
https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636


Desiring relations to list in their entirety is *not* a "0.1%
case". Splitting them into 'super relations' should not be the
desired, final solution.


Amtrak routes, like many other public transit routes, are already 
split into super-relations (see [1], [2]).


Yes. I've done it myself on UK bicycle routes, but only out of 
necessity, due to the software limitation, not, as I stated, from any 
desire. It would be much less error prone with tags & ways being added 
to the wrong relations.


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

I'm surprised you think that as you were a contributor to the discussions:

https://github.com/gravitystorm/openstreetmap-carto/pull/3102

https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html

DaveF



On 22/11/2020 16:32, Christoph Hormann wrote:



Dave F via Tagging  hat am 22.11.2020 17:08 
geschrieben:

[...] OSM-carto demanding boundaries on ways

???

I am smelling fake news here.




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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 11:24, Richard Fairhurst wrote:
[cross-posted to talk-us@ and tagging@, please choose your follow-ups 
wisely]


If you go against the accepted principle of not X-posting on a 
newsgroup, you've no entitlement to lecture how others respond.




Brian M. Sperlongano wrote:
> It seems that we are increasingly doing things to simplify the
> model because certain tooling can't handle the real level of
> complexity that exists in the real world.  I'm in favor of fixing
> the tooling rather than neutering the data.


Actually, splitting way because software can't handle it, is making the 
database more complex.




I sincerely hope "I'm in favor of fixing" translates as "I'm planning 
to fix", though I fear I may be disappointed.


More broadly, we need to nip this "oh just fix the tools" stuff in the 
bud. (etc)


Likewise we need to stop software developers from expecting contributors 
to add data purely because they can't be bothered/not competent enough 
to write a few lines of code. (OSM-carto demanding boundaries on ways & 
numerous routers expecting multiple foodways to criss-cross pedestrian 
areas, are just two examples)


Contributing to the database (also *volunteers*) are expected to map to 
a certain standard. There shouldn't be a reason to expect develops not 
to do the same.


Desiring relations to list in their entirety is *not* a "0.1% case". 
Splitting them into 'super relations' should not be the desired, final 
solution.


If developers are offended at receiving suggestions on how to improve 
their software, or even have it criticized, then they should rescind it.


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

Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

[Dave F via Tagging]

To me, boardwalk describes the design & appearance rather than the 
surface construction: An elevated walkway.

Although I do admit that's mostly influenced by The Drifters song.

DaveF


On 21/11/2020 23:20, Mateusz Konieczny via Tagging wrote:

Is there some value in surface=boardwalk tag?

It seems to be a duplicate of surface=wood.

___
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] Tagging Cycle Route Relations vs. Ways

[Dave F via Tagging]

On 17/11/2020 18:56, stevea wrote:



I've found published data (from the authority
authorised to amend the route) are often too inaccurate, out of date or
lacking in detail to warrant transferring to OSM.

Then, don’t import, curate or transfer them to OSM.  I don’t believe we want 
"inaccurate, out-of-date or lacking in detail data" in OSM.


I'm baffled how you could completely misinterpret my comment about NOT 
entering data which would reduce the quality of the OSM database.


DaveF


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

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Dave F via Tagging]

On 17/11/2020 03:09, Seth Deegan wrote:

May I ask why not source=*?


TBH. I'm not a fan of the tag. I don't think it adds much value. It's 
too subjective/variable, but...


It relates to the individual contributor editing individual objects. A 
contributor can obtain data from many different sources within each 
changeset. Pushing the tag to the changeset meta data invalidates it's 
limited usefulness when added to individual objects.


 many times I find myself wondering where past mappers got the info 
for a route (this happened just today).


Anecdotal guesstimate: For cycle route - on the ground via signage for 
the vast majority. I've found published data (from the authority 
authorised to amend the route) are often too inaccurate, out of date or 
lacking in detail to warrant transferring to OSM.


DaveF


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

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

[Dave F via Tagging]

On 16/11/2020 16:17, Seth Deegan wrote:


The Cycle Routes Wiki Page 
 
states:


"It is preferred to tag the cycle routes using relations instead
of tagging the ways."

If I come across a route that has the Ways already tagged with the 
name =* of the route, 
can I delete the name 
=*s in the Ways and just 
create a Route Relation with the name?




Be careful. This is where many contributors get confused. The name of 
the *path* is often not the name of the *route*. A route relation can, & 
often does, go along paths with different names. Multiple routes can go 
along a path.


I assume this is not prefered because a number of applications use the 
names in the Ways themselves and not the Route Relation, most notably 
osm-carto.




It renders the names of the paths, not the routes.



However, some benefits of doing this might be:

  * Takes up less space in the DB
  * More tags that apply to the whole coute could be added to the
Relation like surface
=* and source
=* (like the
official map of the route).



Surface has no place in a route relation as it refers diectly to the 
path, not the multiple relations passing along it. Similar for the 
source tag.


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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Dave F via Tagging]

On 26/10/2020 23:26, Martin Koppenhoefer wrote:


crossing_ref as far as I have understood the tag, is not about the 
type of crossing,


I think you've misunderstood.

DaveF

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Dave F via Tagging]

'Zebra' shouldn't be use on the primary tag 'crossing'

crossing_ref was created for use within the UK because many parts of the 
rest of the world didn't understand what was meant by 'zebra'. It is, 
after all, a nickname:


https://wiki.openstreetmap.org/wiki/Key:crossing_ref

DaveF



On 16/09/2020 15:33, Martin Koppenhoefer wrote:



Am Mi., 16. Sept. 2020 um 16:27 Uhr schrieb Dave F via Tagging 
mailto:tagging@openstreetmap.org>>:


I thought the correct tag for this was crossing_ref. Have you
cross checked to see if they've been swapped instead of removed?



crossing_ref is a different kind of beast, as some people use it to 
tell whether there are zebra markings (can also apply to traffic light 
controlled crossings).


Frankly, I do not like the tag for zebra crossings, because this 
approach requires me to set 3 tags (one of crossing=zebra / marked / 
uncontrolled(?)  +, crossing_ref=zebra + highway=crossing, on every 
zebra crossing while I could use 2 and be done (highway=crossing with 
crossing=zebra).



Cheers
Martin


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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

It appears so.

Pretending there is a bias, doesn't mean there is one.

DaveF

On 21/10/2020 02:34, Phake Nick wrote:


At this point it's clear enough OP is just trolling?



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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

"Insanity Is Doing the Same Thing Over and Over Again and Expecting 
Different Results"


On 20/10/2020 19:02, Martin Koppenhoefer wrote:

but it’s fair to discuss every proposal on its own.



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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

No.
In the context of OSM, think of man_made=bridge akin to a noun. The 
actual bridge object.

bridge=* is akin to an adjective/attribute of an object.

DaveF

On 20/10/2020 05:56, Robert Delmenico wrote:

Essentially though, they mean the same thing:
man_made=bridge is for areas
yes is for ways



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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

On 19/10/2020 15:39, Robert Delmenico wrote:
Regardless of the origin of the term, the current use of 'man' is to 
identify adult males.


That's your misinterpretation.

You think you're being original with your proposal, but it's not the 
case. Every couple of years someone come along with the same argument. 
The results are always the same - Nothing happens, because almost 
everybody else comprehends the basics of the English language.


Option 4 is always the outcome.

DaveF




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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

That in a project to create an up to date map, there are people involved 
who get upset over things changing is, indeed, weird.


DaveF

On 19/10/2020 13:58, Mateusz Konieczny via Tagging wrote:

Yes, latest update date can be a hint
but treating it is as an argument to avoid
making an edit is really weird to me.

19 paź 2020, 14:51 od tagging@openstreetmap.org:

I'm in no way supporting the proposal, but this argument of 'it'll
make the entities look fully up to date" is illogical. If taken to
it's conclusion, nothing will ever be update again.

It's false to think that just because an entity was amended
yesterday, it means it's up to date:
If a typo in a road's name is amended, but the road is left
incorrectly tagged as 'tertiary' instead of 'primary' it's not up
to date.

Likewise an entity previously amended 10 years ago doesn't mean
it's inaccurate.

DaveF



On 18/10/2020 22:04, Oliver Simmons wrote:

Doing this would make over 3M objects have their date updated to
the present, when the last meaningful change may have been over 5
years ago.
It creates the illusion of data being up-to-date when all that
was changed was a tag key.


On Sun, 18 Oct 2020, 22:02 Graeme Fitzpatrick,
mailto:graemefi...@gmail.com>> wrote:



On Sun, 18 Oct 2020 at 20:39, Rory McCann
mailto:r...@technomancy.org>> wrote:

*definitely* not something one does auomatically.


But would it be so impossible? (Not suggesting that it should
actually be done!)

Couldn't a bot be set to simply find all cases of man_made=,
regardless of what it is, & change them to human_made=,
similar to using Find & Replace in a Word document?

& no, as you can see, I don't understand the technicalities
behind it all, so please be gentle with explaining that I'm
an idiot! :-)

Thanks

Graeme

___
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 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] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

Irrelevant of any implied meaning, 'man_made' always appeared to be a 
clunky, catch-all tag. OSM was being a bit lazy.
I mean, *everything* is either man made or natural.  We really should 
come up with more specific, accurate key tags.


DaveF

On 19/10/2020 12:45, Jo wrote:
It would be best to first consider the consequences of such a change. 
Weigh the benefits against what we lose in time (humanhours?) and 
resources/energy. And then there is still the point that many objects 
will get new timestamps for a change that's not really a change.


Anyway, artificial sounds like made up to me. artificial=dyke, not 
really a dyke, but it looks like it.


man_made has the advantage of being succinct. Most people will 
immediately understand what is meant by it. Almost nobody will think 
women were not involved in the creation of the feature.


Polyglot

On Mon, Oct 19, 2020 at 12:42 PM Robert Delmenico > wrote:


Nice investigating Nathan,

I would be open to using artificial instead of human_made.


Would it be best to change the proposal or start a second proposal?
Change man_made= to artificial=

Rob


On Mon, 19 Oct 2020 at 21:14, nathan case mailto:nathanc...@outlook.com>> wrote:

Pros and cons aside, “human-made” is not a term that is in
current widespread usage. As a native English GB speaker, I
find it clunky and somewhat distracting.

A better gender neutral term might be “artificial”, which is
already a synonym for “man-made” and is already widely used.

Indeed, the Handbook of Nonsexist Writing suggests:
"artificial, handmade, hand-built, synthetic, manufactured,
fabricated, machine-made, and constructed" as options instead
of man-made. Presumably the majority (if not all) of OSM
"man-made" tags relate to objects which are not naturally
occurring. Therefore "artificial" seems to hold.

Other sources:
https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/


https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
https://dictionary.cambridge.org/dictionary/english/man-made

An issue may arise if artificial is already being used as a
tag however.

Best,

Nathan
___
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 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] Proposal to change key:man_made to key:human_made

[Dave F via Tagging]

I'm in no way supporting the proposal, but this argument of 'it'll make 
the entities look fully up to date" is illogical. If taken to it's 
conclusion, nothing will ever be update again.


It's false to think that just because an entity was amended yesterday, 
it means it's up to date:
If a typo in a road's name is amended, but the road is left incorrectly 
tagged as 'tertiary' instead of 'primary' it's not up to date.


Likewise an entity previously amended 10 years ago doesn't mean it's 
inaccurate.


DaveF


On 18/10/2020 22:04, Oliver Simmons wrote:
Doing this would make over 3M objects have their date updated to the 
present, when the last meaningful change may have been over 5 years ago.
It creates the illusion of data being up-to-date when all that was 
changed was a tag key.



On Sun, 18 Oct 2020, 22:02 Graeme Fitzpatrick, > wrote:





On Sun, 18 Oct 2020 at 20:39, Rory McCann mailto:r...@technomancy.org>> wrote:

*definitely* not something one does auomatically.


But would it be so impossible? (Not suggesting that it should
actually be done!)

Couldn't a bot be set to simply find all cases of man_made=,
regardless of what it is, & change them to human_made=, similar to
using Find & Replace in a Word document?

& no, as you can see, I don't understand the technicalities behind
it all, so please be gentle with explaining that I'm an idiot! :-)

Thanks

Graeme

___
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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 17/10/2020 09:53, Martin Koppenhoefer wrote:


On 15. Oct 2020, at 15:12, Dave F via Tagging 
 wrote:

Please send all messages to the public forum Martin.


I will write to whoever I want, not your business.


Wow. The arrogant hypocrisy. (& v. short term memory)



You may already know it, but for the avoidance of doubt I’ll tell you 
again: every thread and all contributions can be seen here: 
https://lists.openstreetmap.org/pipermail/tagging/2020-October/thread.html


Not if private or on IRC, where the discussion for 2015 wiki edit took 
place. & is what I'm referring to.




If the mail headers are confusing you can always cross check your 
inbox with the public archive.


You appear to be confusing me with someone else.



neither am I, and while I am not scared to participate under my real 
name, I understand that other people might have reasons to choose a 
pseudonym or shorten their last name, and it’s ok.


You use a nickname.
My full name is viewable.

DaveF

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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 17/10/2020 10:00, Martin Koppenhoefer wrote:



On 15. Oct 2020, at 16:40, Dave F via Tagging 
 wrote:


Which negates any desire to change the meaning of railway=station 
from "places where customers can access railway services or where 
goods are loaded and unloaded."



I am perfectly fine with this definition, it was you who chose to 
ignore the “where goods are loaded and unloaded” part.


The diagram's previous incarnations made no mention of this part of the 
definition.


My interpretation for railway=station is: the train station (all of 
it). I am neither a train spotter nor a buffer kisser (not sure this 
term exists in English), but it seems clear that the tag implies the 
whole railway station, regardless of its application on a node or an area.


Which doesn't include signals/points way down the track.

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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 15/10/2020 11:01, OSM wrote:



Am 10.10.2020 um 00:35 schrieb Dave F via Tagging:


I edited a copy of the diagram (A-simple-station.svg) of a station 
layout, primarily to remove any references to PTv2 tags, a completely 
independent, duplicating tagging schema, irrelevant to anything to do 
with the railway=station tag.


That is the main problem I think:
You think, that railway=* and PTv2 tags are duplicating tagging schemas.


They are. One of the creators on the Transit forum stated the intention 
was for PTy2 to supersede railway=* tags.




But:
railway=* are _railway_ related tags - they are for infrastructure.


Which wiki pages claim that?

PTv2 tags are _public_transport_ tags - they are for the public 
transport use cases.


Tell that to the contributors who are adding PTv2 to tourist stations (I 
think it might be to do with another cock-up in iD editor)




And yes - these both are truly different.


Which negates any desire to change the meaning of railway=station from 
"places where customers can access railway services or where goods are 
loaded and unloaded."


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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

Please send all messages to the public forum Martin.


It was a post in reply to the topic.

Unlike a few train spotters in Germany I'm not scared to have all 
discussions be public & a matter for record.


Please don't dictate over events on which you have no authority.

DaveF.

On 15/10/2020 10:27, Martin Koppenhoefer wrote:

from where are you citing here? A private email?

Can we please discuss publicly here, and keep private discussion private?


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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

Please send messages to forum, John.

On 14/10/2020 03:17, John D. wrote:
unless you visit the platform or there is a visible sign how do you 
know where the train stops ?


Unsure of the relevance of that to this discussion.


how is nodes better than area ?



Points have already been made.

DaveF


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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 11/10/2020 09:25, Mateusz Konieczny wrote:

Including all this tracks feels ridiculous to me.


Agreed.
Over the past few years in the UK I've been maintaining/checking the 
railway=station tag to ensure there are the correct number.
I've the changed the few that were mapped as areas to nodes & swapped 
the areas to railway=landuse. It allows accurate positioning of the label.


-

After a discussion on Talk-GB I've also amended all railway=halt to 
stations.

https://wiki.openstreetmap.org/wiki/Tag:railway%3Dhalt
To decide on size is far too arbitrary/subjective for OSM . What makes 
on "small"? OSM requires objective tags to describe objects. I've added 
request_stop=yes to those that only have stopping trains if flagged down 
by a passenger, & looking to add more platform=* tags.  Both help to 
accurately describe stations.


DaveF



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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 11/10/2020 08:16, Martin Koppenhoefer wrote:
Are you mapping train stations as areas? From reading your replies 
here the impression I get is you are advocating for not extending the 
representation from a node to an area, right? I do not understand why 
you are fighting so hard to make a tag useless/superfluous (same 
meaning as public_transport=station) which you do not even use in this 
way, and without offering an alternative,


1. I'm not. I amended a graphic to correspond with the wiki text:" 
places where customers can access railway services or where goods are 
loaded and unloaded.". Nothing about signals/points half a mile away.

It's you who's "fighting so hard " against the definition.

2. PT tags have no influence on railway=*.

3. Alternative: landuse=railway., of which railway=station is a subset. 
if you require signals/points to be within a polygon (it's still unclear 
why this is a requirement for anyone) then this tag works. Looking at 
Germany it appears this is the case.



all allegedly just for the benefit of the  “ordinary people” from whom 
you suppose to have a distorted view of the situation, so they are not 
confused?


It appears it is you who's confused (from '17):
"What is the dividing line between the landuse=railway and the 
landuse=railway at the perimeter of the station? Where should we put 
railway=station if it is attached to an area?"



Why has the wiki been amended repeatedly since 2015 to remove any 
citation regarding inclusion of unrelated signals/points?
If the few (half a dozen?, certainly not "experts") who conceived it 
felt it was going to be widely accepted, why was it only discussed in a 
hidden, closeted IRC channel?
Why has there been no wide spread adoption, even in Germany, of this 
suggestion?


It's a dead proposal

Regards
DaveF

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

Re: [Tagging] railway=station areas

[Dave F via Tagging]

On 10/10/2020 00:34, Andrew Harvey wrote:



I believe most of this discussion is moot as the *vast* majority of
railway=stations are mapped as nodes:


I don't think that makes the point moot since nodes are just a quick 
first pass way to map a station,


railway=station is one of the earliest tags. Given the age of the 
project, I'm pretty sure we're beyond 'quick first pass'. especially in 
established countries.



eventually they should all be upgraded to areas.


It appears mappers have decided that's not what's best.


Tagging objects should be based on the understanding of what the
general
consumer of OSM accept it to be, not just a small group of "rail
enthusiasts" from Germany.


OSM should as much as possible try to remain agnostic towards a 
specific audience or use, we should strive to both be accurate and 
usable for both train drivers and public transport passengers.


See landuse=railway, railway=signal & railway=switch


This is not just a matter for rail enthusiasts from Germany.


Indeed.


 >the railway is from the rail network/infrastructure point of
view and
public
transit from the passenger point of view.

This seems to be a common misunderstanding by those advocating PTv2.


I'm not advocating PTv2, for a long time it just seemed like 
duplication of tags and a waste but if the ability to separate out the 
rail infrastructure from passenger viewpoint can be done with the 
tagging schema then that's maybe one advantage.


railway=station & PTv2 are separate schemas. They don't interact. If 
there's something missing in one, a tag's meaning can't be amended in 
the other. This is the misunderstanding.




No, it's because the public area is what most people consider to be a
'station'. (& most are mapped as nodes)


 but use a new tag for rail infrastructure so you can still correctly 
map the station for train drivers.


Why would train drivers, looking at OSM, need to have just a couple of 
signals enclosed inside a polygon?


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

[Tagging] railway=station areas

[Dave F via Tagging]

Apologies for breaking the thread, but I was unable to connect to 
Tagging & missed the initial message in my email client.


I'm the user in disagreement. (Although reading the current 
railway=station wiki page I'm not convinced there's an genuine 
alternative belief).


I believe most of this discussion is moot as the *vast* majority of 
railway=stations are mapped as nodes:

 Node    Way Relation
IT   2878    400 15
DE   4388    39  45
FR   2553    646 14
JP   9063    5   11
US   4140    174 8

I edited a copy of the diagram (A-simple-station.svg) of a station 
layout, primarily to remove any references to PTv2 tags, a completely 
independent, duplicating tagging schema, irrelevant to anything to do 
with the railway=station tag. I also amended the area indicating what 
roughly constitutes a 'railway station' according to the wiki. This is 
the only page I uploaded the image to. (It's not complete - the creation 
of the PNG image removes the angled text I used)


It appears that in 2015 a user took it upon himself to wholesale rewrite 
the wiki page, based on discussions in OpenRailwayMap IRC, a small 
clique group that keeps no record of any conclusions. If anyone knows if 
discussions took place on a major, wider reaching forum, please indicate 
them.


Tagging objects should be based on the understanding of what the general 
consumer of OSM accept it to be, not just a small group of "rail 
enthusiasts" from Germany.


https://en.wikipedia.org/wiki/Train_station -

"It generally consists of at least one track-side platform and a station 
building providing such ancillary services as ticket sales, waiting 
rooms and baggage/freight service."


@
If you went up to a commuter waiting on the platform & asked 'what 
constitutes a railway station' they would give close to the description 
above. I *very* much doubt they'd also turn, point & say 'Oh, & also 
that one signal. about about 1 km down the track'. Landuse=railway 
should be used for railway areas that far away from the station.


Further comments inline:

On Wed, 7 Oct 2020 at 18:42, Martin Koppenhoefer 
wrote:

> This was also discussed in the wiki:
> 
https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dstation#Station_an_area_.3F


That makes no mention of a station's extent.

> And it is what we do around here locally.

As I've shown, that's not the case, & anyway, OSM is global, not local.

> It is also what the definition of railway=stations says, the tag 
defines "A railway station".


See above at @.

> A fellow editor now insists that this tag should be used on the same area
> as defined for public_transport=station, i.e. the part of the train 
station

> that is accessible by passengers (platforms and buildings near the
> platforms).

From the wiki "Railway stations are places where customers can access 
railway services ". Signals/points are not relevant to customers.


On Wed, 7 Oct 2020  Andrew Harvey wrote:

>the railway is from the rail network/infrastructure point of view and 
public

transit from the passenger point of view.

This seems to be a common misunderstanding by those advocating PTv2. 
Railway=station is the original tag for all stations, including 
passenger. Introducing a disparate schema at a later date, does not 
change the meaning of the original tag.


> In practice many are mapped as the same area, but that's usually only
because unless you're a train operator it can be hard to actually survey
where the station starts and ends from the train network point of view.

No, it's because the public area is what most people consider to be a 
'station'. (& most are mapped as nodes)


Cheers
DaveF



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

Re: [Tagging] [OSM-talk] "Limitations on mapping private information" - wiki page

[Dave F via Tagging]

Please don't crossthread newsgroups.
If you have to alert the few who don't subscribe to both, post a message 
telling them it's on another newsgroup.


DaveF


On 16/09/2020 14:11, Niels Elgaard Larsen wrote:

Mateusz Konieczny via talk:

https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information

Do you think that this page is a good description of community consensus?

The page has
"This page is under development (May 2020). It may not yet reflect community 
consensus."
and I would like to check whatever it matches community consensus well or 
mismatches it.



I think we should avoid language such as "There is no need to split residential
landuse into individual plots".

Of course there is a need for someone somewhere to tag just about everything.
For example, if you want to buy a house you would want to see where the plot is.

This is not about needs, but about privacy, and maybe data quality.





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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Dave F via Tagging]

On 16/09/2020 14:59, Jeremy Harris wrote:

On 16/09/2020 14:26, Matthew Woehlke wrote:

On 16/09/2020 05.57, Martin Koppenhoefer wrote:

I noticed that crossing=zebra tag usage is drastically shrinking while
the
very generic crossing=marked, which was quite unpopular before (2013-2018
below 6000 uses) now went through the roof and is leading the tagstats
with
more than 1 million uses. What do you think about it, shouldn't we be
encouraging people to use more specific tags like crossing=zebra or
crossing=traffic_signals instead?

My understanding is that crossing=zebra is deprecated in favor of
crossing=uncontrolled / crossing=traffic_signals. In particular, my
understanding is that they are synonymous for (almost¹) all practical
purposes. (Also, that crossing=marked is not desired either...)

Please explain how crossing=marked is "very generic" and what value
crossing=zebra adds.

In the UK, at least, there is a legal distinction: motor traffic
is required to give way to pedestrians *waiting to cross* at a
zebra crossing; this does not apply for crossings that are marked
(and have feature useful to pedestrians such as refuge islands
and dropped kerbs).


Indeed; which is why crossing_ref=zebra (which is the correct tag for 
this) should not be tagged as 'uncontrolled'. The presence of a 
pedestrian controls the motor traffic.


DaveF




I could imagine, for example, sight-challenged pedestrians wanting
to know about zebra-crossings specifically.





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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Dave F via Tagging]

I thought the correct tag for this was crossing_ref. Have you cross 
checked to see if they've been swapped instead of removed?


DaveF

On 16/09/2020 10:57, Martin Koppenhoefer wrote:
I noticed that crossing=zebra tag usage is drastically shrinking while 
the very generic crossing=marked, which was quite unpopular before 
(2013-2018 below 6000 uses) now went through the roof and is leading 
the tagstats with more than 1 million uses. What do you think about 
it, shouldn't we be encouraging people to use more specific tags like 
crossing=zebra or crossing=traffic_signals instead?


___
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] Remove non-prefixed versions of 'contact:' scheme

[Dave F via Tagging]

Hi

 I request to replace all occurrence of the prefixed versions of the 
contact keys, as it adds no quality to the OSM database




On 04/05/2020 11:53, Valor Naram via Tagging wrote:

   I request to replace all occurrence of the non-prefixed versions of the 
contact keys like Key:phone, Key:email. Key:website to be replaced with the 
prefixed ones like Key:contact:phone, Key:contact:email, Key:contact:website . 
The current situation harms our database in a way that makes our data less 
useful. In order to be successful we need to standardize to the contact:
  prefix. No more multiple keys for the exact same purpose with just
different names!


But there would still be "multiple keys" (contact:phone, :contact:email etc)


  Make tagging more orthogonal! As someone who has
experience in database and normalisation it hurts to see that mappers
don't know how to take care of a database. It is time to take action and
  to clean up so OSM data gets more useful.


  * Normalisation of that data is required. Key:phone must be
translated to Key:contact:phone or backwards.


No it doesn't


  * Having two schemes leads to confusion of mappers (especially
for newbies) which they should use.


Then get rid the the 'contact' schema

DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

No to motorway, a motorway is a divided, limited access highway, 
distinct from other types of highway.   Trunk is ambiguous, it 
wouldn't bother me if it was removed.

How to miss the point
Note the "etc".



The wiki for cycleway, the 1st line:
"The highway 
=cycleway tag 
indicates a separate way for the use of cyclists. "


Separate from the road, not


All of the example pictures show a paved path or track.


Then tag them as surface=asphalt rtc, Tag mtb routes a surface=dirt etc
A couple of pictures never encompasses all scenarios.

DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 03/04/2020 00:35, Morten Lange via Tagging wrote:


I agree. And I am glad to se that seems to the overwhelming sentimemt on the 
list.
MTB trails are a specific type of cycleway. They are indicated as such 
by using specific tags in combination with highway=cycleway.



For those who want to produce MTB maps, this example might serve as an 
inspiration
https://mtb.waymarkedtrails.org/#?map=6!48.7746!6.679


Those are long distance cycle route relations. They travel over multiple 
types of ways including highway=cycleway!


DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 02/04/2020 20:11, brad wrote:



On 4/2/20 10:56 AM, Dave F via Tagging wrote:

And here we go again...

If a way is designated for riding a bicycle then it's a cycleway, 
irrelevant of severity or conditions.




The trouble with this is that very few trails are 'designated' for 
riding a bicycle.  They are legal for bikes, hikers, and horses. 
Cycleway is a lousy tag for a multiuse trail.


Where does it say 'cycleway' is a "multi-use trail" What you described 
I'd tag as 'bridleway'


Tags have a hierarchical standing based on an increasing number of 
allowed transport modes:


footway>cycleway>bridleway>roads>motorways.

If there are cases where specific modes are (not) allowed  yes/no can be 
used.


All other attributes such as width, surface etc should be described in 
sub/adjective tags.


DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 02/04/2020 15:53, Kevin Kenny wrote:


A key issue is that mtb:scale can't be the only indication. Otherwise,
we're falling into a trap - which has been a common trap in the past.
It's a trolltag https://wiki.openstreetmap.org/wiki/Trolltag - a
second tag that negates or massively changes the meaning of another
tag. "This isn't what you were expecting of a highway=cycleway: it's a
wilderness trail for highly skilled and adventurous MTB riders!"


mtb:scale is complementing, not negating. Along with other additional 
tags, It filters 'cycleways' to indicate a specific kind of cycleway



Just as bad, though, is the fact that tagging with an mtb:scale
requires technical knowledge of that specific sport. How do I tag,
"this trail is posted for MTB use, and would be impassable to a road
bike?"


You don't. You should only tag *anything* in OSM if you have knowledge 
of it.


Although, to help you out:
https://taginfo.openstreetmap.org/keys/mtb

DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 02/04/2020 20:02, brad wrote:


No need for sympathy, I strongly agree with what you're saying.  I 
think it's unfortunate that we even have the cycleway and footway 
tags, but they need to be treated as special cases of highway=path,


Are you also suggesting removing the "special cases" of motorway/trunk 
etc & just having highway=road?


DaveF



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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 02/04/2020 12:40, Snusmumriken wrote:

On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote:

just usually only a certain kind of bicycle.

Well, that's the problem, if one can't travel on a certain way with a
general purpose bicycle, then it shouldn't be tagged highway=cycleway


You're misinterpreting 'cycleway'. In itself, it carries no implication 
of permission, ability, condition or location. These should all be 
covered with additional sub/adjective tags.


DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

On 02/04/2020 11:33, Volker Schmidt wrote:

There is another aspect:
The wiki page highway=cycleway states also
" Tagging a way with highway
=cycleway implies that the
route is designated for bicycles."
This means it implies, at least in Italy and Germany, that this is
equivalent to this sign, which in turn implies that, the use of this way is
mandatory for cyclists, if the cycleway accompanies a road.
Obviously this concept does not apply to a MTB-only paths.
I sympathise with the MTB fraction in OSM, but I strongly suggest that
MTB-only paths be tagged as highway=path plus suitable MTB tagging and
cycleways remain cycleways that are suitable for (nearly) all bicycles (the
"nearly" regards in particular wider bicycles).


You're misinterpreting 'cycleway'. In itself, it carries no implication 
of permission, ability, condition or location. These should all be 
covered with additional sub/adjective tags.


DaveF

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Dave F via Tagging]

And here we go again...

If a way is designated for riding a bicycle then it's a cycleway, 
irrelevant of severity or conditions.


cycleway with mtb:scale combination is a valid tag.
mtb:scale gives an indication of what equipment would probably be required.

The problem, as so often in OSM, is subjectivity.

I do the occasional off-road riding and, going on the photographs on the 
wiki, I'm damned if I can distinguish severity between them.
 mtb:scale should be expanded to include level ways as value 0 as 
locations dedicated to MTBing often have gentle routes specifically for 
beginners/children.


DaveF

On 02/04/2020 10:10, Volker Schmidt wrote:

If a highway is mtb:scale=2 it is definitely not a cycleway. It is a
highway=path with mtb:scale=2
If this were to encounter a "cycleway" with mtb:scale=2 , I would consider
this an error and retag it as highway=path without hesitation.

I agree, that this is not explicitly stated in the bicycle wiki page, and
should be added there, but I would assume that this is the common
understanding. Anything else would cause major problems with the huge stock
of existing highway=cycleway in OSM that have no mtb:scale tag. Routers for
non-MTB bicycles would all need to change and evaluate the mtb:scale tag.

There is already a similar problem with the OpenCycleMap rendering in the
sense that it renders a dedicated cycle path in the same way as a path with
bicycle=yes. This has the effect that many MTB friends have added
bicycle=yes to "normal" hiking paths to make them appear as MTB friendly on
the map, but also with the problem that when I look at that map I wrongly
see a cycle paths where I would never be able to pass with my loaded
touring bike.

Please keep paths that can only be used by MTB clearly different from
cycleways that can be used non-MTB bicycles.



On Thu, 2 Apr 2020 at 10:11, Andrew Harvey  wrote:


My view based on current usage, reading of the wiki and general opinion is
that highway=cycleway is meant for any path that is either
designed/intended for bicycles or specifically designated (signposted) for
bicycles, irrespective of if it's an urban track or mountain biking track.

So a mountain bike track and an urban cycle track should both be tagged
with highway=cycleway as the primary tag. surface= and smoothness= can help
for both to help guide users on which kind of bicycle the track is suitable
for, and mtb:scale=/mtb:scale:imba= are used to indicate this is a
designated mountain biking track.

highway=path is specifically for a general use / unspecified path, which a
mountain biking track may be if it's informal/shared, but purpose built and
signposted mountain bike tracks don't fall into that category.

A similar thing applies to hiking tracks, sometimes they are designated
walking paths so use highway=footway + surface + sac_scale, but sometimes
they are just an unmarked or mixed use path so are highway=path + surface +
sac_scale.

Open to other opinions or comments.

On Thu, 2 Apr 2020 at 18:56, Phyks  wrote:


Hi,

A discussion in CyclOSM issue tracker [1] spotted that there exists
around 3500 highway=cycleway around the world which have specific
mountain bikes (MTB) tags. In particular, around 800 highway=cycleway
around the world declare a mtb:scale greater than 2, which would make
them impassable without a proper mountain bike. Such cycleways would not
be passable with a regular city bike. One example of such a case is at
[2].

Looking at the wiki page [3],
"the highway=cycleway tag indicates a separate way for the use of
cyclists"
which does not mandate explicitly that a cycleway be accessible with any
kind of bikes and should also cover dedicated paths for MTB. However,
the documentation around cycleways and bike features is very oriented
towards city cycling and there is no illustration about MTB-specific
cycleways.

So, is this considered a valid tagging or should it be represented by
another highway class (path, track, etc)? If this is valid, I propose to
add a statement in the wiki explicitly mentioning that cycleways can be
restricted for specific kinds of bicycles, for future questions.

Best,

[1] https://github.com/cyclosm/cyclosm-cartocss-style/issues/208
[2] https://www.openstreetmap.org/way/86978431#map=17/41.26426/-73.91907
[3] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway

--
Phyks

___
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 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] Route names that aren’t names

[Dave F via Tagging]

A general point to all:
Please don't confuse a way's name with a route's name. They are 
different. There can be multiple routes traversing over the same way.



On 28/03/2020 21:56, Richard Fairhurst wrote:


Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the
"M4". That's fine - plenty of people refer to it that way. But OSM
convention, dating back 15ish years, is that in situations like this, you
put the number in the ref alone. The M4 just has ref=M4, not name=M4.


However the authority responsible for naming conventions of entities, 
such roads or routes (ie Highways England/Sustrans/Whoever), wishes to 
name them, then that is how they should be tagged in OSM. Even if it  
includes what OSM perceives as a reference. OSM contributors don't have 
the authority to usurp that. The 'OSM convention' you mention is 
irrelevant - we map 'ground truth'.


If  HE wanted to name a section of the M4 'The bit of the M4 between 
junctions 14 & 15' then that's what it would be.


There's a similar situation in Britain where some think creating an OSM 
specific referencing system for public rights of way is the best 
situation. However inventing, what is in effect a unique language, makes 
it very difficult to communicate efficiently about the paths.



There are of course plenty of NCN routes which do have names. NCN 8 is Lon
Las Cymru. NCN 68 is the Pennine Cycleway. NCN 4 west of the Severn Bridge
is the Celtic Trail. NCN 1 from Newcastle to Edinburgh is Coast & Castles.


The Celtic Trail isn't the name of NCN 4. it's another route which 
happens to coincide (mostly) with a couple of NCN routes. From Sustran's 
blurb "The Celtic Trail is made up of two routes - NCN 4 & NCN 47".


The rest are similar, I believe.



(It's a side-issue, but Sustrans doesn't really have a consistent way of
referring to route numbers: you'll hear Sustrans staff refer to "Route 5" or
"NCN 5" or "National Cycle Network Route 5" or "National Route 5". I was at
a video conference with Sustrans staff earlier this week and heard several
variations. :) ).


Go with publications not chitter chatter over the phone.

DaveF

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

Re: [Tagging] Route names that aren’t names

[Dave F via Tagging]

On 28/03/2020 18:18, Richard Fairhurst wrote:

Hello folks,

Route relation names aren’t in a great state, are they?

Let’s say that I want to render cycle route names on a map (because, well, I 
do). I zoom in on a way along the East Coast of Britain and I find it’s a 
member of this route:
 https://www.openstreetmap.org/relation/9579
 name=NCN National Route 1

Hm, ok. That’s not the name of the route, it’s a duplication of the ref (and 
network)




I'm not sure I'm seeing the problem. What /is/ the "actual" name for UK 
cycle routes?
NCN 4 is named as National Cycle Network Route 4 as that's what Sustran 
call it.

I'm not convinced names & refs *have* to be mutually exclusive.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 20/03/2020 15:26, Janko Mihelić wrote:

the order of platforms and ways


I'm unsure what you mean. Could you expand please? Is there a wiki page?

DaveF


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 11/03/2020 12:16, Jo wrote:


But if the originally, more common
tag highway=bus_stop is already used, there is no need to add bus=yes.



OK, but if we have to keep  highway=bus_stop anyway, then one could also
say that it's not needed to add public_transport=platform to such nodes
anymore.


True. There is no requirement for public_transport tags. PTv2 adds 
nothing new.





And if we do that, then those nodes don't really need roles in the route
relations either,

The problem with PTv2 is that it was an attempt to streamline how buses
were mapped based on how railway was mapped,


Even if all existing transit (PTv1) tags were removed PTv2 wouldn't be 
'streamlined' as it reuires at least twice the number of tags to 
represent the same processes.


DaveF

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 11/03/2020 12:07, Joseph Eisenberg wrote:

I notice that they also refer to adding bus=yes etc to platforms

representing bus stops, which was not part of the PTv2 proposal, but I guess
tries to deal with one of the issues that led people to prefer
highway=bus_stop.

Yes, that is a rather silly thing that has been added, since it was
noticed after the proposal that if you removed highway=bus_stop and
only had public_transport=platform, then you would have no way to know
it was a bus stop rather than a train platform.

So now some mappers advocate adding a second tag bus=yes, originally
only proposed for stop positions. But if the originally, more common
tag highway=bus_stop is already used, there is no need to add bus=yes.


This shows, once again, how PTv2 just induces confusion & so leads to 
errors in the OSM database.


PTv2 was, naively, designed as a replacement for existing transit tags. 
They were not designed to be used in conjunction with each other. so 
Joseph's last sentence is irrelevant & incorrect.


PTv2 was a cock-up & needs to be rescinded.

DaveF



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 11/03/2020 12:12, Jo wrote:

That stop_position nodes became optional is probably because of my
influence.


Sorry. but 



  In the beginning they were definitely part of how PTv2.


railway=stop was, I believe, around before PTv2 concept.


I disliked this very much because all of a sudden we were using 2 objects to
define a single stop, duplicating details, which seemed like a very bad
idea. And it was.


You're misunderstanding stop/stop_position which is used to indicate 
where individual services stop. There can be multiple 'stops' per 
'railway station'.




About the stops, I would have all the details on a single node,
highway=bus_stop, railway=tram_stop next to the road where the passengers
wait.


Bus/Tram stops should have the equivalent set up as railway stations - 
One node to represent the whole station ie railway=station & numerous 
nodes to represent every place a train stops ie railway=stop.

It would require creating new tags for bus/tram stops.


DaveF

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

[Tagging] Barbecue disposal bins

[Dave F via Tagging]

Hi

Communal bins in parks etc for the disposal of hot ash or single-use 
tray barbecues. Unable to find the appropriate tag in the wiki or 
taginfo. Suggestions?


PS
Is anyone as irritated as I am by the shortening to 'bbq'. It seems to 
serve no beneficial purpose & consensus/convention is that OSM doesn't 
abbreviate. It is never too late to change poor tagging.


DaveF

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

Re: [Tagging] Criticism of PTv2

[Dave F via Tagging]

On 10/03/2020 20:52, Phake Nick wrote:


In the sense of bus, sidewalk could be a platform because they are raised
from the driving road surface. You can google "bus platform" and see many
example of the word being used in real world.


But that's not how it was implemented in the PT documentation.

In fact for nodes it specifically mentions "locations where there is no 
physical infrastructure"


DaveF



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 09/03/2020 22:26, Jarek Piórkowski wrote:


Separate relations per each route variant


If you mean bidirectional, they've been mapped since the inception of 
route relations.



- verifying that the highway ways are continuous in the relation.


Which PTv2 tags allows that?


DaveF

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

Re: [Tagging] Criticism of PTv2

[Dave F via Tagging]

On 09/03/2020 21:00, Alan Mackie wrote:


So it's better to label them all as platforms? I can't see any raised area
in a typical bus stop:...


Why would we tag it as if it looks like this?...


This is just one example of poor concepts implemented in PTv2. We should 
be mapping *physical*, not imaginary objects. They couldn't even come up 
with an original tag so hijacked an existing one, while completely 
disregarding it's dictionary meaning.

A platform is a platform, a perfectly flat bit of sidewalk isn't.


+1

DaveF


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

On 09/03/2020 13:21, Jarek Piórkowski wrote:


PTv2 is fine for people who want to handle routes that have variants
and branches and who want computer validators to be able to spot
potential errors in these branches.


I'm intrigued: What Ptv2 tags enable those?


DaveF

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[Dave F via Tagging]

This proposal by Stereo is nothing really new.  Just a alternative to 
routing which has been around since relations were introduced. 
Definitely not 'PTv3'. The 'via' option appears almost as difficult to 
maintain as including ways.



On 08/03/2020 01:41, John Doe wrote:




That would be tempting, because it would mean a lot less work for us in the 
short term. However, I'm afraid of ending up like PTv2 -
1. It 'does not deprecate the old tags', use of the new tags is 'recommended 
but not mandatory'...whatever that means.
It means PTv2 tags aren't required as there are existing tags performing 
the same job.

2. People with a preference for the old tags see that as an excuse to keep 
using them


No. They are preferred because they simple to comprehend, accurate & 
abundant.

3. Consumers see that as an excuse to not support the new schema, even after 8 
years of people requesting it - 
https://github.com/gravitystorm/openstreetmap-carto/issues/311
PTv2 isn't supported because it's not abundant (people get bored of 
adding them after a couple weeks)



4. People who want to use the new tags have to use _both_ sets of tags 🤦♀️
No they don't. They can use just the original tags. PTv2 tags are pure 
duplication.

5. Both sets of tags have to be documented, making the documentation more 
verbose than it might be.
They should coexist...for a transitional phase. But it has to be just that - a 
_transition_, not a permanent inconsistent mess.


The original tags are here to stay because they work. PTv2 is a 
*separate*, *independent* scarcer schema running in parallel that adds 
nothing over existing tags.


It is only PTv2 which is the mess. Even those who conceived it are 
confused by it.


DaveF

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

Re: [Tagging] amenity=faculty?

[Dave F via Tagging]

On 04/02/2020 16:03, Mateusz Konieczny via Tagging wrote:

Universities may have faculties, that often deserved to be mapped separately.

For example university may take a large area, possibly disjointed area across 
the city
but Faculty of dentistry, Faculty of forestry, Faculty of mathematics etc may be
possible to be mapped as an area/node.

Currently typical way to do that is to either
- map name on building
- create fake amenity=university with amenity=university

It seems to me that amenity=faculty would be useful.


But faculty is a subset of university. The primary tag is already used 
as amenity=university


Faculty=* is already in use.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversity#Faculties_and_departments

Cheers
DaveF


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Dave F via Tagging]

On 28/01/2020 21:23, Tomas Straupis wrote:


   Yet for ten years or even more the logic was that...

   Are there any reasons why this must change now? Any benefits?


I think your mistaken in your timeline. Cycleway & footway were around 
before path was introduced to cover the misinterpretation that cycleway 
automatically means cyclists have priority over pedestrians.


DaveF

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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Dave F via Tagging]

On 27/01/2020 16:41, Mike Thompson wrote:


I have never understood the use of tags like "cycleway", "bridleway", and
"footway."  To me these mix two different concepts (physical form and legal
access) in a single tag.


These values do not indicate a way's form. That is achieved with 
secondary, adjective tags such as segregated/width/surface/smoothness etc.



   Also, in the parts of the US where I have lived
there have generally only been "multipurpose" paths/trails (a few
exceptions).


These should be tagged with horse/bicycle/foot = designated/yes/no.

DaveF

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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Dave F via Tagging]

On 27/01/2020 15:36, Jmapb wrote:

My own impression over the years has been that mappers use
highway=cycleway on anything that primarily for bicycle traffic, and add
access keys for any other permitted traffic. Similarly for
highway=footway. So "highway=cycleway + foot=yes" and "highway=footway +
bicycle=designated" are quite common. Is there a general consensus that
these are better mapped as highway=path?



I tag any path which is designated for bicycle usage as 
highway=cycleway. I then add foot=designated, segregated=* if it is a 
shared use path (The vast majority of cases in the UK)


There's a misconception by some in OSM the highway=cycleway interprets 
as bicycles bicycle riders as having priority. This is not the case. I 
believe this misconception led to the path tag being created. AFAIK no 
major renderers distinguish the path tag. Some have actively discouraged 
it. I agree with them


DaveF

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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 16/01/2020 12:57, Paul Allen wrote:



So the wiki says now.  It's not what it said in the past.  But let's say you're
correct.  We both know that standard carto doesn't render physical objects
with a disused prefix.  I, and others, believe that it is important to
render physical objects whether they are used or disused because they are
navigational landmarks.


I agree.


  Joseph's example of a disused water tower is
a good one: it's a water tower and it exists and it's visible; whether or
not it is in use is of secondary importance (some might even argue it is of no
importance and shouldn't be tagged).


Then campaign to get Joseph/Carto to render disused:* prefix. To not use 
disused:* because Carto doesn't currently render it is the tail wagging 
the dog. Joseph has already said similar.

 I'm unsure why Carto ignores such a popular tagging scheme.


So if you get your way and disused=yes becomes forbidden,


I never said any such thing.


  or is treated the
same way as the disused prefix by standard carto


I want the opposite.


I don't see any upside to your position but I do see plenty of downside.


TBH, I think you've misinterpreted what I've said.

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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 16/01/2020 12:01, marc marc wrote:


you want me to believe that every time an object has gone,


It's not gone. We're talking about buildings which are physically still 
existing.



you make an enquiry to find out how it disappeared ?


Err.. No.You don't have to know why a building isn't used anymore to tag 
is as disused:*


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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 16/01/2020 12:01, Paul Allen wrote:


A lot of buildings have to be building=yes, for lack of anything better.
But
you already lost the battle with building=house, which is too firmly
entrenched to change.


Why would it need to change? If that's it's *current* usage tag it as 
house. If it changes to something else, amend it. .



BTW, what do you think this building is?
https://goo.gl/maps/vjpPFTSrQKdKA8Bt8
It's a private house.  But it used to be a chapel, and that's how you'd
describe it
if you wanted to use it as a landmark in navigational instructions.


Use historic=* because *that's* what it is - historic. It makes it clear.

Building=* is a current tag. Using it to describe its historical usage, 
based falsely on an assumption building usage (say, schools) has some 
sort of unifying physical characteristics, makes no logical sense.


DaveF

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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 16/01/2020 01:08, Paul Allen wrote:
That matches my thinking on the issue. Others seem to agree. 


Do they?


So, at the very least, the wiki needs to be amended.


Does it?

"Use the disused: lifecycle prefix on tags that relate to features that 
are in a reasonable state of repair but which are currently unused."


https://wiki.openstreetmap.org/wiki/Key:disused:

DaveF





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

Re: [Tagging] building=disused

[Dave F via Tagging]

Joseph says tagging usage should dictate OSM-carto:


the community should make tagging decisions based on what works
best for mappers and what makes logical sense, without worrying what a
particular renderer will do.



But then ignores the more popular disused: prefix

But this is not always sensible in the case of physical features like
a disused man_made=water_tower -


And also misunderstands that disused:* /does/ represent current physical 
objects.



the feature looks the same whether or
not it is full of water, and general database/map users are interested
in these features as orientations points in the landscape, not as part
of the water supply network, so it's sensible to use
man_made=water_tower + disused=yes.



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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 16/01/2020 11:34, marc marc wrote:

I'm also using was: because I don't care


Well. Done. You.

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

Re: [Tagging] building=disused

[Dave F via Tagging]

On 14/01/2020 19:32, marc marc wrote:

Le 14.01.20 à 19:34, Markus a écrit :

If i understand it correctly, building=* values describe how the
building looks, not how it is used. For example, a church that is now
used as a pub still remains a building=church.

I fully agree with that.
note that building:use may record the current use.


This never really stands up. Storing the supposed type could only ever 
work if there's a 'standard' style for each building type. Take schools, 
which can vary from a mud hut to Eton. If a school building changes to, 
say  a  warehouse, no one would go & point at it and say 'that's a school'



Using "building=* values describe how the building looks" is recording 
historical data. We don't do that in OSM


DaveF

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

Re: [Tagging] building=disused

[Dave F via Tagging]

You're using was: to represent the same meaning as disused:, so why not 
use the far more popular latter one?


On 14/01/2020 19:02, Markus wrote:


For example,
building=commercial + disused=yes on the area and was:shop=supermarket
+ name=* on a node within.




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

Re: [Tagging] building=disused

[Dave F via Tagging]

The correct term is 'don't tag *incorrectly* to suit the render'.

All tags are for the renderer, otherwise all the maps would be black 
lines & dots


DaveF.

On 14/01/2020 18:42, Kevin Kenny wrote:


Whenever I raise a point like that, there is a chorus of 'don't tag
for the renderer.'



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

Re: [Tagging] building=disused

[Dave F via Tagging]

The reason it's discouraged is it removes the building type. ie 
building=church. Even though it may not be used as a church currently it 
still looks like one. Renderers may still want to distinguish it as such 
as it's a prominent feature, useful for navigation.


On 14/01/2020 17:59, Andy Mabbett wrote:

JOSM warns me that "building=disuse" is deprecated



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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Dave F via Tagging]

The OP clearly defines the scope of his question with "pedestrian highways"

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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Dave F via Tagging]

On 09/01/2020 20:17, Volker Schmidt wrote:

oneway=yes|no needs indeed be applicable to vehicles only,


That tag on footways would apply only to walkers.

DaveF


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

Re: [Tagging] addresses on buildings

[Dave F via Tagging]

On 07/01/2020 17:18, Paul Allen wrote:

On Tue, 7 Jan 2020 at 16:51, Volker Schmidt  wrote:


May I come back to the navigation aspect.
Let's assume I have a single square building aligned with the compass
directions. It is between two parallel East<>West roads. It is placed
closer to the road on the North side.
Its entrance is on the South side from the road to the South. There is a
fence around the plot that stretches all the way from one road to the
other. The access is by a gate in the fence to the South. No footpath or
driveway is on the map. With other words, a quite frequent situation in
OSM. If I put the house number on the building the navigation device brings
me to a point close to the house on the North road, where there is no
entrance. If I place the number on a node close to where the gate is on the
South road, then the navigation device brings me to the desired place. But
I have no information about the association between the number on the gate
and the building.


Not frequent where I am, but it happens.  Map the fence, the gate, and the
path from the road to the front door.


This. ^

Bodging a tagging schema or adding spurious objects to cover the fact 
other objects are missing, makes no logical sense. Just add those 
missing objects. In this instance it greatly increases door to door 
routing accuracy & improves database quality overall. It often turns out 
to be less time consuming than fudging it.


DaveF


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

Re: [Tagging] addresses on buildings

[Dave F via Tagging]

On 07/01/2020 00:30, Jarek Piórkowski wrote:

Hi,
https://wiki.openstreetmap.org/wiki/Addresses#Denmark and
https://wiki.openstreetmap.org/wiki/Da:Adresser seem like a good place
to start.


Hi Jarek
Yes I had read the first link previously.


Of course nothing is truly forbidden in OSM as long as you are mapping
in good faith ("any tags you like" spirit) but local community
consensus can discourage some tagging schemes (such as separate ways
for sidewalks in Germany) and this is likely what Marc had in mind
when writing "forbidden" in quotation marks.


Again, no valid reason has been given by other local community as to why 
addresses can't be added to buildings to make the data useful. Being 
unable to create software to check buildings for addresses is not a 
valid argument.


Cheers
DaveF


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

Re: [Tagging] addresses on buildings

[Dave F via Tagging]

On 06/01/2020 21:55, Volker Schmidt wrote:

This depends on the country.

It is "forbidden" to put the address on the building in Denmark,

A similar rule exist in Italy: the number has to be put where the actual
entrance is,


Well, this is slightly better than floating nodes as in Denmark, but can 
you show us rule where it says address data can't be added to buildings 
if there's only one entrance? or do even individual domestic properties 
which have both front & back doors have two postal addresses?


Cheers
DaveF



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

Re: [Tagging] addresses on buildings

[Dave F via Tagging]

On 05/01/2020 18:37, Marc Gemis wrote:

This depends on the country.
It is "forbidden" to put the address on the building in Denmark,


Hi

Where does it say that? Where does it say it's forbidden to add address 
data to building polygons in OSM?


Keeping address data separate from buildings (which contain the primary 
tags) reduces the usefulness of the data. It prevents mail-sort 
compilations for residential houses. or locating all hairdressers in 
Randers.



Recently, I asked a few people, including JKHougaard,  the creator of 
https://www.openstreetmap.org/user/autoAWS, but the all failed to confirm.


He gave this as an explanation:

"The reason we treat addresses in Denmark nodes is because that is how 
an address is legally defined here."


 However, he failed to say how this Danish opendata licence prevents it 
from being transferred to buildings within OSM


This was given to me by another user as justification:

"The house number in the address shall refer to the exterior entrance 
door or similar to a building or part of a building which the address 
identifies." https://w2l.dk/file/661441/The_Danish_Adress_act.pdf


But that says nothing about it relating to OSM

This was provided by another user & I suspect is getting close to the 
real reason:


"Transferring the data to buildings will mess up the maintenance"

I asked JKHougaard why his bot couldn't be updated to check ways. "that 
is beyond my coding skills" was his reply.


I may be wrong, but given the responses I can only conclude it's a smoke 
screen to cover up the limitations of the bot.


DaveF


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

[Tagging] pavement placed plaque

[Dave F via Tagging]

Hi

I've a carved stone plaque(?) that's fixed flush into the pavement. it's 
to indicate the start/finish point of a long distance walk. 
https://whatsdavedoing.com/cotswold-way-guide/#start


Two questions:

1 Is plaque the best name? Our Wiki quotes Wikipedia as it being 
vertical, but that seems a bit restrictive to me.

https://wiki.openstreetmap.org/wiki/Tag:memorial%3Dplaque

2. Are there any alternatives to 'memorial' which again, seems too 
specific/restrictive, tourism=information, information=plaque maybe?


Anybody have similar examples?

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

Re: [Tagging] Rail segment in a bike route

[Dave F via Tagging]

On 14/12/2019 14:42, Volker Schmidt wrote:

Adding a bicycle=dismount is OK I suppose, but I'm unsure there's really

a problem.

This street in Padova  carries
a (mono-rail) tram (railway=tram) and is closed to bicycles, tagged with
bicycle=no.
I intended to re-tag this with bicycle=dismount in line with the notion
that you are allowed to push your bike along, like you are allowed to push
your bike across the pedestrian area in the city center.
I would not have dreamed that this would mean that I would have to take my
bicycle on the tram (which I am not allowed to do anyway).


Your example is irrelevant to the point in two ways - it doesn't have a 
bike route relation & what you're actually tagging is the residential road.


Cheers
DaveF


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

Re: [Tagging] Rail segment in a bike route

[Dave F via Tagging]

On 14/12/2019 10:17, Martin Koppenhoefer wrote:

if I saw this I would think I’d have to push the bike there, not take a train


Well, yes - you would have to push it into the carriage. Your assumption 
would only occur if the railway tag is ignored.


Cheers
DaveF

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

Re: [Tagging] Rail segment in a bike route

[Dave F via Tagging]

On 14/12/2019 07:00, Francesco Ansanelli wrote:

Thanks everybody for the feedback.
I've added the bicycle=dismount on the railway. I think we still need some
role in the relation to better describe the situation.


Adding a bicycle=dismount is OK I suppose, but I'm unsure there's really 
a problem. No extra tags need to be added to relations. Remember that 
ways can have multiple route relations.


Routing software creators will always refer to tags on the ways. Common 
sense needs to be exercised - If a router comes across 'railway' 
'dismount' should be a assumed.


Cheers
DaveF

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

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

[Dave F via Tagging]

We are (almost) all volunteers, Joseph. It's irritating that this claim 
is repeatedly rolled out as an excuse.


I'm increasingly disappointed my *voluntary* contributions to the OSM 
database are are not being fairly or accurately being represented by 
OSM-Carto due to errors in the programming. It's ridiculous these errors 
(many of the 400 open issues) can't be fixed "for many years".


Is OSM-Carto fit to be promoted as OSM's flagship, de-facto rendering?

Please get back to me when OSM-Carto has a valid reason for not 
rendering disused bridges.


DaveF

On 11/11/2019 14:44, Joseph Eisenberg wrote:

DaveF, reloading the database could be done more often, but it does
take time and server resources, and everyone is a volunteer. People
can help by donating money to the OSMF to help run the servers, or
donating time to help improve the openstreetmap.org website
infrastructure.

At Openstreetmap-carto there are over 400 open issues
(https://github.com/gravitystorm/openstreetmap-carto/issues), and a
particular request is more likely to happen if a contributor
volunteers to do the work. In this case the first step would be to
decide which tags under `emergency=` should be treated as polygons
when mapped as closed ways, and then submitting a PR (pull request) to
add these for the next database reload, which might happen soon, if
enough people are interested in making it happen.

- Joseph Eisenberg

On 11/11/19, Dave F via Tagging  wrote:

On 11/11/2019 02:20, Joseph Eisenberg wrote:

If this is about Openstreetmap-carto, there is now an open issue:
https://github.com/gravitystorm/openstreetmap-carto/issues/3968 - note
that rendering area features in the "emergency=" key, like this, would
require reloading the database on the openstreetmap.org servers.


it wasn't about rendering really, it was just the illogical use of keys
making it more awkward for all database users.

I gave up on referring to anything relating to OSM-carto issues for
precisely the reason you highlight - to render
emergency=ambulance_station It requires a database reload which is only
performed "*every few years*". #Ridiculous


DaveF

___
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] emergency=ambulance_station vs amenity=fire_station

[Dave F via Tagging]

On 11/11/2019 02:20, Joseph Eisenberg wrote:

If this is about Openstreetmap-carto, there is now an open issue:
https://github.com/gravitystorm/openstreetmap-carto/issues/3968 - note
that rendering area features in the "emergency=" key, like this, would
require reloading the database on the openstreetmap.org servers.



it wasn't about rendering really, it was just the illogical use of keys 
making it more awkward for all database users.


I gave up on referring to anything relating to OSM-carto issues for 
precisely the reason you highlight - to render 
emergency=ambulance_station It requires a database reload which is only 
performed "*every few years*". #Ridiculous



DaveF

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

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

[Dave F via Tagging]

On 10/11/2019 16:53, Greg Troxel wrote:


So I agree these tags should be kept separate.


I'm struggling to comprehend how a question I deliberately kept simple 
at just one sentence long can cause so much misinterpretation.



  As for emergency= and
amenity=, that's a historical artifact and doesn't matter.


That just makes it historically wrong. Being incorrect for a long time 
isn't a reason not to fix it. Having two different keys to describe 
entities which come under the heading 'emergency services' is confusing 
to experienced OSMers let alone newbies.


As emergency=ambulance_station appears to be a later invention, was 
there a valid reason fire_station did follow suit?


DaveF

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

[Tagging] emergency=ambulance_station vs amenity=fire_station

[Dave F via Tagging]

Hi

Simple question (which I presume has been previously discussed) :

Why the different key tags to describe what are essentially synonymous 
entities?


DaveF

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

Re: [Tagging] the nature of large-scale paid edits (was Re: Service road)

[Dave F via Tagging]

On 08/11/2019 03:32, Warin wrote:
There is simply too much other stuff to do that be worried by every 
driveway. So I only map them where they are of some interest to other 
than the resident.


Apologies Warin, but this has just made me genuinely lol. You have an 
opinion on almost every minutiae of OSM tagging to the extent I'm 
surprised you have time to actually add any data. I'm so pleasantly 
surprised you've decided to draw a line in the sand at driveways. :-)


DaveF

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

Re: [Tagging] Service road - Can it be a driveway if serving multiple houses?

[Dave F via Tagging]

On 06/11/2019 18:04, Greg Troxel wrote:


I think a shared driveway is still a driveway.


This is the crux. The only distinguishing attribute from what we'd all 
tag as a driveway is that's it's shared.
A driveway is designated as privately owned rather than by the local 
authority. It isn't defined by how many own it.


As Greg pointed out no one gave it a specific name in this thread. All 
references were to it being a 'shared driveway'.




If other people had tagged in driveway, and amazon removed it as part
of a large-scale paid edit, I think that's totally not ok.


I'm unsure if this is a blanket policy of Amazon, I think it maybe just 
this one editor.



I see large-scale paid edits as part way to mechanical edits, and think
they have to be more deferential than normal mappers.


I really think OSM as a whole needs to steer away from considering edits 
based purely on their size as something to be fearful of. As long as the 
data is accurate & improves OSM's database quality then it should be 
welcomed.


With Amazon specifically, the data is coming from their GPS recordings & 
is being gradually added. (Unsure whether the contributors being paid 
makes any difference). Overall I'd say their edits contain the same 
amount of errors as the average OSM contributor.


DaveF

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Dave F via Tagging]

On 05/11/2019 13:11, Andy Townsend wrote:


https://www.openstreetmap.org/way/65663472 (Meir Tunnel, dry even on a 
wet Wednesday in Stoke*) bans foot and bicycle traffic, so you can 
neither walk nor cycle through it.  A cycle router would have to 
flat-out avoid it, whereas it may choose not to avoid a short 
bicycle=dismount section if it saves a long detour.


Shouldn't the preceding ways also be 'no' back to the previous junction?

DaveF


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