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

2020-11-23 Thread 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

2020-11-22 Thread 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

2020-11-22 Thread 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

2020-11-22 Thread 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?

2020-11-21 Thread 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

2020-11-17 Thread 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

2020-11-17 Thread 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

2020-11-16 Thread 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

2020-10-26 Thread 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

2020-10-26 Thread 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

2020-10-20 Thread 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

2020-10-20 Thread 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

2020-10-20 Thread 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

2020-10-20 Thread 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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-17 Thread 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

2020-10-17 Thread 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

2020-10-15 Thread 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

2020-10-15 Thread 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

2020-10-14 Thread 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

2020-10-13 Thread 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

2020-10-13 Thread 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

2020-10-10 Thread 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

2020-10-09 Thread 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

2020-09-16 Thread 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

2020-09-16 Thread 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

2020-09-16 Thread 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

2020-05-04 Thread 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?

2020-04-03 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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?

2020-04-02 Thread 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

2020-03-29 Thread 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

2020-03-28 Thread 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

2020-03-20 Thread 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

2020-03-20 Thread 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

2020-03-20 Thread 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

2020-03-20 Thread 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

2020-03-18 Thread 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

2020-03-11 Thread 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

2020-03-10 Thread 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

2020-03-10 Thread 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

2020-03-09 Thread 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

2020-03-08 Thread 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?

2020-02-04 Thread 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?

2020-01-28 Thread 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?

2020-01-27 Thread 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?

2020-01-27 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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

2020-01-16 Thread 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?

2020-01-12 Thread 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?

2020-01-09 Thread 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

2020-01-07 Thread 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

2020-01-06 Thread 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

2020-01-06 Thread 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

2020-01-06 Thread 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

2019-12-20 Thread 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

2019-12-14 Thread 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

2019-12-14 Thread 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

2019-12-14 Thread 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

2019-11-12 Thread 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

2019-11-11 Thread 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

2019-11-11 Thread 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

2019-11-10 Thread 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)

2019-11-08 Thread 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?

2019-11-07 Thread 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"?

2019-11-05 Thread 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


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

2019-11-05 Thread Dave F via Tagging

Hi

In the UK, Amazon Logistics are adding useful data from their GPS'd 
delivery vehicles. Mainly highway=service as the last part of their 
journey to a destination.


However, one of their contributors removed service=driveway from a 
highway=service road. In the changeset comments they said it was because 
it served multiple residential properties.


https://www.openstreetmap.org/changeset/76576604#map=19/51.33398/-2.27945

From memory, it wasn't signed as private, but it appears to be 
unadopted by the local authority (There are no raised kerbed pavements, 
drainage or lighting). I'm assuming it's shared ownership.


For indicative purposes only. (The image is ten years old):
https://www.google.co.uk/maps/@51.3343975,-2.278377,3a,60y,185.39h,67.19t/data=!3m6!1e1!3m4!1s5I6ruGYQsgQv4cC0iLM6SA!2e0!7i13312!8i6656

Personally I see no problem tagging this as a driveway even if it's shared.

Thoughts?

DaveF

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


Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

2019-10-28 Thread Dave F via Tagging



On 28/10/2019 09:42, Shawn K. Quinn wrote:

On 10/28/19 03:44, Mateusz Konieczny wrote:

"sign having a hospital icon and no name can simply be tagged
type=destination_sign + amenity=hospital"
https://wiki.openstreetmap.org/wiki/Relation:destination_sign

For me it seems a horrible and unacceptable tagging - amenity=hospital
should be on hospitals
and nothing else.

+1

Maybe destination:amenity=hospital instead?


+1

Mateusz, have you search for other similar signs? I'm sure it's not the 
first.


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Dave F via Tagging

No.

Just because, once again, routing software fails & you don't use a 
certain tag it is not a reason to deprecate. The tail does not wag the 
dog in OSM.


Contact the navigation software developers & tell them to write some 
decent code.


DaveF

On 23/10/2019 09:26, Florian Lohoff wrote:

Hi,

i just saw a changeset of someone makeing a mini_roundabout
from a junction=roundabout. I have never used mini_roundabout
as non of the routing/nav engines i tried actually supported it
when i did.

Instead of making it some special type of roundabout with seperate
tagging i'd vote for deprecating the mini_roundabout and adding
a tag making the area of the junction=roundabout be an area which is
driveable. e.g. why not area=yes on the junction=roundabout.

