Dan, I'm not being dogmatic, I'm being practical. If a data consumer needs to edit the data rather than incorporate the options into their data handling stream they are making their process vulnerable to anyone's edits. If Stuart edits access:psv=* to psv=* his process will work, until someone adds the next access:psv=* or until someone who expects to see the access:psv tag and reverts Stuart's edit. If he deals with both there will be no problem at all.

If you import into a database, you could process the tags during the load (that's what people use lua for when importing the data for rendering) or you could change the SQL you use. If you don't use a database, the tag selection needs to managed by a list rather than a single key. Anyone working with soft data would expect this kind of thing.

As to the edit, I would always support the data being edited. If you want to change psv=No to psv=no, that's fine and useful, but changing one perfectly acceptable tagging scheme to another one to make a data consumer's job very slightly easier seems like a very poor reason for such an edit. It sets a terrible precedent.

Cheers, Chris (chillly)

On 13/10/16 18:15, Dan S wrote:
Chris, I think that's a bit too dogmatic, if you don't mind me saying.
It seems to imply nothing should ever be tweaked, e.g. spelling
mistakes. It's entirely possible that the key in question was a simple
misremember rather than a deliberate choice. There have been many
larger mechanical edits applied, officiated by the imports list I
think. Or one could check with the mapper(s) who did the tagging in


2016-10-13 18:00 GMT+01:00 Chris Hill <o...@raggedred.net>:
There are not an infinite number of ways to tag things. In order to edit the
tags you think need changing, you have to find them. So instead of editing
them just add the tag to your list of accepted tags. If you edit you have to
re-download the extract of the OSM data, if you simply update your list of
tags then just run your code again.

If you edit tags as you describe that is a mechanical edit and I would
insist it is reverted.

Cheers, Chris (chillly)

On 13 October 2016 17:53:11 BST, Stuart Reynolds
<stu...@travelinesoutheast.org.uk> wrote:

For sure! But there are an infinite number of tagging schemes that any
individual mapper could choose to use. I can’t realistically be expected to
get my contractor to implement a revised import every time someone dreams
one up. That’s why I went back to the Wiki to see what it said there, as it
is to some extent the tagging bible, and it is quite clear that it should be
psv=*. That and the fact that there are only 275 worldwide rather suggests
that it is not an accepted tagging scheme.


Stuart Reynolds
for traveline south east & anglia

m: +44 7788 106165
skype: stuartjreynolds

On 13 Oct 2016, at 17:38, Chris Hill <o...@raggedred.net> wrote:

Please don't change the tags to suit your application. If every data
consumer changed the tags they don't like it would be mayhem. If you edit
tags and by doing that you upset a single mapper, that is a disaster -
mappers are our most precious resource.

Change your processing to include both types of tagging. It is not hard to
do, you write the code once and use it whenever you need to in the future.

Cheers, Chris (chillly)

On 13 October 2016 17:12:21 BST, Stuart Reynolds
<stu...@travelinesoutheast.org.uk> wrote:
Greetings all!

In Nottingham in particular there are a number of roads marked with
access:psv tags. This is unusual, in that I would normally expect to see
simply psv=* on these roads - and more importantly (to me) so would my
contractor who is importing the data. I’ve checked the wiki for “access” and
it seems to agree with the contractor that psv=* is the preferred tagging

There are only 275 instances of access:psv worldwide, and I propose to
change those (manually) in the areas that I am concerned about in the UK.
This is just to let you know, in case anyone has any violent objections or
wonders what I am up to.

Stuart Reynolds
for traveline south east & anglia


Talk-GB mailing list

Talk-GB mailing list

Reply via email to