Re: [Talk-gb-london] Thu 22nd Feb - Pedestrian Infrastructure Mapathon

2024-02-22 Thread Robert Skedgell

On 21/02/2024 19:58, Harry Wood wrote:

Tomorrow night (Thursday 22nd Feb) Meta are hosting a "Pedestrian Infrastructure 
Mapathon" 18:00 - 20:00 pm.

"The Open Maps Team at Meta is partnering with local citizens to improve map data 
for pedestrian infrastructure in London ... learn how to increase the accuracy and detail 
of pedestrian infrastructure data in OpenStreetMap."

It's hosted at their offices, and involves bringing a laptop along.

All the details and to sign up:
https://docs.google.com/forms/d/e/1FAIpQLSfnfeevCxOxzm0_ageO_Jz09BZRBViaHb0oxAiOQ79tJdPR8w/alreadyresponded

I hope to make it along myself. I also hope to get around to organising the 
next pub meet-up soon! See the wiki for this and all other events 
https://wiki.openstreetmap.org/wiki/London#Upcoming_Events  and follow us on 
mastodon: https://en.osm.town/@OSMLondon



It's a pity this was at such short notice, as I can't get to this one. 
I've added my details for any future events.


I've noticed a few recent-ish pedestrian edits around the City by Meta's 
mappers (VLD* accounts) which looked quite good.


They're certainly more use for pedestrian navigation than the kilometres 
of decorative sidewalk than we have out in the suburbs (quickly mapped 
for the renderer, usually without crossings).


Hopefully I'll manage to get to one of your pub meet-ups as well.

--
Robert Skedgell (rskedgell)


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] TfL Cycle Infrastructure Database (CID) conflation

2023-10-17 Thread Robert Skedgell

OSM's cycling infra is very well mapped, but no thanks to TfL.

@MacLondon usually adds anything new to the map as soon as it opens.

On 17/10/2023 16:21, David via Talk-gb-london wrote:

Interesting.
I would have thought that the overall quality of cycle route mapping on 
OSM for London is actually rather high,
inspite of TfL - it's certainly orders of magnitude better than TfL's 
own maps, which seem relentless riddled with strange errors.


On Tue, Oct 17, 2023 at 4:11 PM Robert Skedgell <mailto:r...@hubris.org.uk>> wrote:


TfL have recently posted this on Facebook:

"Google has improved its cycle routes in Google Maps 
New updates now consider traffic conditions and the availability of
Cycleways to prioritise cycling on safer, quieter roads.
These changes are being rolled out to all users by the end of the year."


https://www.facebook.com/transportforlondon/posts/pfbid02Po1PXVgVgE4Fbm7zkPUPp4fnq9kkgJfnsNAKbRzMYtTqVviZAevFn34JYAXrXJzVl
 
<https://www.facebook.com/transportforlondon/posts/pfbid02Po1PXVgVgE4Fbm7zkPUPp4fnq9kkgJfnsNAKbRzMYtTqVviZAevFn34JYAXrXJzVl>

I think that's an indirect admission by TfL that the work done on
OpenStreetMap by TfL's paid "mappers" was an embarrassing failure. Some
of the conflation done by the contractors was quite poor, but most
of it
was of much lower quality and should have been reverted.

On 10/08/2023 16:57, Robert Skedgell wrote:
 > As the project was quietly abandoned in January 2023, is it time
for a
 > post mortem of this incomplete project?
 >
 > On 15/11/2022 12:01, Whittaker, Ed via Talk-gb-london wrote:
 >> Hello
 >>
 >> Following very helpful feedback earlier in the year, we are now
 >> looking to recommence efforts to complete the migration of the
TfL CID
 >> to OSM
 >>
 >> We will keep an eye on this board, but suggest (and welcome!)
feedback
 >> to the main post on the talk-gb board
 >>
(https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html 
<https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html>)
 >>
 >> Thanks,
 >>
 >> Ed (Sweco), Aidan (GHD) and Lu (GHD
 >>
 >>
 >> Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England
and Wales)
 >> Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate
 >> Drive, Leeds, LS7 4DN
 >
 >
 > ___
 > Talk-gb-london mailing list
 > Talk-gb-london@openstreetmap.org
<mailto:Talk-gb-london@openstreetmap.org>
 > https://lists.openstreetmap.org/listinfo/talk-gb-london
<https://lists.openstreetmap.org/listinfo/talk-gb-london>


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
<mailto:Talk-gb-london@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-gb-london
<https://lists.openstreetmap.org/listinfo/talk-gb-london>


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] TfL Cycle Infrastructure Database (CID) conflation

2023-10-17 Thread Robert Skedgell

TfL have recently posted this on Facebook:

"Google has improved its cycle routes in Google Maps 
New updates now consider traffic conditions and the availability of 
Cycleways to prioritise cycling on safer, quieter roads.

These changes are being rolled out to all users by the end of the year."

https://www.facebook.com/transportforlondon/posts/pfbid02Po1PXVgVgE4Fbm7zkPUPp4fnq9kkgJfnsNAKbRzMYtTqVviZAevFn34JYAXrXJzVl

I think that's an indirect admission by TfL that the work done on 
OpenStreetMap by TfL's paid "mappers" was an embarrassing failure. Some 
of the conflation done by the contractors was quite poor, but most of it 
was of much lower quality and should have been reverted.


On 10/08/2023 16:57, Robert Skedgell wrote:
As the project was quietly abandoned in January 2023, is it time for a 
post mortem of this incomplete project?


On 15/11/2022 12:01, Whittaker, Ed via Talk-gb-london wrote:

Hello

Following very helpful feedback earlier in the year, we are now 
looking to recommence efforts to complete the migration of the TfL CID 
to OSM


We will keep an eye on this board, but suggest (and welcome!) feedback 
to the main post on the talk-gb board 
(https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html)


Thanks,

Ed (Sweco), Aidan (GHD) and Lu (GHD


Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England and Wales)
Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate 
Drive, Leeds, LS7 4DN



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] Millennium Bridge temp closure

2023-10-12 Thread Robert Skedgell

You could use a conditional restriction, perhaps something like

foot:conditional=no @ 2023 Oct 14-2023 Nov 05
Wheelchair:conditional=no @ 2023 Oct 14-2023 Nov 05

https://wiki.openstreetmap.org/wiki/Conditional_restrictions

On 12/10/2023 11:20, Matthew Scanlon wrote:

Hi

The Millennium Bridge will be closed from Saturday 14 October 2023 until 
Sunday 5 November 2023, is there a way of adding a temporary block on 
OSM to prevent planning tools that use OSM for routing users this way?


Thanks

Matthew

*Matthew Scanlon*
*Service Analyst (Journey Planner)***

*Technology Service Operations *

*Viewpoint Champion for PS*

*Transport for London*| 6G6 6^th Floor 14 Pier Walk

Please note I am normally in the office on Wednesday and Thursday



This message has been scanned for malware by Forcepoint. 
www.forcepoint.com 



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] TfL Cycle Infrastructure Database (CID) conflation

2023-08-10 Thread Robert Skedgell
As the project was quietly abandoned in January 2023, is it time for a 
post mortem of this incomplete project?


On 15/11/2022 12:01, Whittaker, Ed via Talk-gb-london wrote:

Hello

Following very helpful feedback earlier in the year, we are now looking to 
recommence efforts to complete the migration of the TfL CID to OSM

We will keep an eye on this board, but suggest (and welcome!) feedback to the 
main post on the talk-gb board 
(https://lists.openstreetmap.org/pipermail/talk-gb/2022-November/029610.html)

Thanks,

Ed (Sweco), Aidan (GHD) and Lu (GHD


Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England and Wales)
Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate Drive, Leeds, 
LS7 4DN



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] Tube exits

2023-04-07 Thread Robert Skedgell

On 07/04/2023 10:08, Bjoern Hassler wrote:

Hello everyone and happy long weekend!

I'd like to launch a campaign to collect accurate London tube exit 
information and how to get there from the platform. The exits are 
typically already in OSM, but often they are only labelled partially.
I do think that features (such as exits and platforms) should be 
labelled by what is visible on the platform. Sure, station codes can be 
included as well, but for the user, at least some of the label has to 
correspond to what they see at that location.


Could we get broad agreement on how to label tube exits and (ideally) 
what should be included in the description?


For example, this node: https://www.openstreetmap.org/node/5109686507 
. It was previously 
called Algate East, which is correct, but not specific. I've labelled 
this now as "Aldgate East, Exit 1". However, at the station, the exit is 
actually labelled  "Exit 1. High Street (south side), Leman Street, 
Conference forum." I do think that including the station name is good 
for searching, and I do not think it will confuse users.


*Proposal. *London tube exits should be labeled by station name plus the 
actual exit label (where available), i.e., exit name on OSM would be: 
"Aldgate East, Exit 1. High Street (south side), Leman Street, 
Conference forum."


This label would work for people travelling from the platform to 
the exits (as they'll see the sign). Because the sign includes 
landmarks, this lable would also make sense for people entering the station.


How do people feel about this proposal? Would this be acceptable? Any views?

Many thanks!
Björn


We already have a documented tagging scheme for railway=subway_entrance, 
which seems to have been more or less stable for quite a long time (~10 
years). This is what data consumers like pedestrian routing software 
will presumably use and having non-standard tagging for London 
Underground could cause problems.


name	Name of the exit if is known. Not the name of the station (use the 
public_transport=stop_area relation instead to link with the station). 
This doesn't include the reference either.


ref	Reference of the entrance if it has one. Some subway networks use 
numbers or codes to identify exits, e.g. "2" or "B1".


https://wiki.openstreetmap.org/wiki/Tag:railway%3Dsubway_entrance

For that exit from Aldgate East, it should have name="High Street (south 
side), Leman Street, Conference forum" and ref=1.


The exit already inherits the station name by being a member of Aldgate 
East's public_transport=stop_area relation.

https://www.openstreetmap.org/relation/7218599

I realise that it doesn't help much that the four entrances which are 
members of that relation were incorrectly tagged 5 years ago with 
name="Aldgate East" (understandable) and ref=* values of A,B,C and F 
(which seem very odd). This is clearly useless for routing, but luckily 
for me CityMapper gets its station information from somewhere else.


In OSM Carto, the icon for railway=subway_entrance is rendered at zoom 
18 and the value of the ref=* tag is added at zoom 19. Changing the 
value of the name=* tag may not result in anything different being 
rendered, unless you can persuade the maintainers to change it. None of 
the other common tile layers I've looked at appear to render any text at 
all, even if they display an icon.


https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/stations.mss


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


[Talk-gb-london] #waymap-project-SB cycleway vandalism