That would add a lot of information - e.g. the size of the roundabout
etc - and it would eliminate another "special" case which is mostly
unsupported.

Flo


___
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] Feature Proposal - RFC - sunbathing

2019-10-16 Thread Dave F via Tagging



On 15/10/2019 16:24, Vɑdɪm wrote:


Apparently you've misunderstood the proposal. It is not about a place where
sunbathing is generally allowed, which indeed would be too vague/general.

It's about a dedicated place.


That you've changed your tune & given vague/unrealistic examples 
suggests you don't really have a proposal with any validity. It appears 
you have a solution looking for a problem.


Maybe your OSM time would be better spent on other aspects of the project?

DaveF

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


Re: [Tagging] Feature Proposal - RFC - sunbathing

2019-10-14 Thread Dave F via Tagging

Better to drop it. it's too vague/general.

All the examples in this list are leisure places (Beach, lido, park) at 
which sunbathing is just one of many assumed activities. Swimming, 
kicking a ball about, throwing a frisbee etc.There's no requirement to 
explicitly tag it.


You'd be better off tagging places where sunbathing is explicitly 
banned. Much more quantifiable, Much more likely to be designated with a 
sign.


DaveF

On 14/10/2019 16:49, Vɑdɪm wrote:

OK. Any more comments or we better go for a vote?



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

___
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] Cycling relation misuse

2019-10-14 Thread Dave F via Tagging



On 14/10/2019 14:50, Dave F via Tagging wrote:


PS Can anyone explain what an " academic member" is?


Just found out it was a spell-correct typo. Volker is an ACA member

DaveF

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


Re: [Tagging] Cycling relation misuse

2019-10-14 Thread Dave F via Tagging

On 14/10/2019 00:17, Warin wrote:

On 14/10/19 07:26, Volker Schmidt wrote:

(disclosure: I am academic member, but express my personal view)
The Great Divide route is, to my knowledge, not signposted. The 
source for thr route is most likely either a GPX track from ACA or a 
map set from ACA,  which has their copyright on it. aca sells the GPX 
track and the map.

For these reasons I think the Great Divide should no be in OSM.


Say I used a copyright map to travel somewhere. During that trip I 
generate a GPX track.
Should I not then have the right to use that generated GPX track to 
map things in OSM???


+1
Do it all the time using current UK OS maps.

PS Can anyone explain what an " academic member" is?

DaveF


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


Re: [Tagging] Cycling relation misuse

2019-10-11 Thread Dave F via Tagging
Are you able to properly verify these are all "Random road your cycling 
club likes to ride on the weekend" & not designated/signed routes?


ATM it appears you're vetting them purely on the class of highway used.

Designated cycle routes can go along "just regular roads, with no 
designation for cyclists."


DaveF





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


Re: [Tagging] building typology vs usage

2019-09-13 Thread Dave F via Tagging

On 13/09/2019 16:14, Wolfgang Zenker wrote:


That would be kind of redundant, wouldn't it? We already use other tags
for the current function of a building,
I'm repeating much of my of my previous comment, but no, the schema 
which hijacked building=* to represent the original historical function 
of a building never took off*. The vast majority of contributors use it 
for it's current purpose. OSM isn't for the mapping of redundant 
historical information.



  so building=* is mostly useful
when the uilding does look like it was built for some other function
than it's current one.


How do you know what it was originally used for just from your 
interpretation of what a building of a certain function should look 
like? It's just guesswork. How does tagging this perception add to, or 
improve the quality of the OSM database?


"OpenStreetMap is a place for mapping things that are both /real and 
current/"


*building:use = 628 167
building!=yes  = 65 221 930

DaveF

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


Re: [Tagging] building typology vs usage

2019-09-13 Thread Dave F via Tagging

On 11/09/2019 14:50, Paul Allen wrote:


I said that if it was a church and looks like a church then tag the building as 
a church even if it now functions as something else.


Buildings don't have a 'type'. There's no 'class', no standard 
architectural style or size. A quick image search proves that.


OSM "is a place for mapping things that are both real and current"

'building=*' is to indicate its current usage.

/If/ there's an insistence on recording it's original usage, if actually 
*known*,not just observed, then an appropriate *clearly defined* tag 
should be used. Something along the lines of 'original building use".


Frederik suggests "Everyone may be confused about this.". It's been 
evident for years that those who are perplexed are the ones who imagined 
a 'typology'. I believe they've based their assumptions on anecdotal 
observations around their own neighbourhoods. OSM is global.


