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
Stuart,
Putting "access:" in front of psv is a documented approach as set out in
the Conditional Restrictions wiki page [1]. 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
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
example
http://chris-osm.blogspot.co.uk/2012/01/homogenised-data-no-thanks.html
I agree with this... any formal tagging schema is going to end up
obstructing useful mapping of circumstances
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
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
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
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
Stuart
I'm only returning 127 (Worldwide) & 29 (UK, 24 Nottingham)
Compared with 77857 for psv=*
Chris
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
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
That's interesting.
I wonder the reason for the increase in users/edits around April '16?
Dave F.
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
http://osmstats.neis-one.org/
Though it doesn't necessarily mean much osm is now over 3 million registered
users and has 40,000 contributers last month
http://osmstats.neis-one.org/___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
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.
14 matches
Mail list logo