2023-01-18 Thread Robert Skedgell
I had previously thought that @alisonlung's #waymap-project-SB edits 
were no worse than just a few decorative sidewalks, with some slightly 
irritating footway routing as a result.


Unfortunately, I was wrong.

I hadn't noticed what looks like real, and frankly quite nasty, 
vandalism by @alisonlung. They changed the cycleways forming cycle route 
LCN39 around Holland Park Roundabout to footways, with the result that 
some routers use the roundabout itself (I've done that and it's not fun).


Looking at the changeset where I've (hopefully) fixed this in OSMCha 
will give an idea of what was done.

https://osmcha.org/changesets/131431567/

I hate to think what else I'll find.

--
Robert Skedgell (rskedgell)

___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] [Talk-GB] Separate sidewalks added by #waymap-project-SB in West London

2023-01-17 Thread Robert Skedgell
I am not against mapping separate sidewalks and have added quite a few 
of them on main roads where they're generally helpful for routing and 
accessibility. I've also added them in some newer residential 
developments which have been designed to be pedestrian-friendly, with 
lots of tactile paving, kerb adaptations etc.


My general test for whether it is worth mapping a separate sidewalk is: 
if I were planning a run, would this help?


With sidewalks on residential streets added by a local mapper, I'll 
survey and add crossings and wouldn't consider deleting them without 
discussion.


These, on the other hand, have been added as part of a nebulous project, 
mostly by a mapper who has not responded to changeset comments by other 
users, and who may be mapping from an armchair in the USA.


I walked down Shepherds Bush Road yesterday afternoon and used 
StreetComplete to update sidewalks and crossings. I feel that was worth 
the effort for routing and accessibility (and there was a pint at the 
end). I don't propose to walk around the surrounding residential streets 
to add crossings.


On 17/01/2023 10:02, Steven Hirschorn wrote:
I raised this once before on this list and didn't feel the response was 
very positive so left all the sidewalk mapping - in my case it came onto 
my radar in Acton.
It seems pointless mapping pavements on little residential streets 
because the default expectation is a pavement on either side.
Like you say, it can negatively impact routing if the sidewalks aren't 
joined to the roads at regular intervals, so it's easy to get wrong.
There's a justification for mapping sidewalks in some circumstances. The 
thread is here:

https://lists.openstreetmap.org/pipermail/talk-gb/2021-October/027947.html 
<https://lists.openstreetmap.org/pipermail/talk-gb/2021-October/027947.html>

On Tue, 17 Jan 2023, 08:56 Robert Skedgell, <mailto:r...@hubris.org.uk>> wrote:


We have had a large number of separate sidewalks added around Shepherds
Bush, mostly by user alisonlung (possibly based in the USA) with some
contributions by ABullock with the hashtag #waymap-project-SB

I have several problems with this:
- there seems to be no documentation or explanation of this organised
editing project (or I'm looking in the wrong place)
- alisonlung has consistently ignored changeset comments from other
users
- the sidewalks were frequently decorative: they may look pretty on OSM
Carto, but often provide no or negative benefit for pedestrian routing
- some sidewalks were added with layer=-1, strongly suggesting that the
mapper(s) had no idea what the tag means
- some cycleways around Shepherds Bush Green were changed to footways
without adding bicycle=yes, which I consider to be vandalism

I have tried to fix some of these, but the volume and the amount of
fiddly realignment required seems disproportionate.

I propose to do the following:
- retain and repair sidewalks on main roads
(trunk/primary/secondary/tertiary) where there are defined crossing
points, or where there is a clear benefit to pedestrian routing
- delete most sidewalks added by these users on residential streets,
leaving crossings as nodes on the highway




___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] Separate sidewalks added by #waymap-project-SB in West London

2023-01-17 Thread Robert Skedgell
I am also very much in favour of adding separate sidewalks where there 
is a benefit for pedestrian routing or accessibility. I have added quite 
a few of them, mostly on main roads.


Where they can be less useful, even when done properly, is on long 
residential streets without formal crossing points or even connections 
with driveways and alleys. These can produce some rather "scenic" routes.


On 17/01/2023 09:18, David Davis wrote:
I am generally in favour of explicit drawing of pavements and pedestrian 
crossing points where possible,
but it does sound from your description that this user's enthusiasm has 
somewhat over-reached their skillz ;)


If possible though, an effort should be made to explain and educate them 
as to what technicalities they are getting wrong,

so they can direct their considerable energies more productively :)

On Tue, Jan 17, 2023 at 8:57 AM Robert Skedgell <mailto:r...@hubris.org.uk>> wrote:


We have had a large number of separate sidewalks added around Shepherds
Bush, mostly by user alisonlung (possibly based in the USA) with some
contributions by ABullock with the hashtag #waymap-project-SB

I have several problems with this:
- there seems to be no documentation or explanation of this organised
editing project (or I'm looking in the wrong place)
- alisonlung has consistently ignored changeset comments from other
users
- the sidewalks were frequently decorative: they may look pretty on OSM
Carto, but often provide no or negative benefit for pedestrian routing
- some sidewalks were added with layer=-1, strongly suggesting that the
mapper(s) had no idea what the tag means
- some cycleways around Shepherds Bush Green were changed to footways
without adding bicycle=yes, which I consider to be vandalism

I have tried to fix some of these, but the volume and the amount of
fiddly realignment required seems disproportionate.

I propose to do the following:
- retain and repair sidewalks on main roads
(trunk/primary/secondary/tertiary) where there are defined crossing
points, or where there is a clear benefit to pedestrian routing
- delete most sidewalks added by these users on residential streets,
leaving crossings as nodes on the highway

-- 
Robert Skedgell (rskedgell)





___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


[Talk-gb-london] Separate sidewalks added by #waymap-project-SB in West London

2023-01-17 Thread Robert Skedgell
We have had a large number of separate sidewalks added around Shepherds 
Bush, mostly by user alisonlung (possibly based in the USA) with some 
contributions by ABullock with the hashtag #waymap-project-SB


I have several problems with this:
- there seems to be no documentation or explanation of this organised 
editing project (or I'm looking in the wrong place)

- alisonlung has consistently ignored changeset comments from other users
- the sidewalks were frequently decorative: they may look pretty on OSM 
Carto, but often provide no or negative benefit for pedestrian routing
- some sidewalks were added with layer=-1, strongly suggesting that the 
mapper(s) had no idea what the tag means
- some cycleways around Shepherds Bush Green were changed to footways 
without adding bicycle=yes, which I consider to be vandalism


I have tried to fix some of these, but the volume and the amount of 
fiddly realignment required seems disproportionate.


I propose to do the following:
- retain and repair sidewalks on main roads 
(trunk/primary/secondary/tertiary) where there are defined crossing 
points, or where there is a clear benefit to pedestrian routing
- delete most sidewalks added by these users on residential streets, 
leaving crossings as nodes on the highway


--
Robert Skedgell (rskedgell)

___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] [Talk-GB] Is TfL data allowed on OSM?

2022-06-30 Thread Robert Skedgell

Hi Andy,

Many thanks for taking the time to look into this.

So far, the following are my concerns with the TfLCID import:

1) Community "engagement" with talk-gb-london appears to operate in 
write-only mode. Ed Whittaker from TfL's contractor Sweco has posted 
twice (13/05/2022 and 14/06/2022), but has not responded beyond that. 
Comments on the Github issue tracker were also invited, but pointless 
without replies from the import team.

https://github.com/cyclestreets/tflcid-conversion/issues/40

2) The changeset comments do not make it clear that this is part of an 
organised edit or import.


3) The TfLCID data set includes links to two photographs (PHOTO1_URL and 
PHOTO2_URL) taken by TfL's surveyors. There is no excuse to add a 
barrier=yes with access tags when examining the photographs would allow 
a meaningful value for barrier=*. If the photographs have not been 
checked, I cannot trust the access tags. These probably need to be 
removed ASAP.


4) Most, if not all of Greater London has good quality Bing aerial 
imagery available, which is more recent than TfL's surveys. I do not 
believe that this is being checked.


4) The data also includes a survey date field (SVDATE), which might 
usefully have been imported as check_date=* for comparison with more 
recent imagery and use by (e.g.) StreetComplete.


5) Importing TfL's unique asset ID might have been useful. Where I have 
matched assets with imagery (mostly in Newham), I have used 
ref:GB:tflcid=*. The URLs of the asset photographs can be derived from 
these IDs, which could perhaps be useful for navigation apps.


6) cycleway:(left|right|both) tags have been added to highway=* ways 
which conflict with existing tags added my mappers who may actually have 
surveyed the location more recently than TfL's surveyors.


7) Adding cycleway:*=share_busway to a highway=* way where no bus lanes 
are mapped might suggest that there's a problem, particularly if it has 
lanes=2, no oneway=yes tag, and consequently no room for a bus lane to 
share.


8) The data for cycle lanes distinguishes between advisory cycle lanes 
(CLT_ADVIS) and mandatory lanes (CLT_MANDAT). Recent changes on 
enforcement of the prohibition of parking (CCTV allowed since June 2020) 
and driving (TfL from this month) in mandatory lanes make this a more 
useful distinction than it was a couple of years ago.


Looking at Osmose for @AyushS183's edits, there's quite a lot to check...
https://osmose.openstreetmap.fr/en/map/#level=1%2C2%2C3=AyushS183=15=51.51552=0.06029=

I'll continue to use the data in my own edits.

On 30/06/2022 14:08, Andy Townsend wrote:

Hello,

Andy from OSM's Data Working Group here.  We've received a couple of 
complaints about edits that appear to be related to this import, also 
mentioned at 
https://lists.openstreetmap.org/pipermail/imports/2022-June/006878.html 
.  I am assuming that https://www.openstreetmap.org/changeset/122632581 
et al are changes associated with this import, based on the source used 
in the changeset.


Based on that, this work seems to have gone ahead without any attempt to 
follow https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines 
.  Based on what I can read at 
https://resultmaps.neis-one.org/osm-discussion-comments?uid=15976978 , 
the work performed so far also seems to be of very poor quality in that 
it appears to be based on out-of-date information and the people 
performing the work appear to lack the necessary skills to even know 
that they are not using up-to-date information.


I have replied to the "imports" list at 
https://lists.openstreetmap.org/pipermail/imports/2022-June/006896.html 
(including an embarrassing typo - "doesn't seem to be of poor quality" 
instead of "seems to be of poor quality"!) and have asked the organiser 
to engage with the community here, as talk-gb-london is a pretty 
low-volume list and many people with a view on this import will not be 
subscribed to that.


We (the DWG) will take advice from people familiar with the areas 
affected to decide whether a revert of the data imported so far is the 
best way forward.


Best Regards,

