Sorry I'm forgetting to keep the mailing list informed, so this is rather
last-minute if you missed it on twitter/wiki but...
TONIGHT we're in the Angel pub from 7pm
It's near Angel tube. Here on the map: http://osm.org/go/euu45JLI?m=
The Angel pub is quite big but all on one floor. Hopefully
I wonder the reason for the increase in users/edits around April '16?
On 13/10/2016 15:01, Bob wrote:
Though it doesn't necessarily mean much osm is now over 3 million
registered users and has 40,000 contributers last month
Dave, yes - sorry. Mistyped what I had been sent. It is only 127, two of which
are one single instance of access:psv:bus, which surely ought to be just bus=*,
and one single instance of access:psv:maxweight
Chris - I will quite happily build in different tagging schemes if I feel that
I'm only returning 127 (Worldwide) & 29 (UK, 24 Nottingham)
Compared with 77857 for psv=*
If they're to signify different entries, what are those differences.
If they're for the same entity what is the advantage of access:psv. If
there is none, they should be change as clearly more
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
Stuart, You explained your idea (thanks for emailing first) and you
added 'in case anyone has any violent objections'. I voiced my
objection. I'm not in charge nor am I the OSM Police, you should proceed
as you see fit and so will I.
I have written about this process more than once in the
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
Most of Chris's blog appears irrelevant to this case. The
cemetery/graveyard example isn't applicable.
There's no "variations", "differences" or "flattening out the data into
a monotonous grey".
If you have 2 tags: X1 & X2 that represent the same object, & the data
user checks for both
I agree with what Chris says.
I continue mapping with the tagging scheme I use until someone messages me
as a discussion. By ignoring current usage (regarded with more reverence
than the wiki) your consumption will potentially miss new data that mapper
adds, they will likely be unaware of your
On 13-Oct-16 18:51, Chris Hill wrote:
I have written about this process more than once in the past, for
I agree with this... any formal tagging schema is going to end up
obstructing useful mapping of circumstances
Putting "access:" in front of psv is a documented approach as set out in
the Conditional Restrictions wiki page . This is designed to create a
hierarchy from simple restrictions (e.g. access:psv=yes, often shortened to
psv=yes) to the more complex. Proceeding with "access:" follows the
On 14-Oct-16 05:22 AM, Gregory wrote:
I agree with what Chris says.
I continue mapping with the tagging scheme I use until someone
messages me as a discussion. By ignoring current usage (regarded with
more reverence than the wiki) your consumption will potentially miss
new data that mapper
On 11/10/2016 12:36, John Aldridge wrote:
In most cases that involves filling in addr:postcode and fhrs:id on
existing OSM features. I'm not, however, trusting that the postcode
recorded on FHRS is accurate, and I'm not setting addr:postcode unless
I can find corroborating information (e.g.
Though it doesn't necessarily mean much osm is now over 3 million registered
users and has 40,000 contributers last month
Talk-GB mailing list
Mail list logo