DaveF

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


Re: [Tagging] phone vs contact:phone

2019-08-26 Thread Dave F via Tagging
I've yet to see an argument for collecting all under the 'contact:*' tag 
that bears scrutiny .


The "group them without having to keep a hardcoded list" falls down as 
they have to be split into separate variables to make sense of them.


DaveF

On 25/08/2019 20:48, marc marc wrote:

Le 25.08.19 à 16:55, Martin Koppenhoefer a écrit :

What about deprecating the contact: prefix, at least for phone?

not "AT LEAST FOR" that's the main issue !

having some contact with contact: prefix and some other without
is a very bad idea.
we need to switch all contact to key with contact: prefix
(pro : a datauser is able to group them without havng to keep
a hardcoded list of all key (phone, fax, email, web, social network )
and update to list everytime one user add a new contact)
OR
we need to forget this idea of grouping all contacts
(ironic pro : we tag for the database, not to have easy to use data)
___
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] Keys to which new values can be added without a proposal

2019-08-15 Thread Dave F via Tagging

On 31/07/2019 08:20, Warin wrote:


"Any tag you like" is one of the OSM mantras.
https://wiki.openstreetmap.org/wiki/Any_tags_you_like


To be clearer it should be "Any tag you like.. to describe something 
different"


If a valid tag is in use - use that.

Cheers
DaveF


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


Re: [Tagging] New property Key:walk-in for amenities like clinics, barbers, hair salons that offer walk-in appointments/service?

2019-08-15 Thread Dave F via Tagging

How about using booking?
https://wiki.openstreetmap.org/wiki/Key%3Abooking

DaveF

On 15/08/2019 03:36, Joseph Eisenberg wrote:

Another user has proposed the Key walk-in=* to specify if an amenity,
like a healthcare facility, sees people on a walk-in basis or not. In
particular it's for medical clinics or doctor's practices.

Suggested values are:

yes - walk-in service is available (appointments might also be available)

no - does not normally serve walk-in patients/customers (appointments required).

only - for clinics (or hair salons, barbers, etc) which only provide
"walk-in" service, and do not offer advance appointments

This looks pretty good to me, unless there is a different term used in
British English?

See https://wiki.openstreetmap.org/wiki/Proposed_features/Key:walk-in

___
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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

2019-07-29 Thread Dave F via Tagging
I believe the main reason isn't (& probably shouldn't) deprecated is 
that it allows entities which are unused but still physically there, to 
be rendered. disused:*=* aren't rendered on the 'standard' render.


Davef

On 29/07/2019 07:23, Joseph Eisenberg wrote:

I was going to fix the status of abandoned=yes which is currently
incorrectly listed as "obsolete". I thought it was probably
deprecated, since the wiki page was deleted when Key:abandoned:*
(namespaced) was made in 2015, but it's still used 40,000 times.

The key disused (mainly disused=yes) is also used 60,000 times, even
though the situation is the same: no wiki page, and the Key:disused:
page suggests it is deprecated.

Should these two be added to deprecated features, or should I recreate
the deleted pages and change the status to something other than
obsolete/deprecated?

I see that there was just a mention added that landuse=quarry plus
disused=yes might be more sensible than disused:landuse=quarry.

Joseph

___
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] Was public_transport=platform intended to always be combined with highway=bus_stop?

2019-07-29 Thread Dave F via Tagging

Hi

This is not a criticism of Joseph.

This post confirms what I've been saying for the past year - PT tags add 
nothing but confusion to OSM, which directly leads to errors.


highway=bus_stop is a completely separate tag to any in the PT schema. 
It was created long before the invention of the PT schema and is the 
original & the most popular, accurate way to map a bus stop.


The PT schema purely duplicates existing, well used, clearly defined 
tags. It adds no extra detail or information.


A platform is a raised physical object compared to the surrounding area 
to aid vehicle boarding. Popular tags such as railway=platform, 
tram=platform are used for such entities.
Public_transport=platform has been hijacked by PT to falsely represent a 
bus stop as an imaginary area on a pavement. As defined in OSM's welcome 
page: "OpenStreetMap is a place for mapping things that are both /real 
and current/ ".