Andy (https://www.openstreetmap.org/user/SomeoneElse).

On 17/05/2022 19:17, Berrely wrote:
C/e the announcement on the -gb-london mailing list: 
https://lists.openstreetmap.org/pipermail/talk-gb-london/2022-May/000210.html



On Tue, 17 May 2022 at 18:33, Michael Booth  wrote:

Don't want to say "search before posting" but... :)

I found the following with a search for "talk-gb tfl":
https://lists.openstreetmap.org/pipermail/talk-gb/2019-August/023356.html

which confirms it is an acceptable source.

and more info at:
https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database

On 17/05/2022 18:08, Jon Pennycook via Talk-GB wrote:
> Hello.
>
> I just noticed someone adding barriers and cycle parking with "tfl
> cycle database" as the source.  Is this an acceptable source?  I
> assume it 

Re: [Talk-gb-london] Update on TfL CID conflation plans

2022-06-25 Thread Robert Skedgell

Is @AyushS183 one of yours? Apologies if not.

I'm less than delighted with an import of TfLCID data where in at least 
one location no attempt was made to check the imported data against 
available imagery or infrastructure mapped in OSM.


Chobham Road (w10818748) no longer has cycle lanes on both sides, which 
I have fixed. How many other errors have been blindly imported in recent 
changesets by this user?


https://www.openstreetmap.org/changeset/12263258

On 14/06/2022 17:13, Whittaker, Ed via Talk-gb-london wrote:

Hello,

To keep you updated, a few cosmetic changes have been made to:
https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database

I'd particularly like to draw your attention to the very careful and limited 
plan to use the openstreetmap API. As noted:
- This approach only applies to adjusting tags where they are determined as 
incomplete or incorrect. No geometry changes involved.
- Changes will be manually validated
- The script has been tested in the dev server

We're really keen to get thoughts and feedback to the approach. We will be 
presenting the plan at the geomob session tomorrow (a bit late notice - but it 
would be wonderful if you're able to make it to discuss)
https://thegeomob.com/post/june-15th-2022-geomoblon-details
Thanks,

Ed Whittaker
Senior Transport Planner
Sweco UK Limited | Solihull
Telephone 0121 711 6600
ed.whitta...@sweco.co.uk
www.sweco.co.uk

LinkedIn | Instagram
Reg. No.: 2888385 | Reg. Office: Leeds (Registered in England and Wales)
Reg. Office Address: Sweco UK Limited, Grove House, Mansion Gate Drive, Leeds, 
LS7 4DN
For more information on how Sweco processes your personal data, please read 
here.


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london



___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-gb-london] Conflating TfL CID cycle data to OSM

2022-05-13 Thread Robert Skedgell

On 13/05/2022 16:10, Whittaker, Ed via Talk-gb-london wrote:

Hello everyone,
  
Pleased to let you know that we have been commissioned by TfL to continue the good work of cyclestreets in completing the migration of the CID to OSM. In the first instance, we've updated the associated wiki to give more detail about this renewed effort:

https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database
  
This is just a small introduction - we'll be in touch with updates on the conflation approach. We're very grateful to receive your questions and comments!
  
Lu (GHD), Ed (Sweco) and Aidan (GHD)



Ed Whittaker


Hi,

It's great to see something finally being done with the TfLCID data on a 
larger scale.


I've been manually matching and adding some TfLCID assets within Newham 
as I edit other highway features. So far I've been using the key 
ref:GB:tflcid for TfL's asset ref., but I'm happy to change those if you 
were planning to use another key.


--
Robert Skedgell (rskedgell)


___
Talk-gb-london mailing list
Talk-gb-london@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-london


Re: [Talk-GB] What is needed for something to be classified as a 'cycle route' (London)

2020-12-15 Thread Robert Skedgell
On 15/12/2020 15:06, Simon Still wrote:
> 
> 
>> On 15 Dec 2020, at 14:35, Robert Skedgell > <mailto:r...@hubris.org.uk>> wrote:
>>
>> If 1057 is used on a carriageway
>> rather than on a lane or track, it presumably indicates a route,
>> although TSRGD 2016 does not elaborate upon this - is there an LTN which
>> does?
> 
> Not by any means.  1057’s are the ‘go-to’ way to DO SOMETHING for
> traffic engineers.  
> 
> - Cyclists getting hit by cars at a junction? Paint some 1057s across it
> ‘to alert drivers that there may be cyclists there” (though of course
> drivers should be conscious that there could be cyclists on any road) 
>
> - can’t work out how to get cyclists around a bus stop or parked car?
> Paint a 1057 to indicate road position. >
> OSM Wiki Cycle_routes <https://wiki.openstreetmap.org/wiki/Cycle_routes>

The wording in TSRGD 2016, however is "Cycle lane, track or route". If
it is on the carriageway and is not part of a lane, the assumption would
be that it indicates a route.
https://www.legislation.gov.uk/uksi/2016/362/schedule/11/made#tgp2-tbl2-tbd1-tr28-tc2

Luckily there is further guidance on the use of 1057, which is a bit
more detailed than TSRGD's description.

LTN 1/20 10.5.4 includes "Providing road markings to highlight the
presence of cyclists to other road users, such as cycle symbols to TSRGD
diagram 1057, lines to TSRGD diagram 1010 and advisory cycle lanes, as
well as coloured surfacing". 10.7.35 allows this on the approach to a
mini-roundabout: "Cycle symbols to TSRGD diagram 1057 may be placed in
the primary position to guide cyclists and to alert motorist to their
presence."
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/906344/cycle-infrastructure-design-ltn-1-20.pdf

Chapter 6 of London Cycling Design Standards 6.2.5 includes this:
"Diagram 1057 cycle symbol markings should be selected according to the
width available: usually medium-sized, but small for cycle tracks and
large for ASL boxes. They are used, orientated in the direction of
travel for cyclists, in three distinct and well recognised ways:

• For conspicuity: alerting other road users to expect the presence of
cyclists
• For positioning: suggesting a recommended line of travel for cyclists
• For wayfinding: indicating a route, particularly at a decision point
Any use of this marking should either meet all three functions, or
positioning and conspicuity without an explicit wayfinding function.

The cycle symbol should never be used for
wayfinding where it compromises the positioning
function, particularly at junctions and past parking
and loading bays."
http://content.tfl.gov.uk/lcds-chapter6-signsandmarkings.pdf

You are correct in stating that 1057 outside a lane on a carriageway
does not necessarily indicate a route as I had previously thought.

> "Cycle routes or bicycle route are named or numbered or otherwise
> signed route”

However, if a cycle route in London has 1057 at 150-200m intervals (on
local streets), or 20-30m intervals on a main road route (LCDS fig.
6.2), it's an "otherwise signed" route. It's not a particularly well
signed route and not using 1057.1 for the route number is unhelpful, but
as some CS and Q route numbers appear to be changing to C route numbers
they could be out of date anyway (unless Will Norman changes his mind,
or Shaun Bailey has them all ripped up).

> I would argue that a ‘route’ marked with nothing but 1057 symbols is not
> useful in any way and doesn’t meet that definition 
>
> I have similar issues with London’s Q network - sections of
> un-numbered quietway.  However, these should indicate a certain level of
> service - ie that they meet TfL s quality criteria in terms of traffic
> volumes etc - but also have a point.  Q sections are supposed to be
> feeders for the strategic cycle network of QW and CS routes - ie follow
> a Q and you should soon get to a main, destination signposted, route.
>  (though again, naming and numbering being revised and all routes that
> meet *latest* quality standards will be C numbered)  


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] What is needed for something to be classified as a 'cycle route' (London)

2020-12-15 Thread Robert Skedgell
On 15/12/2020 13:26, Simon Still wrote:
> See discussion on 
> https://www.openstreetmap.org/changeset/95752985#map=18/51.46201/-0.12146=C
> 
> 
> There appear to be a large number of sections of road in some areas of
> London tagged as ‘cycle route’ that are no more than the occasional 1057
> cycle symbol painted on the road.
> 
> They are not signed, and do not have any route numbering.

Some of the LCN/LCN+ routes are signed with blue directional signs, but
often without route numbers.

You would need recent street level imagery or a survey to determine
whether a route really has degraded to only fading TSRGD diagram 1057
signs ("Cycle lane, track or route"). If 1057 is used on a carriageway
rather than on a lane or track, it presumably indicates a route,
although TSRGD 2016 does not elaborate upon this - is there an LTN which
does?

I am not very familiar with the area discussed in the changeset above,
but routes I have used in LB Hackney this summer certainly were.

> 
> Based on the discussion it appears
> - most were added by user MacLondon 
> - they were the ‘lowest level’ of route designation by some councils at
> some time in the past. Pick some ‘useful routes’ on ‘quiet roads’ and
> just paint some symbols on them for people to follow 
> 
> Some of these appear on the last 2015 TfL cycle maps in yellow (routes
> were blue) keyed as ‘other roads recommended by cyclists’ 
>  
> My opinion is
> - these are not followable on the ground 
> - they do not meet TfL or borough quality criteria (and thus do not
> appear on any more recent maps) eg - they are not shown in any way on
> Lambeth councils 2017 cycle
> map 
> https://www.lambeth.gov.uk/parking-transport-and-streets/cycling/lambeth-cycle-routes-map
> 

I wouldn't trust most borough councils here, as the older LCN/LCN+
routes are likely to be the responsibility of TfL/GLA.

> - they decrease legibility of the map because they create a mass of
> dense blue lines from which it’s hard to pick out genuinely useful routes.
> - they probably have a negative impact on routing engines as they are
> likely treated equally to actual signposted routes. 
> - in many cases where they do show the most direct route through
> backstreets that is likely to be the busiest with rat running traffic as
> it’s where google and Waze will send drivers. 

Unless there's a new modal filter as part of a Low Traffic
Neighbourhood, obviously.

> 
> Thoughts?
> 
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] No U-turn on a long stretch of road

2020-12-05 Thread Robert Skedgell
This probably won't help routers much, but you could at least tag the
positions of the signs as nodes on the highway with
traffic_sign=GB:614 + direction=forward|backward

