Brian,
Do you mean the Brompton Dock? Its not a Borris bike btw. There is also a dock
due in at New Street.
Cheers
Andy
From: Brian Prangle [mailto:br...@mappa-mercia.org]
Sent: 05 October 2014 11:52
To: OSM Group WM
Subject: [Talk-gb-westmidlands] Birmingham Bike Hire pods
Hi
On 05/10/14 09:49, Lester Caine wrote:
there
should be a block on the deleted element being removed until the
'damage' is repaired. Something that JOSM at least tries to help with,
but iD ignores?
Where the damage is the breaking of a relation, iD is not ignoring it,
it is actively but
On Sun, 05 Oct 2014 00:35:20 +0100
David Woolley for...@david-woolley.me.uk wrote:
I think iD has taken totally the wrong approach. If the concept is
too difficult for the target audience, it should have refused the
operation, rather than hidden the problem.
Simply refusing to delete seems
On 05/10/2014 10:47, David Woolley wrote:
A classic example is NaPTAN stop data, where the rule for one that
has gone away is to invalidate the bus stop tag and add
physically_present=no, but leave the node present. I think I've seen
cases where a stop being moved has triggered an delete/add
On 05/10/14 11:27, Spike wrote:
On 05/10/2014 10:47, David Woolley wrote:
A classic example is NaPTAN stop data, where the rule for one that has
gone away is to invalidate the bus stop tag and add
physically_present=no, but leave the node present. I think I've seen
cases where a stop being
2014-10-05 12:11 GMT+01:00 David Woolley for...@david-woolley.me.uk:
On 05/10/14 11:27, Spike wrote:
On 05/10/2014 10:47, David Woolley wrote:
A classic example is NaPTAN stop data, where the rule for one that has
gone away is to invalidate the bus stop tag and add
physically_present=no,
On 5 October 2014 12:11, David Woolley for...@david-woolley.me.uk wrote:
Could I ask please the logic behind retaining references to a stop that
does not exist?
In rural area there are places that buses stop but no physical stop. And in
Malvern there are examples of where this only a physical
On 05/10/14 11:25, Andy Street wrote:
Simply refusing to delete seems rather unhelpful. I'd much prefer
the user to be presented with a dialog box that explains the problem in
simple terms before allowing them to either continue with the delete or
seek assistance. If the user requires assistance
On 05/10/14 11:25, Andy Street wrote:
I think iD has taken totally the wrong approach. If the concept is
too difficult for the target audience, it should have refused the
operation, rather than hidden the problem.
Simply refusing to delete seems rather unhelpful. I'd much prefer
the user
On Sun, 05 Oct 2014 12:47:29 +0100
David Woolley for...@david-woolley.me.uk wrote:
Newbies will tend to do what is necessary to suppress the error
message, without thinking what they are doing. Alternatively, they
will reject the editor as one of the big problem with creating dumbed
down
I am trying to think how to reduce incidents that would cause alarm to users
like me, but there is no point in flagging new editors because it won’t help
them integrate into OSM.
I am not an expert in iD since I moved on from Potlatch, but Potlatch at least
denotes relations on ways, while iD
This is digressing somewhat into a discussion about NaPTAN but before I get
into that point, if I can just pick up on the comment about leaving things in
because it shows a history of what the data looked like. Sorry, but OSM IS a
dynamic data set and doesn't AFAIK have the facility to keep a
That should have been DfT in my last sentence. Curse autocorrect!
Sent from my iPhone
On 5 Oct 2014, at 18:00, Stuart Reynolds
stu...@travelinesoutheast.org.ukmailto:stu...@travelinesoutheast.org.uk
wrote:
This is digressing somewhat into a discussion about NaPTAN but before I get
into that
On 05/10/14 17:58, Stuart Reynolds wrote:
On NaPTAN, deleted stops are those that have been removed and should
correspondingly be removed from OSM
If that is the new policy, you should change
On 05/10/14 18:20, David Woolley wrote:
On 05/10/14 17:58, Stuart Reynolds wrote:
On NaPTAN, deleted stops are those that have been removed and should
correspondingly be removed from OSM
If that is the new policy, you should change
That's my view as someone who is closely involved with NaPTAN. I don't know
what official OSM policy is-I'm just saying what it ought to be
Regards
Stuart
Sent from my iPhone
On 5 Oct 2014, at 18:20, David Woolley for...@david-woolley.me.uk wrote:
On 05/10/14 17:58, Stuart Reynolds wrote:
On 05/10/14 17:58, Stuart Reynolds wrote:
This is digressing somewhat into a discussion about NaPTAN but before I
get into that point, if I can just pick up on the comment about leaving
things in because it shows a history of what the data looked like.
Sorry, but OSM IS a dynamic data set and
On 05/10/14 21:00, Lester Caine wrote:
and
historic material would have an end date set which the renderers would
also respect. A view of the data with any out of scope material
suppressed is easy to implement, but at present we still don't have a
reliable method of archiving material even if
On 05/10/14 14:11, Lester Caine wrote:
Which sort of ties in with my constraints on relations.
If an edit is breaking something it's easy enough to say unable to
proceed because ... but ideally the API should be able to find a new
missing bit and add it into the relation? Only blocking
On 05/10/14 21:43, David Woolley wrote:
On 05/10/14 14:11, Lester Caine wrote:
Which sort of ties in with my constraints on relations.
If an edit is breaking something it's easy enough to say unable to
proceed because ... but ideally the API should be able to find a new
missing bit and add
With new editors though I sometimes think we forget how hard it is for
someone to start editing now in e.g. the centre of London compared to
when we experienced mappers started. Here, for example (courtesy of
Martijn Van Exel's OSM Then and Now) is what the area I started
mapping in looked
21 matches
Mail list logo