It's hard to ascertain precisely why PT was originally created but it 
appears to be that the existing tags weren't complete. However instead 
of adding that missing data, somebody though it would be a great idea to 
start from the very beginning with a completely new set of tags & try to 
paper over the gaps. The irony is that, after a lot of discussion over 
tag names & locations & quickly waning enthusiasm for adding them to the 
database,  PT is *less* complete than the original data. What a waste of 
time. It's a mess.


Over on the transit forum the PT schema has become so convoluted even 
those who helped create it are baffled. At least one is advocating its 
removal.


It's time for the PT schema to be redacted.

DaveF



On 29/07/2019 15:29, Joseph Eisenberg wrote:

I read up on the rather exhausting history of public transport tagging.

The strange thing is that the approved proposal which introduced
public_transport=* and the current public_transport pages suggest
using bus=yes only for public_transport=stop_position. In contrast,
public_transport=platform doesn't have bus=yes added.

Does this mean that tagging highway=bus_stop on the same node as
public_transport=platform is the approved way to specify that a
certain "platform" is a bus stop?

It certainly looks that way. Does this mean that tagging
public_transport=platform + highway=bus_stop was the tagging that was
intended by the proposal to specify bus stops, and
public_transport=platform + railway=platform for train platforms, etc?

It appears that the proposal specifically said that the existing tags
like highway=bus_stop were not deprecated. Current usage confirms
this: in the past year just as many (or perhaps slightly more?)
highway=bus_stop have been added as a public_transport=platform -
about 350,000 each - though the latter tag also can be used for
railways, trams, etc.

Joseph

___
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] Clashing access tags

2019-07-16 Thread Dave F via Tagging
Even if 'construction' was to be used, it would still cause the same 
confusion to Richard F


On 15/07/2019 20:33, Mateusz Konieczny wrote:

14 Jul 2019, 21:03 by tagging@openstreetmap.org:


Route relations should be aware of tags on ways. access=no can be used in part 
to indicate road works.
Just because a way may be inaccessible to bikes doesn't mean it's not still 
officially regarded as a cycle route (the NCN ref won't be removed)


Probably highway=construction is a better tagging for such case.




___
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] Clashing access tags

2019-07-14 Thread Dave F via Tagging

On 14/07/2019 13:07, Richard Fairhurst wrote:

Hi all,

Occasionally I encounter tag combinations like this:

bicycle=designated
highway=proposed

(from https://www.openstreetmap.org/way/335831004)

where the "bikes can ride along here" of the first tag is contradicted 
by the "this hasn't even been built yet" of the second.


No. it doesn't. Highway is the primary tag. It usurps sub-tags which are 
merely adjectives of the primary.

When it has been completed it will be designated for use by bicycles.



Similarly, on occasion I've found ways which are tagged access=no 
("nothing is allowed along here") but are part of a bike route 
relation ("bikes can ride along here").


Route relations should be aware of tags on ways. access=no can be used 
in part to indicate road works.
Just because a way may be inaccessible to bikes doesn't mean it's not 
still officially regarded as a cycle route (the NCN ref won't be removed)


DaveF

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


Re: [Tagging] Removing an ATM

2019-07-09 Thread Dave F via Tagging

On 09/07/2019 14:04, MARLIN LUKE wrote:

Hi,

I've read in the wiki (and on this list) that it's best to avoid loosing 
history.


This refers to the edit history of an object ie How many times it's been 
amended, by whom, & what got changed.



I have an ATM mapped in a street which does not exist anymore (apparently since 
2014).

Should I:

-Remove the point altogether and lose the history?


Yes.
From: https://www.openstreetmap.org/welcome

"OpenStreetMap is a place for mapping things that are both /real and 
current"/


If it doesn't exist in the real world then it shouldn't exist in OSM.

Even after you remove it the database still has a record of it's existence.

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


Re: [Tagging] JOSM's "suspicious" path data warnings

2019-07-06 Thread Dave F via Tagging

On 06/07/2019 14:08, Andy Townsend wrote:
Where any editor gives incorrect suggestions I'd suggest raising a 
ticket with the editor concerned about it.  I've done that a couple of 
times in the past with JOSM and the issues have been resolved almost 
immediately.


Obviously it helps to provide a bit of background as to why and in 
what circumstances a particular suggestion is incorrect.


I agree, but I wanted to check with a wider audience that I haven't 
grabbed the wrong end of the stick. I'm more than happy to be proved wrong.


Plus you don't always get a *balanced* viewpoint from those who directly 
wrote the code.  iD 


DaveF



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


  1   2   >