On 05/12/2020 14:27, Edward Bainton wrote:
> Sorry I should have made clear 
> 
> Rather than seeking to capture a subjective jmt in the map, I'm trying
> to capture "no U-turn" signs that are shopping this long stretch, . 
> 
> I agree a driver should use their discretion. Equally where it's
> actually prohibited do we want to capture that?
> 
> On Sat, 5 Dec 2020, 12:57 David Woolley,  > wrote:
> 
> On 05/12/2020 12:39, Edward Bainton wrote:
> > Any established tagging system?
> >
> > The turn restriction wiki
> >  > envisages
> > turn restrictions at junctions only; my case is along the length of a
> > major road (~3km). There's no barrier to prevent it, but presumably
> > routing engines ought to know that route correction after a wrong
> turn
> > will have to wait until the next roundabout.
> >
> 
> That's a subjective judgement, so would be tagging for the renderer.
> The renderer (in this case a router) should be using some sort of
> heuristic like only  permitting U turns on residential or service
> roads,
> and giving a heavy weighting to the use of formal junctions at the the
> expense of distance travelled.  A real human would consider actual
> traffic levels and sight distances but they would be difficult to
> capture on the map and time and season dependent.
> 
> I think No U Turn signs tend only to be used where traffic volumes or
> junction structures, might otherwise suggest U turns were acceptable.
> 
> I don't think any driver (or autonomous vehicle) should be making U
> Turns based solely on the instructions of an automated router.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] UPRN wiki page

2020-11-17 Thread Robert Skedgell
On 17/11/2020 14:53, Cj Malone wrote:
> On Tue, 2020-11-17 at 14:10 +, Jez Nicholson wrote:
>> Whilst i'm here, am I correct that a UPRN can *only* be on a single
>> thing?
>> So anything in
>> https://taginfo.openstreetmap.org/keys/?key=ref%3AGB%3Auprn#values mo
>> re
>> than once is an error?
>>
>> ...or can a road have a USRN *and* a UPRN?
>
> As far as I know a road should have only 1 USRN, but it can have
> multiple UPRNs. I think it's mainly if it goes over a admin boundary,
> each area will have a UPRN but the road will have one USRN.
>
> Also OSM often has multiple ways per road, each of these ways should
> share a USRN and more often than not share the UPRN.

Roads can have more than one USRN. I've come across some sections of
road which appear to have more than one Designated Street Name record
(possibly streets which cross authority boundaries?). In addition to
this, there may be records of types Unofficial Street Name, Officially
Described Street and Numbered Street.

Details of the USRN specification are here
https://www.ordnancesurvey.co.uk/documents/product-support/tech-spec/open-usrn-techspec-v1.1.pdf



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Tagging modal filters and school streets

2020-10-06 Thread Robert Skedgell
Would it be worth adding something like traffic_intervention:website to
link to the relevant traffic order in The Gazette (an OGL source) or the
relevant highway authority's website?

On 27/09/2020 00:53, Stephen Colebourne wrote:
> Here is the outline proposal:
> 
> """
> The traffic_intervention tag is used to identify locations where roads
> have been closed to general traffic for the purpose of preventing
> undesirable through traffic.
> 
> The traffic_calming tag covers many use cases where the road is open
> but something physical has been added to slow down traffic. Sometimes
> however, the local traffic authority goes further and closes a road to
> through traffic - traffic_intervention is used to record these
> interventions. Mappers should ensure that all normal tags are still
> applied to the relevant road segment, traffic_intervention is intended
> to be used in addition to existing tags to capture the semantic
> meaning.
> 
> traffic_intervention=modal_filter
> A modal filter is a road closure that is designed to allow certain
> modes of transport through, typically bicycles and pedestrians. It is
> intended for short sections of road that used to be open to general
> traffic and are no longer. The standard modal filter that allows
> cycles should be mapped as follows:
> * A way representing the section of road that is closed to general traffic:
> highway=cycleway, traffic_intervention=modal_filter, other tags as
> necessary, especially including the road name.
> * A barrier in the middle of the way representing what is being used
> to close the road. For example:
> barrier=bollard, foot=yes, bicycle=yes
> 
> traffic_intervention=bus_gate
> A bus gate is a short section of road that has been closed to general
> traffic but is open to buses, bicycles and pedestrians. It should be
> mapped as a bus road would be, but with the additional
> traffic_intervention tag.
> * A way representing the section of road that is closed to general traffic:
> highway=service, bus=yes, bicycle=yes, foot=yes, traffic_intervention=bus_gate
> 
> traffic_intervention=school_street
> A school street is a section of road near a school that is closed to
> general traffic, often only at certain times of day. The access
> restrictions are normally mapped using motor_vehicle:conditional.
> Simply use traffic_intervention=school_street to add the additional
> semantic meaning.
> 
> Mappers may additionally specify the year, month or full date when the
> road was restricted if known:
> traffic_intervention:date=
> traffic_intervention:date=
> traffic_intervention:date=
> 
> """
> 
> Example modal filter: https://www.openstreetmap.org/way/851872727
> Example bus gate: https://www.openstreetmap.org/way/851872729
> 
> What do people think? Should this be put forward to the tagging list?
> Would anyone here use this scheme?
> 
> Stephen
> 
> 
> 
> On Mon, 21 Sep 2020 at 18:20, Stephen Colebourne  wrote:
>>
>> Given we have hundreds of existing and new modal filters* and school
>> streets**, I think we could do with having a *high level* tag for them
>> that captures the concept.
>>
>> Currently, these are hard to find as they can be represented in many
>> ways. eg. for modal filters:
>> - highway=cycleway
>> - highwat=footway
>> - highway=service/residential with motor_vehicle=no
>> - plus potential associated barrier=xxx
>>
>> School streets are no more than a motor_vehicle:conditional=no @ (xxx)
>> which again loses the semantic meaning.
>>
>> What I'd like is a new tag that captures the high level concept. It
>> would be a bit like traffic_calming, but I don't think that adding
>> more values to that is appropriate. Any new value would go on the way
>> that is no longer open. These are generally verifiable on the ground,
>> even for filters that were added in the 1970s.
>>
>> Unfortunately, I don't have a great name. "traffic_restrictions" is
>> taken as is "traffic_control". My best suggestion is
>> "traffic_intervention=modal_filter"/"school_street", as they are
>> essentially interventions by local government to better manage the
>> street space.
>>
>> Any thoughts?
>> Stephen
>>
>> * a "modal filter" is a place where the road is closed, or made one
>> way for the purposes of controlling traffic, such as to stop rat
>> running. It is commonly linked to Low Traffic Neighbourhoods (LTNs)
>> but they have been around for 50 years, and are generally easy to
>> spot.
>>
>> ** a "school street" is a street that is only accessible by residents
>> at school drop-off and pick-up time
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] How closely do we map lamp posts?

2020-09-03 Thread Robert Skedgell
On 02/09/2020 22:37, Lester Caine wrote:
> On 02/09/2020 19:00, Dave F via Talk-GB wrote:
>> I don't know the area. but they look like the existing posts to me.
>> Has the cycle path been realigned around them to provide better vision
>> splays/ stopping room to motorists?
>>
>> https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656
>>
>> I believe it's something to do with building regs. Existing posts have
>> to be one of the last items to be decommissioned, usually by newly
>> installed ones. Similar happened on one of the London CS ways, where
>> everyone got their knickers in a twist over it.
> 
> The fact that a neatly finished cycleway surface now has to be dug up so
> that the electric supply can be moved to a new location and the lamp
> pole moved is just another example of the complete waste of money many
> of these 'improvements' result in? Actually another question is just why
> the kerb to the footpath and the cycleway had to be moved at all? It no
> longer lines up with the next section anyway.
> 

I see this fairly often. Usually the local council who are responsible
for the highway lay the new cycle lane, but cannot move the lamp posts
as UK Power Networks(?) have to deal with them and the associated cabling.

In Greater London we also have bus stops "left" on cycle tracks at new
bus stop bypasses, until Transport for London's contractors can move them.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Pedestrian priority and highway=cycleway

2020-09-03 Thread Robert Skedgell
If iD really is prompting changing highway=cycleway->highway=footway
without preserving cycle access, we can expect to see cycle routing
becoming badly broken in a lot of places. Some of these edits were made
3 weeks ago and nothing like that appears to have been reported elsewhere.

There also appears to be no justification in the wiki for assuming that
highway=cycleway should not be used where pedestrians have priority,
unless I have missed it. In general, the GB assumption is that
pedestrians have priority on infrastructure shared with cyclists.

Personally, I don't really care whether the top level tag is cycleway or
footway, as long as routing, access and other physical characteristics
are correct.

In any case, my first presumption was carelessness, not malice. Breaking
cycle routing in this part of London is very unhelpful, particularly at
the start of the new school term.

On 03/09/2020 10:39, Tom Hughes wrote:
> I suspect that the real clue is in the changeset tags:
> 
>   resolved:outdated_tags:incomplete_tags=10
> 
> So the iD validator has presumably claimed that the tagging of
> those paths was "out of date" in some way and this was likely a
> misguided attempt to fix that.
> 
> Of course that was likely based on some rule in the validator
> that is trying push whatever daft path tagging the wiki is
> currently trying to promote...
> 
> Certainly I think a polite enquiry would have been a better first
> response than presuming malice.
> 
> Tom

[...]

>> In several places, the edited object no longer has a bicycle=* access
>> tag and segregated=no has been removed, which breaks cycle routing
>> through the path. I am unsure whether this is carelessness, or the
 
>> expression of an agenda which has no place in OSM. If the latter, this
>> is vandalism.
>>

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Pedestrian priority and highway=cycleway

2020-09-03 Thread Robert Skedgell
I think access=permissive could have unfortunate consequences for motor
vehicle routing, unless routers ignore highway=footway|cycleway anyway.

Some of these paths should probably have motor_vehicle=private added
(together with some gates and removable/rising bollards), as maintenance
and event vehicles do use them.

On 03/09/2020 10:58, Gareth L wrote:
> I think the permissive tag is due to it being yet another perceived public 
> space which is actually private, so there’s no public right of way.
> 
> Would access=permissive or access:bicycle=permissive be sensible? Or is that 
> also mangling tagging conventions. I genuinely don’t know!
> 
> Gareth
> 
>> On 3 Sep 2020, at 10:42, Frederik Ramm  wrote:
>>
>> Hi,
>>
>>> On 03.09.20 11:29, Robert Skedgell wrote:
>>> I believe the most appropriate base tagging, following the duck tagging
>>> principle for highway=*, for most of the paths in QEOP would be:
>>> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
>>
>> I think that highway=cycleway implies bicycle=yes so adding a
>> bicycle=permissive would be confusing?
>>
>> In my mental picture the combination highway=cycleway+foot=permissive
>> means: "This is a way made and intended for bicycles. But pedestrians
>> are also tolerated." - which might well be correct given that there
>> seems to be a lot of cycle-related infrastructure around.
>>
>> To be honest, given the rules you cite, I would be tempted to use
>> highway=footway+bicycle=yes OR the dreaded
>> highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
>> the ground.
>>
>> Bye
>> Frederik
>>
>> -- 
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Pedestrian priority and highway=cycleway

2020-09-03 Thread Robert Skedgell
Rather than reverting, I restored access and left the top-level
highway=* tag alone.

I only noticed these changes when plotting a route in Komoot and
noticing that I needed to create/drag a lot of extra waypoints in order
to get the expected behaviour. Hopefully Komoot will behave responsibly
and warn me that I'll need to dismount in a few places. Repairing
routing as quickly as possible was my priority, although it could take
weeks for some routers to restore functionality.

In this case, I think that if there is any tagging for the renderer, the
target renderer was OpenCycleMap rather than OSM Carto.

On 03/09/2020 10:40, Ken Kilfedder wrote:
> These changes should be reverted in my view.
> 
> But I would note that the default map on osm.org does a poor job of 
> communicating the difference between shared paths (like those in QEOP and 
> elsewhere) and dedicated cycle lanes.  Both look like blue dashed lines.   
> They look indistinguishable. So an honest pedestrian mapper might easily jump 
> to the wrong conclusion and make changes of the sort you've described below.
> 
> Perhaps the right way forward is to suggest changes to how osm.org displays 
> shared ways - red dash for dedicated pedestrian, blue dash for dedicated 
> cycleway and alternating for shared?   Maybe something to indicate priority?  
>  Without changes like this, I can see this sort of thing happening again.
> 
> ---
> https://hdyc.neis-one.org/?spiregrain
> spiregrain_...@ksglp.org.uk

[...]

>>
>> It also appears to be tagging for the renderer, as changing
>> cycleway->footway changes the path in OpenCycleMap from a blue dashed
>> line to a red dashed line.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Pedestrian priority and highway=cycleway

2020-09-03 Thread Robert Skedgell
On 03/09/2020 10:41, Frederik Ramm wrote:
> Hi,
> 
> On 03.09.20 11:29, Robert Skedgell wrote:
>> I believe the most appropriate base tagging, following the duck tagging
>> principle for highway=*, for most of the paths in QEOP would be:
>> highway=cycleway + segregated=no + bicycle=permissive + foot=permissive
> 
> I think that highway=cycleway implies bicycle=yes so adding a
> bicycle=permissive would be confusing?
> 
> In my mental picture the combination highway=cycleway+foot=permissive
> means: "This is a way made and intended for bicycles. But pedestrians
> are also tolerated." - which might well be correct given that there
> seems to be a lot of cycle-related infrastructure around.
> 
> To be honest, given the rules you cite, I would be tempted to use
> highway=footway+bicycle=yes OR the dreaded
> highway=path+bicycle=yes+foot=yes - but I haven't seen how it looks on
> the ground.
> 
> Bye
> Frederik
> 

The rationale for using permissive here is that there isn't really any
right of way through the park, so the park's operators can and do close
parts of it with little or no notice for events and maintenance.
Otherwise, I would probably be more inclined to use highway=cycleway +
segregated=no.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[Talk-GB] Pedestrian priority and highway=cycleway

2020-09-03 Thread Robert Skedgell
A user has recently changed highway=cycleway objects in Queen Elizabeth
Olympic Park, London (QEOP) from highway=cycleway to highway=footway on
the ground that "Olympic Park paths are Pedestrian Priority".

In several places, the edited object no longer has a bicycle=* access
tag and segregated=no has been removed, which breaks cycle routing
through the path. I am unsure whether this is carelessness, or the
expression of an agenda which has no place in OSM. If the latter, this
is vandalism.

It also appears to be tagging for the renderer, as changing
cycleway->footway changes the path in OpenCycleMap from a blue dashed
line to a red dashed line.

Changes made by Skyguy in:
https://www.openstreetmap.org/changeset/89374106

Broken routing by missing access tags (not changing the highway=* tag
for now) fixed in:
https://www.openstreetmap.org/changeset/90351366

Most paths in QEOP are 3 metre wide gold-top asphalt (looks a bit like
surface=compacted and sometimes mapped as such) and there are no paths
on which cycling is prohibited. The paths are almost all included as
cycle tracks in the TfL CID export. QEOP is generally open to the public
24/7, but any part can be closed without notice for events.

I believe the most appropriate base tagging, following the duck tagging
principle for highway=*, for most of the paths in QEOP would be:
highway=cycleway + segregated=no + bicycle=permissive + foot=permissive

There is nothing in the Wiki which suggests that pedestrians do not
already have priority on unsegregated cycleways, so the edit seems
unnecessary.

The current Highway Code Rule 62 does not make this explicit, but
pedestrian priority seems a reasonable interpretation of: "Take care
when passing pedestrians, especially children, older or disabled people,
and allow them plenty of room. Always be prepared to slow down and stop
if necessary."
https://www.gov.uk/guidance/the-highway-code/rules-for-cyclists-59-to-82

The proposed new Rule 63 could also reasonably be read as strongly
implying pedestrian priority:
"Sharing space with pedestrians, horse riders and horse drawn vehicles.
When riding in places where sharing with pedestrians, horse riders or
horse drawn vehicles is permitted take care when passing pedestrians,
especially children, older adults or disabled people. Let them know you
are there when necessary e.g. by ringing your bell (it is recommended
that a bell is fitted to your bike), or by calling out politely.
Remember that pedestrians may be deaf, blind or partially sighted and
that this may not be obvious.
Do not pass pedestrians, horse riders or horse drawn vehicles closely or
at high speed, particularly from behind. Remember that horses can be
startled if passed without warning. Always be prepared to slow down and
stop when necessary."
https://www.gov.uk/government/consultations/review-of-the-highway-code-to-improve-road-safety-for-cyclists-pedestrians-and-horse-riders/summary-of-the-consultation-proposals-on-a-review-of-the-highway-code

BCC to DWG because of the impact in cycle routing.

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] National Cycle Network removal/reclassification

2020-08-16 Thread Robert Skedgell
On 16/08/2020 17:46, Ken Kilfedder wrote:
> I should think that in places where there is a good, cycle-dedicated way 
> roughly parallel to a canal, a pedestrian-respecting router would recommend 
> that cyclists stick to the cycle-dedicated way. 

A good example of this might be where NCN route 1 runs parallel to the
Lee Navigation towpath (with moored boats) alongside Hackney Marshes.
https://www.openstreetmap.org/way/7831970

Most of the cycle traffic seems to be local, so most won't be using
routing software. I usually run along the NCN cycle track there because
it's less congested.

I tried a test route from The Greenway to Markfield Recreation ground
with different routing services:
CycleStreets - towpath
cycle.travel - cycle track
Komoot (bike touring) - cycle track
Strava (most direct) - towpath
Obviously this is a tiny and unrepresentative sample.

>> I’m just struggling to think what the tag would add - either for 
>> information or for a routing algorithm.  Also note the the proposals 
>> for the highway code would establish and road user hierarchy which 
>> would apply everywhere 

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] National Cycle Network removal/reclassification

2020-08-14 Thread Robert Skedgell
On 14/08/2020 19:14, Simon Still wrote:
> 
> 
>> On 14 Aug 2020, at 16:47, Ken Kilfedder > > wrote:
>>
>> I believe most of the canal towpaths are 'pedestrian priority' too -
>> at least there are signs to that effect all over the place.  Well
>> worth tagging them to that effect if true.
> 
> I’m not sure that’s actually a legal status that changes anything -
> pedestrians have priority on all shared use paths so not sure that tag
> would add anything 

I think that while it's certainly good practice to give priority to
pedestrians on any shared (unsegregated) infrastructure, I'm not sure
how you would tag it in addition to segregated=no.

On canal towpaths, the Canal & River Trust's cycling FAQ states that
"Pedestrians are generally the most vulnerable and have priority at all
times".
https://canalrivertrust.org.uk/enjoy-the-waterways/cycling/cycling-faqs

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] National Cycle Network removal/reclassification

2020-08-14 Thread Robert Skedgell
On 14/08/2020 13:55, Simon Still wrote:
> See the blog posts that I linked to.  
> Plus 
>  https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database 
> 
> (Our involvement has now ended but TfL should be continuing to use CID
> info to improve OSM accuracy) 
> 
> More discussion planned within LCC and community to press for better
> navigation and wayfinding 

I look forward to seeing how the discussion progresses.

>>> Width of cycleyway is definitely useful if separated from traffic but
>>> some way of reflecting the comfort of the riding experience on marked
>>> routes would be a big step forward. Traffic Volumes,. Lane widths,
>>> traffic speed all contribute (as does surface - gravel bad, cobbles bad,
>>> smooth tarmac good)  
>>
>> Most sections of cycle routes in London which I use already have
>> surface=* set, but there are areas where using smoothness=* consistently
>> might help.
> 
> Good to know surface is already widely used - I’d managed to miss that
> in the work I’d done. 
> Smoothness is a new tag for me 

One way to improve surface=* tagging (and also lit=*) might be to
encourage people to install the Street Complete mobile app and try using
it when they go for a walk. It's very good at finding gaps even in
places mapped with a lot of detail.

> What has come up in discussions is that it would be good to map
> ‘restrictions’ more comprehensively and have routing algorithms that
> recognised them.  
> 
> There are many sections of cycle route (such as canal towpaths) have
> many - rough surface, steep inclines to rejoin roads, width
> restrictions/gates/barriers to stop motorbikes and tight turning radii.
>  All of those would create issues for someone using a bakfiets, cargo
> bike or disability adapted cycle. 

On towpaths, they will often be tagged with highway=footway +
bicycle=permissive + towpath=yes. There are times when I would prefer to
use a route which avoided towpaths as much as possible, particularly the
Regent's Canal and places where boats are moored. Having them mapped is
one thing, but persuading any developers of routing software that there
might be enough demand to add it as a routing option is another.

> An objective would be to be able to plan a ‘disabled suitable route’ 

Asking people to add data at street crossings (particularly crossings of
segregated cycle tracks) like dropped kerbs and tactile paving might be
helpful in this respect, even when it is not of direct use to cyclists.
It might not hurt LCC's case to be seen to be assisting VI pedestrians.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] National Cycle Network removal/reclassification

2020-08-14 Thread Robert Skedgell
On 13/08/2020 15:41, Simon Still wrote:
> 
> In my view there is definitely scope to look at adding more info to
> cycle routes/tracks/cycleways to give more information to routing
> algorithms about the real experience of using them.
> 
> Would welcome input on what as we’re doing more on this at the London
> Cycling Campaign. 

Is there any more information on what LCC are doing in this area? There
are probably members, myself included, who would be happy to help.

I know that borough groups audit changes to local infra, but having
detailed photographs and notes are less useful to the wider cycling
community than they could be if the information never finds its way onto
OSM.

> 
> Width of cycleyway is definitely useful if separated from traffic but
> some way of reflecting the comfort of the riding experience on marked
> routes would be a big step forward. Traffic Volumes,. Lane widths,
> traffic speed all contribute (as does surface - gravel bad, cobbles bad,
> smooth tarmac good)  

Most sections of cycle routes in London which I use already have
surface=* set, but there are areas where using smoothness=* consistently
might help.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] OSMUK Instagram ideas

2020-08-09 Thread Robert Skedgell
On 09/08/2020 14:31, Jez Nicholson wrote:
> I've been posting to the OSMUK
> Instagram https://www.instagram.com/openstreetmapuk/ account recently.
> We are currently focusing on potential new mappers, so i'm thinking
> quirky and topical.
> 
> So,
> 
> a) Do you know of an interesting looking feature in the UK?
> 
> b) Do you know of something topical (and visual)?
> 
> c) After this thread has finished, how best could/would you get in
> contact to tell me? Twitter? A thread on Loomio? Here?
> 
> Regards,
>               Jez
> 

Some of the COVID-19 related highway changes, e.g. modal filters
implemented with planters might be worth including. There's an obvious
visual and routing impact in real life, as rendered by OSM Carto and for
routing engines.

-- 
Robert Skedgell (rskedgell)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] And the USRN tag proposal page

2020-08-06 Thread Robert Skedgell
On 22/07/2020 21:52, Rob Nickerson wrote:
> As promised, here is the second tag proposal page - this time for the
> USRN (Street).
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn
> 
> As before, any comments welcome, especially those that would prevent us
> moving to the voting stage.
> 
> P.S. Does anyone know if we need to highlight these proposals to the
> tagging mailing list? If we do, could someone kindly volunteer please.
> 
> Best regards,
> *Rob*

Where a street has a separately mapped footway/sidewalk, would it be
worth considering adding the USRN to this as well? The advantage might
be that the component parts of a street (or highway in HA 1980 terms)
can be groupeed together without the need to create relations.

In cases like this, we usually have the street tagged with
sidewalk=separate and the footway(s) tagged with footway=sidewalk or
cycleway=sidewalk

-- 
Robert Skedgell (rskedgell)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Surveying rural buildings

2020-07-24 Thread Robert Skedgell
On 23/07/2020 10:55, Mateusz Konieczny via Talk-GB wrote:
> 
> 
> 
> Jul 23, 2020, 11:49 by for...@david-woolley.me.uk:
> 
> On 23/07/2020 10:12, Nick wrote:
> 
> Do we actually know what the general public use OSM for?
> 
> 
> My impression is that the target for a lot of the material in OSM is
> professional users of maps, rather than the general public.
> 
> I would say that most of use by general public is indirect - from location
> maps in a bus, through maps on mapy.cz/Osmand/FB/Snapchat/Uber/Maps.me
> to indirectly benefiting from use of OSM data in various
> plans/analysis/scientific research.

I though Uber used Google, which would explain a couple of comical
misdirections to somewhere near-ish to my destination, which I could
replicate later on in Google.

> 
> I would say that direct use by general public is going to be fairly
> rare, though still
> happening, like with nearly all resources.
> 

There's also a lot of indirect use by the public in route planning sites
and apps, particularly for cyclists, e.g. Komoot, CycleStreets and
cycle.travel

It's also fairly heavily used by sport and activity tracking apps like
Strava and Training Peaks (both via Mapbox), VeloViewer, etc.

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Scheduled Monument

2020-07-23 Thread Robert Skedgell
This licence (including any non-contractual disputes) is governed
by, and will be construed in accordance with, English law and the
exclusive jurisdiction of the English courts.

-- 
Robert Skedgell (rskedgell)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Paths on Wimbledon Common

2020-07-10 Thread Robert Skedgell
On 10/07/2020 13:35, David Woolley wrote:
> On 10/07/2020 13:11, Colin Smale wrote:
>> What does "legally accessible" mean? Are they Public Footpaths? Do we
>> tag all Public Footpaths with an explicit "foot=yes" or is
>> "designation=public_footpath" enough?
>>
> 
> I don't know the situation in Wimbledon Common, but most footpaths in
> public park are more correctly described as access=permissive.

foot=permissive might be better, as that doesn't imply anything at all
for other transport modes.

> 
> My understanding is that designated only has meaning if combined with an
> access type tag with a value of designated.
> 

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] UPRN Locations Map

2020-07-05 Thread Robert Skedgell
On 05/07/2020 17:58, Mark Goodge wrote:
> 
> 
> On 05/07/2020 17:45, Kai Michael Poppe - OSM wrote:
>> On 05.07.2020 17:51, Andy Mabbett wrote:
>>
>>>> I've set up a quick slippy map with the UPRN locations shown:
>>>>
>>>> https://osm.mathmos.net/addresses/uprn/ (zoom in to level 16 to show
>>>> the data)
>>>
>>> Naive question - can that be added as a layer in JOSM? If so, how?
>>
>> Yes and no. The UPRN data is also available as a GeoPackage (just like
>> USRN), yet when I tried this morning, I was unable to make to GeoServer
>> deliver the data correctly.
> 
> Just out of interest, is there any simple way to export data from
> GeoPackage (eg, to GML or GeoJSON) via the command line on Linux? I've
> tried ogr2ogr, but that doesn't seem to recognise GeoPackage as a
> source. I can do it manually by loading it into QGIS desktop and then
> exporting it, but I'd prefer something I can automate.
> 
> Mark
> 

This worked for me to import a copy of the USRN GeoPackage file into my
local OSM database:

ogr2ogr -f PGDump -s_srs EPSG:27700 -t_srs EPSG:3857 \
osopenusrn_202007.sql osopenusrn_202007.gpkg

Is it possible that your installation of GDAL doesn't include support
for the GPKG vector driver?

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] UPRN & USRN Tagging

2020-07-03 Thread Robert Skedgell
Surely these should be ref:GB:uprn and ref:GB:usrn, as UK is not an ISO
3166-1 alpha-2 country code?

Having had a quick look at USRN data, it appears that roads may have
more than one USRN, as a road may have more than one of 'Designated
Street Name', 'Officially Described Street', 'Numbered Street' and
'Unofficial Street Name'. In addition to this, some streets appear to
have a UPRN for the 'street record'.

On 03/07/2020 15:31, Tony OSM wrote:
> As we have access to the data and Robert Whittaker has produced a great
> UPRN locations map, how are we planning to tag OSM objects?
> 
> ref:UK:uprn and ref:UK:usrn
> 
> have been suggested as tags - I think this is the way to go.
> 
> 
> There is also Key:ref:NPLG:UPRN:1 in the wiki.
> 
> 
> Question: Should uprn be applied to the building outline or to a node?
> 
> The OS data applies them as nodes, they are assigned by local
> authorities to a location as a node.
> 
> The uprn is applied to many objects even bus shelters, and individual
> flats within a block; there may be what appear to be duplicates.
> 
> I suggest that for OSM buildings or building parts which are
> individually linkable to a uprn then the uprn is assigned to the
> building way outline; otherwise to an OSM node if the mapper deems
> appropriate
> 
> Tony Shield    ---   TonyS999
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] "secret" site

2020-06-28 Thread Robert Skedgell
Is it mapped or does it appear to be redacted on NLS's out-of-copyright
OS maps?

On 28/06/2020 09:27, Tony OSM wrote:
> I question the meaning of the word 'secret' when used in a newspaper. My
> observations are that secret means the reporter didn't know about it.
> 
> Tony
> 
> On 28/06/2020 00:47, David Woolley wrote:
>> On 27/06/2020 23:37, Dave Love wrote:
>>> I was going to map a covered reservoir round here that I've known from
>>> my youth, but I happened to find an article about it from the local
>>> paper suggesting the location is secret, though it's listed in
>>> Historic England.  (It's not far from a "sensitive government
>>> establishment" that no-one locally knew about before it ceased to be
>>> secret :-/)
>>> Should I not map it, or pretend I didn't see the article?
>>>
>>
>> How would another mapper verify this?  I normally think that people
>> interpret the map only what's on the ground rule too literally, but in
>> this case, I'd suggest the moral thing to do is to ignore your local
>> knowledge an only map what can be seen, without guessing its
>> significance.
>>
>> (There are some road signs entitled "secret bunker", e.g. for Kelvedon
>> Hatch, but I don't think this is the case here.
>>
>> On the other hand, there used to be part of the North Yorkshire moors
>> that had "undefined" written over it on OS maps.)
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] JOSM Plugin for the FHRS API

2020-06-26 Thread Robert Skedgell
The fhrs:authority tag isn't normally necessary as it can be inferred
from the surrounding local authority boundary.

There are some exceptions to this, including premises where the food
hygiene authority is the City of London Corporation, but which are not
located within the City of London boundary. Some of these are presumably
on Port of London Authority land, e.g. the floating Good Hotel in Royal
Victoria Dock ( https://www.openstreetmap.org/way/523627051 ).

On 26/06/2020 11:54, o...@poppe.dev wrote:
> Hi Dave,
> 
> whilst doing the current week's Q session
> (https://wiki.openstreetmap.org/wiki/Schwerpunkt_der_Woche/Overpass_Postcodes),
> where we check postcodes against their country's respective pattern I
> came across multiple object, that _had_ an fhrs:id but were missing the
> correct postcode (only the Outward code was tagged) - even more so the
> fhrs:authority information are missing in most objects I've come across
> so far.
> 
> So, yes, it's usefulness is restricted for objects with fhrs id but it's
> not complete useless :-)
> 
> Kai
>> Dave F via Talk-GB < talk-gb@openstreetmap.org
>> > hat am 26. Juni 2020 um 12:39
>> geschrieben:
>>
>>
>> As the OSM entity has to already contain the FHRS:ID tag it limits the
>> usefulness of this plugin. Won't most have address data added when
>> contributors initially add the FHRS tag? I certainly do.
>>
>> What would be useful is a way to search the LA's database for retailers
>> which don't have a FHRS tag.
>>
>> DaveF.
>>
>> On 26/06/2020 05:58, Kai Michael Poppe - OSM wrote:
>>> Good morning everyone,
>>>
>>> I built a plugin for JOSM that allows you to merge data from the FHRS
>>> API into OSM with a few clicks. I'd love to find some people that would
>>> be willing to test the 0.1.2 version and report bugs they found and/or
>>> comment on the user experience.
>>>
>>> Just throw me a line at o...@poppe.dev  and I'll
>>> send you the download link.
>>>
>>> Thanks in advance!
>>>
>>> Kai
>>>
>>>
>>> ___
>>> Talk-GB mailing list
>>> Talk-GB@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Cycle Track - part/soft protection tags - proposal

2020-06-19 Thread Robert Skedgell
That seems to cover everything I can think of in London. I'll have to
get off my backside and take some Mapillary images of new infra as soon
as the experimental traffic orders come into force.

On 19/06/2020 16:29, Simon Still wrote:
> Try this - description and photo of each type I’ve identified.  Most of
> these photos are London infra, many COVID emergency meausres
> 
> https://docs.google.com/document/d/1VL0MmHJoapd4JRgDhow0el2H06IJNsK-8KycxtWSaEw/edit?usp=sharing
>  
> 
> You should be able to leave comments on that doc as well 
> 
> 
> 
>> On 16 Jun 2020, at 23:21, Mateusz Konieczny via Talk-GB
>> mailto:talk-gb@openstreetmap.org>> wrote:
>>
>> Do you have a photo of such feature?
>>
>> https://i1.wp.com/bicilonatours.com/wp-content/uploads/2017/02/barcelona-cr-urgell.png
>> link is dead
>>

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] COVID road changes

2020-06-18 Thread Robert Skedgell
LB Southwark have just made some ETOs which explicitly mention the
London Streetspace programme in the London Gazette announcement. The
orders come into force on 2020-06-25 and expire on 2021-12-29.

https://www.thegazette.co.uk/notice/3579196

This could be a good opportunity to work out how to tag the changes.

On 16/06/2020 19:27, Simon Still wrote:
>>Temporary and experimental traffic orders may include a date on which
>>the expire or have to be reviewed, so that could perhaps be tagged?
> 
>>None of the orders which I have seen have explicitly mentioned Covid-19,
>>but any suggestions about how to tag these would be useful.
> 
> A COVID-19 tag  - or  #StreetspaceLDN  StreetspaceLondon or some
> variation could also enable mapping that highlights the temporary
> infrastructure (I know there is interest in this within the cycling
> community) 
> 
> Best
> Simon
> (Didn’t receive original mail so apologies if this doesn’t thread)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] COVID road changes

2020-06-12 Thread Robert Skedgell
Temporary and experimental traffic orders may include a date on which
the expire or have to be reviewed, so that could perhaps be tagged?

None of the orders which I have seen have explicitly mentioned Covid-19,
but any suggestions about how to tag these would be useful.

On 12/06/2020 08:07, Gregory Marler wrote:
> Has anyone been adding any tagging to designate these as Covid-19
> temporary blocks?
> 
> It would make it interesting to see the amount of change, but also allow
> us to check which ones haven't been reverted when able.
> 
> Gregory. 
> 
> On Fri, 12 Jun 2020, 01:23 Robert Skedgell,  <mailto:r...@hubris.org.uk>> wrote:
> 
> On 11/06/2020 23:35, Stephen Colebourne wrote:
> > Hi,
> > It seems that COVID is likely to result in some rapid changes to road
> > networks, which OSM will need to capture.
> >
> > I saw a tweet today of the area around the Bank of England, and a road
> > is now one way with a cycle lane the other way. Obviously I can't
> > survey that right now, but Google Maps traffic layer is showing it.
> > Really it needs someone to do a survey (unless we can use the City of
> > London documentation).
> >
> > More generally, I guess we will all need to keep an eye on proposals
> > from each council. For example, here is a tweet from last month about
> > 50 modal filters (road closures) in just Croydon and Lambeth:
> > https://twitter.com/MeristemDesign/status/1260339305261785088 showing
> > the scale of the task here.
> >
> > Stephen
> >
> I'm following a feed from The Gazette for traffic orders in London which
> need to be mapped. When MacLondon doesn't get there first, I've either
> been adding notes, putting in changes using the proposed: namespace, or
> setting a reminder in my calendar for the start date, as appropriate.
> The data are released under OGL v3.0 and can sometimes be used for
> updates without a survey being essential.
> 
> This will show notices for "Cycle tracks, bus lanes & tramways" and
> "Road restrictions":
> 
> https://www.thegazette.co.uk/all-notices/notice?results-page-size=50=1=1=latest-date=G408040001+G408040004=all-notices
> 
> -- 
> Robert Skedgell (rskedgell)
> 

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] COVID road changes

2020-06-11 Thread Robert Skedgell
On 11/06/2020 23:35, Stephen Colebourne wrote:
> Hi,
> It seems that COVID is likely to result in some rapid changes to road
> networks, which OSM will need to capture.
> 
> I saw a tweet today of the area around the Bank of England, and a road
> is now one way with a cycle lane the other way. Obviously I can't
> survey that right now, but Google Maps traffic layer is showing it.
> Really it needs someone to do a survey (unless we can use the City of
> London documentation).
> 
> More generally, I guess we will all need to keep an eye on proposals
> from each council. For example, here is a tweet from last month about
> 50 modal filters (road closures) in just Croydon and Lambeth:
> https://twitter.com/MeristemDesign/status/1260339305261785088 showing
> the scale of the task here.
> 
> Stephen
> 
I'm following a feed from The Gazette for traffic orders in London which
need to be mapped. When MacLondon doesn't get there first, I've either
been adding notes, putting in changes using the proposed: namespace, or
setting a reminder in my calendar for the start date, as appropriate.
The data are released under OGL v3.0 and can sometimes be used for
updates without a survey being essential.

This will show notices for "Cycle tracks, bus lanes & tramways" and
"Road restrictions":
https://www.thegazette.co.uk/all-notices/notice?results-page-size=50=1=1=latest-date=G408040001+G408040004=all-notices

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] barrier=kerb on highways may be blocking OSRM (Car) routing

2019-12-18 Thread Robert Skedgell
On 18/12/2019 16:26, David Woolley wrote:
> On 18/12/2019 15:59, Robert Skedgell wrote:
>> It's parking a car on a
>> footway which is illegal in London (an offence which is only subject to
>> civil enforcement), unless explicitly allowed by the local authority.
> 
> It's potentially a criminal offence anywhere see sub-paragraph 17 of
> <http://www.legislation.gov.uk/ukpga/1980/66/section/184>.  I think the
> situation in London is just that the default position is reversed, and
> everywhere is assumed to have a notice by default.  The offence is
> crossing the kerb or verge, not parking on the footway, which is a
> separate offence.

I believe the general prohibition of driving on footways to be s. 72
Highway Act 1835
<http://www.legislation.gov.uk/ukpga/Will4/5-6/50/section/72>.

In London, footway parking is prohibited by s. 15 Greater London Council
(General Powers) Act 1974
<http://www.legislation.gov.uk/ukla/1974/24/section/15>, although it's
illegal to park an HGV on a footway or verge anywhere under s. 19 Road
Traffic Act 1988
<http://www.legislation.gov.uk/ukpga/1988/52/section/19>. Both of these
are enforced only as civil parking contraventions, using codes 62 and 61
respectively.

> 
> I think issue of civil enforcement is just that the police have
> abdicated all this sort of thing to civil enforcement, rather that it
> isn't a crime.  About the only parking offences the police will
> prosecute are dangerous and obstructive parking, but they could
> prosecute any of them.

In civil enforcement areas in England (most places now), the police
cannot enforce a parking offence as a criminal matter other than for a
pedestrian crossing contravention, see regulation 7 of The Civil
Enforcement of Parking Contraventions (England) General Regulations 2007
<http://www.legislation.gov.uk/uksi/2007/3483/regulation/7/made>.
Complying with legislation isn't really an abdication of their powers.

The police can act on a vehicle parked in a dangerous position under s.
22 Road Traffic Act 1988
<http://www.legislation.gov.uk/ukpga/1988/52/section/22>, but this isn't
a parking offence per se. This may be fortunate as a CEO who may have an
(officially denied) quota to fill shouldn't be serving PCNs based on
their subjective judgement.

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] barrier=kerb on highways may be blocking OSRM (Car) routing

2019-12-18 Thread Robert Skedgell
On 18/12/2019 15:36, Philip Barnes wrote:
> On Wednesday, 18 December 2019, David Woolley wrote:
>> On 18/12/2019 13:31, Edward Catmur via Talk-GB wrote:
>>> That said, the same goes for cars - other than the lowest bodied sports 
>>> cars, pretty much all motor vehicles are capable of taking a kerb at low 
>>> speed.
>>
>> Although raised kerbs are generally there to stop that happening and the 
>> resultant trespass on the footway can be illegal, e.g. in London.  As 
>> such routers should not be routing motor vehicles over kerbs.

I believe the simplified version of this is that it's generally illegal
(a criminal offence) to drive a car on a footway, unless there's a
vehicle crossover provided for that purpose. It's parking a car on a
footway which is illegal in London (an offence which is only subject to
civil enforcement), unless explicitly allowed by the local authority.
Trespass isn't likely to be the issue on highways maintainable at public
expense.

> Its a level of detail that few of us have mapped, but it is perfectly 
> acceptable, and quite common, to route motor vehicles  over lowered kerbs to 
> access private property. 
> 
> Phil (trigpoint)

For access to a private property as a destination, hopefully
kerb=lowered at the intersection of the highway=service and barrier=kerb
ways would be interpreted as allowing it by a router.

-- 
Robert Skedgell (rskedgell)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Disused or empty apartments prior to demolition

2019-12-18 Thread Robert Skedgell

On 17/12/2019 20:54, David Woolley wrote:

On 17/12/2019 20:35, Warin wrote:


so
building=apartments
becomes
disused:building=apartments

or
building=yes
becomes
disused:building=yes


I disagree.  It is still a building.  In fact some of the most 
interesting buildings are disused ones.


Rather than change the tagging on the buildings, if they are currently 
enclosed by a landuse=residential polygon*, perhaps change that to 
something else (splitting the polygon if appropriate)?


Unfortunately that creates another headache, as neither 
landuse=construction nor landuse=brownfield really seem to fit the 
original case.


* In the OP's example, this is https://www.openstreetmap.org/way/676088956

--
Robert Skedgell (rskedgell)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Strava heatmaps - permission reconfirmed

2019-11-16 Thread Robert Skedgell
On 16/11/2019 13:34, Rob Nickerson wrote:
> Hi all,
> 
> In 2014 Strava developed a custom version if the ID editor which
> included their heatmap. The tool could adjust OSM ways to better align
> them with their GPS heatmap.
> 
> Some years ago that tool stopped working and use of the heatmap for
> improving OSM was drawn in to doubt. That doubt has now come to an end
> as Strava have been able to reconfirm that we are ok to use it in to
> improve OSM:
> 
> https://lists.openstreetmap.org/pipermail/talk/2019-November/083564.html
> 
> This is a good supplement to the OSM GPS traces and can be used to help
> map public rights of way and improve road alignment.
> 
> Happy mapping,
> *Rob*
> 

With any luck, this may mean that Strava have remembered that OSM exists
and will start updating the embarrasingly out of date maps which they
present to end users.

https://support.strava.com/hc/en-us/community/posts/360019440271-Mapbox-maps-not-updated-from-OpenStreetMap-recently-

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Managed open water swimming

2019-09-12 Thread Robert Skedgell
Thanks, Dan. network=* looks like quite a good fit.

On 12/09/2019 12:43, Dan S wrote:
> It sounds like the network=* tag might be useful for this? eg
> network=NOWCA. I'm suggesting it because it sounds like a fairly
> similar situation to the London bike hire scheme (for which we use
> this tag), in which one can use RFID keys to borrow a bike from any of
> various locations...
> 
> https://taginfo.openstreetmap.org.uk/keys/network#values
> 
> Best
> Dan
> 
> 
> Op do 12 sep. 2019 om 12:26 schreef Robert Skedgell :
>>
>> There are a few open water swimming areas which are operated by the
>> landowner, but use RFID wristbands provided by NOWCA or Great Swim Local
>> to manage booking and attendance.
>>
>> I feel that the operator=* tag should probably contain the operator of
>> the site, so does anyone have suggestions for the best way to capture
>> NOWCA and Great Swim Local sites?
>>
>> For OWS in the reservoir at Hadleigh Park (
>> https://www.openstreetmap.org/way/724008897 ), I currently have it
>> tagged as follows:
>> access=customers
>> contact:website=https://hadleigh-park.co.uk/open-water-swimming/
>> leisure=swimming_area
>> opening_hours=We 17:30-19:30;Sa 08:00-10:00
>> operator=Hadleigh Park
>> sport=swimming
>>
>> There should probably also be a fee=yes added to the above.
>>
>> --
>> Rob Skedgell (rskedgell)
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Possible removal of FHRS tags

2019-09-12 Thread Robert Skedgell
This is a very late reply, but there are other cases where
fhrs:authority is useful, particularly for premises where the City of
London Corporation is the local authority. It's probably not a useful
tag within the City of London itself, but is for Port of London areas
like the Royal Docks (actually in LB Newham) and Tilbury.

On 14/08/2019 17:12, SK53 wrote:
> I see little value for all of these except fhrs:rating_date which is
> scarcely used. The local authority to which a rating belongs can be
> directly determined from OSM most of the time, but may be useful in
> Northern Ireland where we have no good usable data on LA boundaries. 
> 
> I would rather that if they are to be removed it is when data is updated
> (i.e. by the editor discard list).
> 
> I do have a collection of extracts of FHRS data going back to 2013, but
> have not been updating these regularly for some time. They are useful
> for providing address details & sometimes as a cross check that a place
> has genuinely gone out of business (e.g., a note to the effect that a
> pub has closed).
> 
> Jerry
> 
> On Wed, 14 Aug 2019 at 15:19, Andrew Hain  > wrote:
> 
> Are the keys fhrs:rating (3358 occurences in Taginfo),
> fhrs:inspectiondate (1748), fhrs:confidence_management,
> fhrs:hygiene, fhrs:structural (621 each) and fhrs:rating_date (22)
> better off removed from our database, or should they be kept for
> businesses that disappear from FHRS listings when still open?
> 
> What about fhrs:local_authority_id (11724)?
> 
> Is fhrs:authority (12981) useful for businesses on borders?
> [https://www.openstreetmap.org/note/807942]
> 
> Should any that are not kept be removed in bulk or added th
> discarded lists in editors?
> 
> --
> Andrew
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[Talk-GB] Managed open water swimming

2019-09-12 Thread Robert Skedgell
There are a few open water swimming areas which are operated by the
landowner, but use RFID wristbands provided by NOWCA or Great Swim Local
to manage booking and attendance.

I feel that the operator=* tag should probably contain the operator of
the site, so does anyone have suggestions for the best way to capture
NOWCA and Great Swim Local sites?

For OWS in the reservoir at Hadleigh Park (
https://www.openstreetmap.org/way/724008897 ), I currently have it
tagged as follows:
access=customers
contact:website=https://hadleigh-park.co.uk/open-water-swimming/
leisure=swimming_area
opening_hours=We 17:30-19:30;Sa 08:00-10:00
operator=Hadleigh Park
sport=swimming

There should probably also be a fee=yes added to the above.

-- 
Rob Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[Talk-GB] Dubious edits to parks in Bromley

2018-11-29 Thread Robert Skedgell
I've noticed a few edits around Bromley by a new user CliveDom, who
appears to be changing Bromley's green spaces to random, and as far as I
can tell, entirely fictional schools, hospitals, industrial sites, etc.
All have the changeset comment "Better description".

https://openstreetmap.org/changeset/65019858
https://openstreetmap.org/changeset/65020180
https://openstreetmap.org/changeset/65020220
https://openstreetmap.org/changeset/65020251
https://openstreetmap.org/changeset/65020313

I've flagged these on OSMCha, but other changesets by this user may need
checking and reverting.

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Spurious No U turns in GB

2018-06-27 Thread Robert Skedgell
On 27/06/2018 16:01, David Woolley wrote:
> On 27/06/18 15:30, SK53 wrote:
>> # Junctions with islands which also cause a single carriageway to
>> split and merge around the junction.
>> #
>
> I would definitely agree that this is tagging for the renderer, and
> wrong.
>
> However, I can think of a case like this where you might well get
> attention from the police, for a dangerous manoeuvre, if you U-turned
> at any time but the early hours.  I seem to remember that one of the
> routers thinks this is a good place for a U-turn.
>
> Obviously the correct thing is for routers to use a heuristic to
> detect that if two one way roads join at a very acute angle, they
> shouldn't route from one to the other, or should give it a large
> penalty, but it does beg the question as to whether OSM should allow
> router hints.
>
> The problem with hints is that, like "too dangerous for cycles, so
> mark as no cycling" they are subjective, and the router should really
> be looking at the topology to infer a that this is really a dual
> carriageway.

Where there really is a no U-turn sign (and consequently an offence
contrary to s. 36 RTA 1988 for failure to comply), might it help to tag
it with traffic_sign=GB:614 (see Schedule 3 to TSRGD 2016,
)?

This wouldn't do anything to help routing algorithms, but might make it
a little easier for mappers to find potentially spurious restrictions to
re-survey.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Legible London signs - tagging suggestions

2017-01-10 Thread Robert Skedgell
On Tuesday, 10 January 2017 21:46:53 GMT Steve Doerr wrote:
> On 10/01/2017 07:54, Robert Skedgell wrote:
> > ref=legible_london
> 
> I don't understand the rationale for this as a 'ref'. Refs are normally
> unique identifiers for a particular object (unique within a particular
> domain, that is). Thus each sign would have a different ref, if there
> were indeed a system of refs for Legible London signs. The value
> 'legible_london' looks more like a network tag.

ref=* was (as already stated in another reply) an error in my thinking/
recollection - something like brand=legible_london or network=legible_london 
would seem appropriate choices from the suggestions made.

On closer inspection of a few of the miniliths in Stratford, they do have a 
unique ID number which would be an appropriate use for the ref key.

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Legible London signs - tagging suggestions

2017-01-10 Thread Robert Skedgell



Andy
That's a very good point. I suspect that I mis-remembered the use of 
crossing_ref=* (used with highway=crossing + crossing=*) as just "ref".
brand=legible_london seems a much better fit, particularly as it makes it seem 
less of an assertion about the actual legibility of the map (as noted in an 
earlier comment).
Perhaps also operator=* for the borough responsible, or TfL as appropriate? 
-- Robert Skedgell  (rskedgell)

 Original message 
From: Andy Allan <gravityst...@gmail.com> 
Date: 10/01/2017  15:10  (GMT+00:00) 
To: Robert Skedgell <r...@hubris.org.uk> 
Cc: Talk-GB <talk-gb@openstreetmap.org> 
Subject: Re: [Talk-GB] Legible London signs - tagging suggestions 

On 10 January 2017 at 07:54, Robert Skedgell <r...@hubris.org.uk> wrote:

> ref=legible_london

I would only use the ref= tag if there is a reference code for each
installation, e.g. if the totem has a displayed reference like "A01"
designed for users to see. From the pictures I don't think that they
do, and if they did, I would expect it to be a reference for internal
use - i.e. official_ref=

Think of it like bus stops (ref=C) or road numbers (ref=A204). Would
it make sense if I was to render a map with an icon for the
information point, with the reference shown underneath?

I would suggest brand=legible_london as an alternative, but there
might be other options too.

Thanks,
Andy
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Legible London signs - tagging suggestions

2017-01-10 Thread Robert Skedgell

The wiki lists map_type and map_size as "useful combinations" for the tag 
combination tourism=information + information=map ( 
https://wiki.openstreetmap.org/wiki/Tag:information%3Dmap ).
Using map_type=street probably makes sense as it is already in use and seems a 
reasonable match for the feature.
I am rather more dubious about map_size, partly because nothing currently in 
use really seems to fit and partly because "size" seems potentially ambiguous 
to convey information about the area covered.
I was aware of the different types of sign listed in TfL's product range PDF, 
but was not really convinced that the distinction between monolith and totem 
(or variants of minilith) would really be useful. Something other than 
tourism=information + information=map would be needed for the waymarker bollard 
and fingerposts in any case as these do not have maps.

 Original message 
From: David Groom <revi...@pacific-rim.net> 
Date: 10/01/2017  10:59  (GMT+00:00) 
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] Legible London signs - tagging suggestions 


Not quite sure what you had in mind by the tags map_type and map_size, 
but maybe need a tag something along the likes of "sign_type" withn 
values of "bollard | monolith | finger_post | totem" ( see 
http://content.tfl.gov.uk/legible-london-product-range.pdf)

David


-- Original Message --
From: "Robert Skedgell" <r...@hubris.org.uk>
To: talk-gb@openstreetmap.org
Sent: 10/01/2017 07:54:41
Subject: [Talk-GB] Legible London signs - tagging suggestions

>Does anyone have any suggestions for tagging nodes for the Legible 
>London
>signs/maps (see https://en.wikipedia.org/wiki/Legible_London and 
>https://
>tfl.gov.uk/info-for/boroughs/maps-and-signs )?
>
>Perhaps:
>  tourism=information
>  information=map
>  map_type=street
>  map_size=site
>  name=*
>  ref=legible_london
>
>--
>Robert Skedgell (rskedgell)
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[Talk-GB] Legible London signs - tagging suggestions

2017-01-09 Thread Robert Skedgell
Does anyone have any suggestions for tagging nodes for the Legible London 
signs/maps (see https://en.wikipedia.org/wiki/Legible_London and https://
tfl.gov.uk/info-for/boroughs/maps-and-signs )?

Perhaps:
tourism=information
information=map
map_type=street
map_size=site
name=*
ref=legible_london

-- 
Robert Skedgell (rskedgell)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb