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

[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

[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

[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

[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: [OSM-talk] When two bots go to war

[Robert Whittaker (OSM lists)]

Maybe there should be a general good-practice recommendation / policy
that bots running in this fashion to keep things in sync should only
automatically add/update/remove a tag that they've previously set if
the current state/value in OSM is unchanged from the last state/value
that the bot set. This way, bots could be used to keep things up to
date automatically, but would not automatically override any manually
applied changes by other mappers between runs. (A sensible bot owner
would have the bot send them a report of any tags that couldn't be
updated for manual review.)

Robert.

On Thu, 14 Sept 2023 at 08:41, Cj Malone
 wrote:
>
> On Tue, 2023-09-12 at 15:06 +0200, Snusmumriken via talk wrote:
> > My speculation is that Distriktstandvården (a chain of dental
> > clinics)
> > has taken "ownership" of "their" nodes and once a day check that the
> > values in osm database correspond to that of their internal database.
>
> I've added a more specific website tag to test this. If they restore it
> (Probably 03:00) to the generic home page I agree with you. They need
> to be informed that 1) there data needs improving (eg covid opening
> hours, POI specific not brand specific contact details) 2) they don't
> own these nodes, other people can edit them.
>
> CJ
>
> https://www.openstreetmap.org/changeset/141243391


-- 
Robert Whittaker

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[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

[OSM-talk] ODbl concerns

[Robert C Potter (DTP) via talk]

Hi OSM,

Representing the state transport authority (Department of Transport and 
Planning) we have made the strategic decision to use OSM as our foundational 
mapping data source.  We are confident that this is a decision will be of value 
to both ourselves improving the management of the networks (road, Train, Bus, 
tram) and adding significantly to the citizens of the state.

Our intended use of OSM is built on an extract being done then validating that 
extract for the gazetted/official place and road names. The resultant validated 
dataset will be shared that via our Opendata portal.  Our state government has 
a strong commitment to sharing all data openly.  We are currently developing 
that process and should be in production by the end of the year.

Alas, there has been concern from our distribution partners with the ODbl 
license requirement to "Share alike".  You know these companies; Google, Here, 
Tomtom and Apple.

The information we would share, and all shared as ODbl;

  *   Disruptions
  *   Heavy vehicles
  *   Bicycles routes
  *   Public transport routes and timetables

I am wondering how we, can continue engage with these partners and use and 
improve OSM.



If you have any further queries, please do not hesitate to contact me.



Regards,



Robert Potter

Helping people use the power of location to make better decisions

Manager, Spatial Data Strategy
Department of Transport and Planning

1 Spring Street

MELBOURNE 3000


M 0402 484 739

F 03 9935 4111
E robert.pot...@roads.vic.gov.au
W dtp.vic.gov.au

[cid:16f05bdc-8c23-42fb-9db6-2304edffd042]


I acknowledge the Traditional Aboriginal Owners of Country throughout Victoria 
and pay my respect to Elders past and present and emerging and to the ongoing 
living culture of Aboriginal people.

DISCLAIMER

The following conditions apply to this communication and any attachments: 
VicRoads reserves all of its copyright; the information is intended for the 
addressees only and may be confidential and/or privileged - it must not be 
passed on by any other recipients; any expressed opinions are those of the 
sender and not necessarily VicRoads; VicRoads accepts no liability for any 
consequences arising from the recipient's use of this means of communication 
and/or the information contained in and/or attached to this communication. If 
this communication has been received in error, please contact the person who 
sent this communication and delete all copies.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-gb-london] Tube exits

[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-au] DTP Data Wavier Submitted

[Robert Potter via Talk-au]

Hi OSM-AU,

It is with great pleasure and personal satisfaction that I can today announce 
that an appropriately appointed officer has signed the CC BY 4.0 wavier for DTP 
https://wiki.openstreetmap.org/wiki/Victoria,_Australia.

This means any information made public via the Victorian Government OpenData 
platform by the Department of Transport and Planning is able to be used in 
OpenStreetMap, including and most requested has been the GTFS supply.


Regards,



Robert Potter

Department of Transport and Planning (Victoria, Australia) - OpenStreetMap 
Wiki<https://wiki.openstreetmap.org/wiki/Department_of_Transport_and_Planning_(Victoria,_Australia)>

W dtp.vic.gov.au

DISCLAIMER

The following conditions apply to this communication and any attachments: 
VicRoads reserves all of its copyright; the information is intended for the 
addressees only and may be confidential and/or privileged - it must not be 
passed on by any other recipients; any expressed opinions are those of the 
sender and not necessarily VicRoads; VicRoads accepts no liability for any 
consequences arising from the recipient's use of this means of communication 
and/or the information contained in and/or attached to this communication. If 
this communication has been received in error, please contact the person who 
sent this communication and delete all copies.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[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

[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

[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

[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?

[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

[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

[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

[Talk-si] Eurovelu 9, del Slovenija

[Robert Grübler]

Hallo Nachbarn!

The Austrian forum is currently discussing Eurovelo 9, part Slovenia:
https://forum.openstreetmap.org/viewtopic.php?pid=849233#p849233 
Please don't be put off by the German language, contributions in Slovenian
are of course just as welcome.

Best regards
Robert

--- Automatic translation ---
Na avstrijskem forumu trenutno poteka razprava o Eurovelu 9, del Slovenija:
https://forum.openstreetmap.org/viewtopic.php?pid=849233#p849233
Naj vas ne odvrne nemščina, prispevki v slovenščini so seveda prav tako
dobrodošli.

Lep pozdrav
Robert


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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

As others have said, having some uniform national scheme of
places/areas that each address is assigned to is useful for anyone
using addresses. No-one outside the local area will know which postal
districts correspond to which areas, or even where many remote postal
areas are. Local authorities would be better than postcode districts,
but again they may not always be well-known (even amongst local
residents), and their boundaries can change. Post towns provide a more
recognisable way for people to identify the rough location of an
address. They're also good for error checking / correction within
addresses.

In any case, if OSM is going to be a useful source of addresses for
businesses and the public, we need to replicate the official addresses
that everyone is currently used to using.

On Mon, 21 Dec 2020 at 16:19, Chris Hill  wrote:
> How are they verifiable? There is no open source that is compatible with
> the OSM licence that I am aware of that lets us look up an address.

There are plenty of open sources for addresses. They won't be
complete, but if you know the postcode of the address you're
interested in, in the vast majority of cases you should be able to
find an open address that's close enough to be able to infer the post
town. In particular, there is an open dataset of addresses for all
post office branches: https://osm.mathmos.net/postoffice/data/ . This
should cover pretty much all the post towns, and if you add in the
(admittedly imperfect) FHRS data, I'd have thought that you should be
able to deduce the correct post town in almost every case.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] Probleme mit User / Qualitätsoffensive Salzburg usw.

[Robert Kaiser]

Johann Haag schrieb:

Wir sind in Österreich für eine gedeihliche Qualitätsdiskussion mit dem
grundsätzliche Problem konfrontiert, dass Österreichs Protagonisten bislang
auf das Instrument eines eigenen Local Chapter verzichten.
Mit in Anonymität auftretenden Identitäten kann man schwer in einen
fruchtbaren Dialog treten.


Weder die OpenStreetMap Foundation, noch ihre Local Chapters sind für 
die Datenqualität der OSM-Datenbank (bzw. daraus gerenderter Karten) 
zuständig. Die Leute, die in der Community aktiv sind, haben die 
Verantwortung für die Qualität, und bei Konflikten gibt es die DWG - 
https://wiki.osmfoundation.org/wiki/Data_Working_Group - um diese zu 
lösen (oder auch andere Probleme, die die Daten betreffen, wie 
Lizenzkonflikte).


Zusätzlich finde ich, dass eine Gruppe wie ein Local Chapter sogar noch 
mehr "anonym" wirken würde, als Leute aus der Community, die hier 
persönlich sagen, welche Meinung sie haben. Ich habe schon viele 
fruchtbare Dialoge hier gesehen, aber dazu braucht es die Bereitschaft, 
auf den anderen einzugehen, was man sicher nicht mit Anschuldigungen 
z.B. von "Interessenkonflikten" und "Anonymität" macht. Ich bitte, hier 
konstruktiv zu sein.


Grüße,
KaiRo


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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

On Mon, 21 Dec 2020 at 12:02, Alan Mackie  wrote:
>
> I struggle with what to call the  in that example.
>
> A recent suggestion for named terraces was to use addr:street= 
> and addr:parentstreet=, but if the  relates the 
> whole building to to parentstreet, then reconstructing an address seems 
> impossible.

In cases where a building/property has a number and/or name on a main
street and is then sub-divided into dwellings, I would put the
building/property info in addr:housenumber and/or addr:housename with
addr:street as the main street. You then need a way to tag the
individual dwelling identifiers. Looking at
https://wiki.openstreetmap.org/wiki/Key:addr#Detailed_subkeys it looks
like addr:unit might be the best tag to use.

This is a different way of thinking about things from the "named
terrace" as a sub-street approach. There are certainly real
sub-streets branching off main streets that could use addr:street=*
and addr:parentstreet=* that will want that approach. And there will
be instances of named/numbered buildings that have flats or
appartments within them that will want the approach above. There will
be probably be borderline cases between the two that could use either
scheme, though if the main property/building has a number on the main
street, you wouldn't be able to use the sub-street approach.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Anglican churches

[Robert Whittaker (OSM lists) via Talk-GB]

On Fri, 18 Dec 2020 at 20:07, Donald Noble  wrote:
> Forgive me if I've missed it somewhere, but what do the different colours 
> represent on the nameless places of worship page?

It's not documented anywhere at the moment, but the different coloured
markers on the "nameless" maps at e.g.
https://osm.mathmos.net/nameless/amenity/place_of_worship simply
denote the type of OSM object: node, way or relation.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] UK street addressing

[Robert Whittaker (OSM lists)]

Like it or not, in the UK addresses are defined by Royal Mail. They're
introduced the concept of a "postal town", and this is one of the few
common elements that each address must always have. Once you accept
that the Post Town is intended to be a nearby significant place (to
help with delivery routing and identifying the rough location of the
addressed property) rather than being a place that the address is
"in", then it's really no more of a fiction than the postcode. (The
village I grew up in had a GL postcode, despite it being in
Worcestershire. I've currently got an IP postcode, despite being in
Norfolk and closer to Norwich (NR) than Ipswich.)

On the basis that it's a required part of each address, I would
recommend that we do store the post town in OSM addresses. There are
significant advantages to storing it in a consistent way, and the best
existing tag to do this would be addr:city. (We wouldn't want to
invent a new tag (e.g. addr:posttown), since as a UK-only term that
will simply be ignored by most international data consumers.

We then have a possible hierarchy of named localities between the
street and the post town to record as part of the address. I would
suggest using appropriate values from the set {addr:hamlet,
addr:village, addr:town, addr:suburb}. (I don't see any other
alternatives to this.) Most of these key names already have a
reasonable number of uses in OSM (addr:town is the lowest, but that
still has 59k uses), so it seems that others are doing this too.

Regarding properties (e.g. on named terraces or sub-streets), where
there are two street names (Thoroughfare and Dependent Throughourfare
in Rail Mail terminology) then we need a second key to store the other
street name under. Certainly if there is an addr:housenumber or
addr:housename, I think we need to use addr:street for the
street/terrace name on which that name or number applies. Otherwise,
software that's unaware of the second key name will think it's house
number n on the main street not the sub-street. There are already
about 3.5k uses of addr:parentstreet in OSM, so I'd recommend using
that for the main street, and addr:street for the terrace or
sub-street name. If any data-users aren't aware of addr:parentstreet
it's not a major issue, since it will still pick up the correct
terrace/sub-street name, and the locality, which will probably be
enough to use as an address.

I would strongly argue against using addr2 in connection with
sub-streets, as it's not standardised, and is likely to not be picked
up by any software. There's an abondoned proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/addr2 , but that
was for the case of a single property on a street corner having two
formal addresses, one on each street, not for the case of two streets
in a hierarchy.

Robert.

On Sun, 20 Dec 2020 at 12:47, Dave Abbott  wrote:
> I am trying to make sure I tag addresses correctly. I am currently
> trying to understand how to map in my area.
>
> The postal addresses are like:
>
> 99 Postal Street
> Smalltown
> Largertown
> West Yorks XY9 7GY
>
> Smalltown is geographically separate to Largertown, which however is the
> Postal Town. Omitting Smalltown from the address is probably correct
> postally-speaking, but local residents would object as Smalltown is seen
> as completely separate to other places under the same Postal Town.
>
> Currently tagging as -
> addr:housenumber=99
> addr:street=Postal Street
> addr:city=Smalltown, Largertown
>
> But I am pretty sure this is wrong.
>
> There is a page at
> https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping which
> mentions "suggested tags" but there is no evidence that this is in use.
> If correct I would be tagging as -
>
> addr:housenumber=99
> addr:street=Postal Street
> addr:town=Smalltown
> addr:city=Largertown
>
> Hoping someone can advise me as to the correct way to tag for the UK...
>
> Dave Abbott  (OSM user DaveyPorcy)
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


-- 
Robert Whittaker

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

Re: [Talk-GB] Anglican churches

[Robert Whittaker (OSM lists)]

On Fri, 18 Dec 2020 at 18:05, Sean Blanchflower  wrote:
> In case anyone's interested I set myself the lockdown project of ensuring all 
> the active Anglican churches in England are mapped consistently in OSM, and 
> have gotten as far as I realistically can for the moment.
>
> The net result is that of the 15649 active Anglican churches that I know of 
> in England, all of them are now in OSM mapped as ways with 
> building=church;amenity=place_of_worship;religion=christian;denomination=anglican;name=XX
> other than...

Good stuff!

On a slightly related note, I've recently done a bit of an upgrade to
my "Nameless" tool. This flags objects that don't have a name=* tag
when you'd usually expect them too. There's now a page for each tag
combination with a map and list of the nameless objects. The
top-ranked tag combination is amenity=place_of_worship, with around
4,000 instances:
https://osm.mathmos.net/nameless/amenity/place_of_worship . I think a
lot of them may have been armchair-mapped from possibly out of date
maps. So if anyone is at a loose end and fancies trying to work out if
the places of worship listed there are still in use and if so what
their name is, please have a look.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

[Robert Grübler]

Am 18. Dezember 2020 11:24 schrieb Thomas Rupprecht

> Ich kann das wie gesagt in NÖ und Wien überhaupt nicht nachvollziehen 
> dass die Gebäudegeometrie von basemap.at mit dem Orthofoto übereinstimmt.

Ein Beispiel aus der Steiermark
https://www.basemap.at/application/index.html#{%22center%22:[1710031.0462455489,5954434.468193395],%22zoom%22:20,%22rotation%22:0,%22layers%22:%221000%22}
 
(auf herauszoomen klicken)

Die Volksschule in Thal Westseite
 https://www.mapillary.com/map/im/WdyozZKr1utqzh0yQYRJSp :
Das rechte Inneneck ist von oben nicht sichtbar, aber dennoch in basemap.at 
korrekt verzeichnet

Unmittelbar davor ist der Lagerplatz für den Müll:
https://www.mapillary.com/map/im/Xe4RtyYH1JfcwrBRj1CrYy
Das Flugdach über die Mistkübel ist in basemap.at als Teil des Gebäudes 
eingezeichnet

Die Jakobuskirche in der Nachbarschaft hat über dem Eingangsbereich ein 
Flugdach:
https://www.mapillary.com/map/im/vbfHph7ffcwJGFDCwfqOme
Das Flugdach ist in basmap.at eingezeichnet

Mein Eindruck: je jünger die Bearbeitung, umso eher stammt sie vom Luftbild. 

LG Robert


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

Re: [Talk-at] OSM Gebäude, Dachfläche oder Grundriss

[Robert Kaiser]

Johann Haag schrieb:

Neben der Garagenzufahrt eignen sich als weiteres Indiz der jeweilige
Gebäudeanschluss zu Nebengebäuden. Zieht man den regional üblicherweise
bekannten Typischen Dachüberstand ab, so gelingen solche Anschlüsse auch
ohne künstliche Erker oder andere Verrenkungen.


Sorry, aber OSM ist kein Ratespiel. Wir sollten nach bestem Wissen und 
Gewissen das einzeichenen, was wir WISSEN. Wenn wir nur das Dach wissen, 
weil wir von Orthofots abzeichnen, dann ist es gut genug, das zu nehmen. 
Wenn du nicht selbst vor Ort warst und das ausgemessen hast, oder einen 
(für die Übernahme erlaubte) Datenquelle hast, die eindeutig besser ist, 
dann ändere nicht Dinge, weil du *schätzt*, dass es so sein könnte.
Wenn du der erste bist, der das Haus einzeichnet, dann kannst du das 
machen, weil du nach bestem Wissen und Gewissen versuchst, das hin zu 
bekommen. Aber wenn es schon da ist, und die Geometrie nicht auf Grund 
des WISSENS in verfügbaren Quellen zu verbessern ist, dann lass es 
lieber, wie es ist. Weniger Arbeit und eine nur geschätzte 
"wahrscheinlich-möglicherweise" Verbesserung ist keine eigentliche 
Verbesserung und bringt niemand was, schadet nur der Community, weil 
sich der Mapper, der das vorher eingezeichnet hat, übergangen, wertlos 
oder auf den Schlips getreten fühlt.


KaiRo


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

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

[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)

[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-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 10.12.2020 schrieb Friedrich Volkmann

> Die Alpenvereine sind keine Alleinherrscher …
So ist es. OSM darf das Beste von allen vereinen.

> Das Symbol für "alpine Route" hab ich noch nie auf einem Wegweiser gesehen.
Hier siehst du es: 
https://upload.wikimedia.org/wikipedia/commons/1/17/Wegweiser_Warnsdorfer_H%C3%BCtte.jpg
 

> Wenn man auf die bestehenden Wege die neuen, gelben Wegweiser aufstellt, 
> macht man halt die blauen/roten/schwarzen Punkte dazu, aber das heißt nicht, 
> dass die schwarzen einem T4 entsprechen
https://www.alpenverein.de/bergsport/aktiv-sein/bergsport-die-schwierigkeits-skalen_aid_27599.html
 



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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 09.12.2020 schrieb Friedrich Volkmann:
> Wie ich schon tausendmal geschrieben habe, gibt es zwischen 
> Wandern und Klettern keine klare Trennlinie.
:
> Natürlich ist dritter Grad kein Wanderweg, aber die Grenze 
> fix zwischen 2 und 3 anzusetzen finde ich zu unelastisch
:
> Demnach dürften wir so ziemlich gar keine Wege als path mappen

Interessant, du kommentierst alles, nur den Kern meiner Argumentation nicht. 
Offenbar hab ich es schlecht formuliert. Lass es mich noch einmal versuchen.

Das Problem – einen klare Trennlinie zwischen Wandern und Klettern zu ziehen – 
haben nicht nur wir, sondern auch die Alpenvereine. Sie haben das Problem 
gelöst, indem sie die „Alpine ROUTE“ zwischen dem klassischen Wandern und dem 
Klettern geschoben haben.

Alpine Route – T5 bis T6 oder kleiner(!) – i.d.R. weder gewartet noch angelegt
Bergwege – T2 bis T4 – gewartet und markiert; Grade: blau, rot, schwarz
...[1] Schwierigkeitsskalen: 
https://www.alpenverein.de/bergsport/aktiv-sein/bergsport-die-schwierigkeits-skalen_aid_27599.html
 
...[2] Begriffsbestimmungen, Seite 25 „1.6.1.2Geltungsbereich“: 
https://www.alpenverein.at/portal_wAssets/docs/berg-aktiv/wege_touren/wegehandbuch_digital.pdf
 

[1] visualisiert das recht gut. Für T1 bis T4 passt die generische Bedeutung 
von „path“ (und nein, das ist kein urzeitliches Relikt). Für die „Alpine ROUTE“ 
braucht es etwas anderes. „climbing=route“ könnte ich mir gut vorstellen, es 
ist bereits 458x verwendet. Auch gibt es eine Karte, die es renderd.

LG Robert



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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 6. Dezember 2020 schrieb Kevin Kofler:

> Leider wurde für den dort besprochenen Trail die "Lösung" implementiert, 
> den highway=path Tag ersatzlos zu löschen, sodaß die Kletterroute wohl auch 
> für diejenigen nicht mehr sichtbar ist, für die sie ursprünglich gemappt 
> wurde. 
> (Nein, sport=climbing ist kein ausreichender Tag, wenn nicht zugleich 
> irgendein Basistag gesetzt ist, 
> der beschreibt, worum es sich bei der Linie überhaupt handelt.) Aber das ist 
> eine DWG-Entscheidung 
> und betrifft zudem Kanada, also werden wir hier auf talk-at eher nichts daran 
> ändern können.

Die Entscheidung der DWG halte ich für richtig, als T6 Wanderweg mappen und im 
note vermerken "das ist eine Kletterroute" das geht nicht. Zumal aus der 
Versionsgeschichte hervorgeht, dass es dort schon mehrmals zu gefährlichen 
Situationen kam.

Das „sport=climbing“ in der Luft hängt ist unschön, sollte sich aber mit einem 
passenden natural=* einfach beheben lassen.
Auch climbing=route am Weg bietet sich an 
(https://wiki.openstreetmap.org/wiki/Climbing#Climbing_Routes )

Das Problem gibt es nicht nur in Kanada. Zwei Beispiele:

1.) Weg zum Tuxeck
https://www.openstreetmap.org/way/125672765 
Ein 7m hoher, senkrechter Kamin im UIAA Grad 3 ist doch kein T6 Wanderweg. Oder?

2.) Wiederroute auf die Watzmann-Mittelspitze
https://www.openstreetmap.org/relation/1959910  
Die Relation ist eine Kletterroute (diesen Relationstyp finde ich im Wiki 
nicht) mit UIAA-Grad 3, der darunterliegende Weg ist ein T6 path!


Ich finde, die DWG sollte die Einzelentscheidung generalisieren.

Für mich liegt die Begründung in der Definition von „path“( 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath ):
„ highway=path is a generic path, either multi-use or unspecified usage, open 
to all non-motorized vehicles …”
Hier liegt die Betonung eindeutig auf die Verkehrsfläche und ist damit auch ein 
Weg im Sinne des §2 StVO 1960 und des §1319a(2) ABGB. Ein T6 path geht weit 
über eine Verkehrsfläche hinaus und hat viel mehr Ähnlichkeit mit einer 
Kletterroute.

LG Robert


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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 13:18, Dave F via Talk-GB
 wrote:
>
> https://snipboard.io/scrm5R.jpg
>
> There you go, free of any supposed copyright infringement.

Not quite. Before we're able to use any third-party data in OSM, we
need to verify that it is available under a suitable licence. So you
would still need to get permission from Wiltshire Council to use that
data, and ensure that any required attribution statements or
disclaimers are correctly recorded at
https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
.

If you trust the author of Rowmaps, you could make use of the
Wiltshire data that's available from
https://www.rowmaps.com/datasets/WT/ (which claims to be re-usable
under the OGL v3) once the appropriate attribution statement is added
to the OSM Contributors page linked above. However the precise
attribution statement required isn't clear, and the copyright text in
the files on rowmaps conflicts with the statement that it's available
under the OGL v3. (If the text in the files is correct, then they're
incompatible with OSM use, due to the additional sub-licensing
requirement.)

So I think we'd be better to wait for a successful outcome at
https://www.whatdotheyknow.com/request/public_rights_of_way_gis_data_9
before using the Wiltshire data. Many other councils have made their
data available under terms we can use in OSM, as you can see from
https://osm.mathmos.net/prow/open-data/ .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 12:37, Dave F  wrote:
> On 08/12/2020 12:08, Robert Whittaker (OSM lists) wrote:
> > On Tue, 8 Dec 2020 at 09:39, Mark Lee via Talk-GB
> >  wrote:
> >> Hello. I've just added a missing public bridleway 
> >> (https://www.openstreetmap.org/way/882278479) which is detailed on the 
> >> Wiltshire Definitive Map.
> > Generally these maps have lines drawn on top of
> > Copyrighted Ordnance Survey base-maps, which means they're off-limits
> > for use in OSM.
>
> Do you have evidence of this being the case? Has someone from OS (or
> anyone outside OSM) stated that?

Since the Definitive Maps are someone else's work, without a licence /
permission, we aren't allowed to make use of them in OSM. So the
question is usually moot. I'm not aware of any instances of a
Surveying Authority granting a re-use licence for its definitive maps.

But, generally speaking, the base-map will contain a OS copyright
notice, and OS have historically claimed derived data rights over
anything drawn on top of their base-maps. This would mean that local
authorities aren't able to authorise any re-use. That's changed
slightly in the last few years, with OS's "Presumption to Publish"
policy. But this makes it clear that it's only the derived data on its
own (and not the basemaps) that third-parties are able to licence. See
https://www.ordnancesurvey.co.uk/business-government/licensing-agreements/presumption-to-publish-form
and in particular point 5: "For example, you can’t use OS licensed
data as a background picture to give your data better real-world
context." The upshot of this is that Councils are able to allow re-use
of their Rights of Way data if it's separated from the OS base-map
(e.g. as a stand-alone GIS file), but not the Definitive Maps
themselves.

I guess if a council is still using a very old OS base-map that has
since gone out of copyright, things might be different. But you'd
still need an explicit licence from the council if their depictions of
the Rights of Way were still in copyright. And there's a question
about the status of derived data rights on derivations made while the
base-maps were still in copyright.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Bridleway across field

[Robert Whittaker (OSM lists)]

On Tue, 8 Dec 2020 at 09:39, Mark Lee via Talk-GB
 wrote:
> Hello. I've just added a missing public bridleway 
> (https://www.openstreetmap.org/way/882278479) which is detailed on the 
> Wiltshire Definitive Map.

I see that you've put source="Wiltshire Definitive Map" in the
tagging. Do you have permission to use information from the Definitive
Map in OpenStreetMap? Generally these maps have lines drawn on top of
Copyrighted Ordnance Survey base-maps, which means they're off-limits
for use in OSM.

Digitised Public Rights of Way data (without the base-map background)
is another matter though, and it is possible to get permission to use
these. But we need an explicit statement / licence from each Council.
Generally this will be permission to use the data under the Open
Government Licence, and we would then need to document this with the
specified attribution statement at
https://wiki.openstreetmap.org/wiki/Contributors#Public_Rights_of_Way_Data_from_local_councils
. Wiltshire is not currently listed there, although there is an FOI
request in progress to get the data and permission to use it:
https://www.whatdotheyknow.com/request/public_rights_of_way_gis_data_9
.

I maintain a table of which authorities we have PRoW data for and what
licence it can be used under at
https://osm.mathmos.net/prow/open-data/ . Any updates and corrections
to this would be most welcome.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Idea - OSMUK walkers' map application

[Robert Whittaker (OSM lists)]

On Sat, 5 Dec 2020 at 15:29, Nick Whitelegg via Talk-GB
 wrote:
> A shame really, an open, standard API - and accompanying open source clients 
> to the API - adopted by all councils for problem reporting would be a great 
> thing to have.

It would indeed be great. An open standard for this already exists --
it's called Open311. I don't think there's very much adoption of it
though. See https://www.open311.org/ and
https://www.mysociety.org/2013/01/10/open311-introduced/ . Fix
MyStreet can make use of it where it is available, and some of the
councils they have collaborated with may well support it.

If anyone is looking to create some sort of reporting tool for PRoW
faults, I'd suggest a system that will use Open311 if the council
supports it, and otherwise send the report through FixMyStreet.

Robert.

-- 
Robert Whittaker

___
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

[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: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Robert Whittaker (OSM lists)]

On Wed, 2 Dec 2020 at 21:56, Michal Migurski  wrote:
> First, the text of the ODbL is explicit about “reasonably calculated” 
> awareness. FB believes its maps comply with this. The ODbL does not require 
> that “every” person see the attribution. It requires that “any” person can.

I believe that you are wrong here. In ODbL 4.3, "any Person" is
synonymous with "every Person". The term "reasonably calculated"
modifies the whole clause, and is about the result of the scheme as a
whole, not "reasonable awareness" by individuals. It means that the
attribution method you use must be reasonably calculated to ensure
that *every* person viewing will be aware that content has come from
OpenStreetMap. Nowhere does the clause allow you to only provide the
opportunity for anyone to be able to discover the source if they
decide to, or to only ensure some people are aware. Yes, the
"reasonably calculated" means that not 100% of people necessarily have
to be aware, but the attribution scheme does have to have the purpose
and intention of making everyone aware. You have to be able to say
that under a reasonable assessment of the scheme, everyone viewing the
work will know of the ODbL source. I think it's clear this is not the
case for the current Facebook attribution, as clearly lots of people
will not choose to click on the "(i)" icon.

Given your interpretation of ODbL 4.3 and the statements you have made
so far, does this mean that you and/or Facebook are admitting that the
current Facebook attribution does not meet this stricter
interpretation of 4.3? i.e. the current Facebook attribution is not
"reasonably calculated" to ensure that every person who "uses, views,
accesses, interacts with, or is otherwise exposed to the Produced Work
aware that Content was obtained from" OpenStreetMap?

I think this is a crucial point that the OSM community needs an answer
to, given your candidacy for the OSMF Board.

Many thanks,

Robert.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] I’m running for OSMF board and I’ve set up office hours for questions

[Robert Whittaker (OSM lists)]

On Wed, 2 Dec 2020 at 03:41, Michal Migurski  wrote:

> Facebook is in compliance with the ODbL license which requires that 
> attribution be “reasonably calculated to make any Person that uses, views, 
> accesses, interacts with, or is otherwise exposed to the Produced Work aware” 
> of OSM’s contribution to a map.

Are you seriously claiming that *every* person who views one of the
maps on Facebook, will either already know that it uses OpenStreetMap
data, or will click on the faint "(i)" logo to find that out? Because
that is what the ODbL requires. This isn't just about a mechanism for
people who are already motivated to find out where the map data comes
from, your attribution needs to be reasonably calculated to ensure
that *everyone* viewing one of your maps (whether they're interested
or not) is aware that the map data has come from OpenStreetMap. I
don't see how you can claim that your current attribution does that.

Robert.

-- 
Robert Whittaker

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] High quality NLS imagery of buildings and HOUSENUMBERS (!) available in London (and Scotland). Create a tasking manger to add this?

[Robert Whittaker (OSM lists)]

On Tue, 1 Dec 2020 at 09:53, Ken Kilfedder  wrote:
> IpswichMapper forwarded me this note, apparently received from NLS via an 
> enquiry made by Rob-from-OSMF:
>
> > “I wish I could give you better news on the 1940s OS maps of south-east 
> > England.
> > Unfortunately, you’re right, they were scanned by a third-party commercial 
> > company
> > who have placed commercial re-use restrictions on this layer – there are 
> > further
> > details under our Copyright Exceptions list at
> > https://maps.nls.uk/copyright.html#exceptions. These restrictions will last 
> > for
> > another couple of years – until the end of 2022 – which I know might seem a 
> > long
> > way off, but hopefully will pass quickly. Then we’ll be happily able to 
> > share
> > them with the OSM community, along with the rest of England and Wales
> > National Grid 1940s-1960s mapping, that will be of interest too.”

Looking at https://maps.nls.uk/copyright.html#exceptions am I right in
thinking that the non-commercial contract restriction also applies to
some other NLS layers (e.g. OS 1:25k and 7th series scans) which have
been available (and being used) in popular OSM editors for some time
now? Do we have some specific permission to use those layers, and if
so does that permission apply to the new house number layer as well?

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Recycling Points

[Robert Whittaker (OSM lists)]

On Sat, 28 Nov 2020 at 12:35, Mateusz Konieczny via Talk-GB
 wrote:
> 28 Nov 2020, 10:48 by robert.whittaker+...@gmail.com:
>
> I guess the problem is that recycling_type=container is being used
> both for individual containers and for mini sites with a group of
> containers.
>
> Is it really a problem?

It is if you want to be able to micro-map such a site and the
individual containers within it.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Recycling Points

[Robert Whittaker (OSM lists)]

On Fri, 27 Nov 2020 at 09:42, Jez Nicholson  wrote:
> Agreed, "point" sucks as a value, I won't use itmy fundamental reason for 
> it not being a 'centre' was size, but a Recycling Point _could_ be seen as a 
> mini Recycling Centre that only accepts recyclable waste. You can see a 
> perimeter boundary by the concrete area it is set on. I could go with a site 
> relation but you can't physically carry out other activities between the 
> constituent objects (unlike a wind farm).

How about recycling_type=container_site ?

I guess the problem is that recycling_type=container is being used
both for individual containers and for mini sites with a group of
containers. An alternative approach would be to continue to use
recycling_type=container for the site, and have a new tag for
individual containers within such a site. (Then it would be a bit like
mapping individual parking spaces within a car-park.)

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 19. November 2020 02:01 schrieb Kevin Kofler

> In dem Vergleich schneidet aber keine der Online-Karten wirklich gut ab

Du meinst keine ist empfehlenswert? 

OK, mein Anspruch war zu hoch. Vielleicht ist es besser nicht von 
„empfehlenswerten Karten“ zu sprechen sondern von „geeigneten Karten“. Ich 
meine damit alle Karten, welche die Mindestanforderungen erfüllen. Diese 
Punkteliste, die alle erfüllt sein müssen, ist sicher einfacher zu erstellen 
als eine Liste von Bewertungskriterien mit deren  numerischen 
Gewichtungsfaktoren.

Meine Mindestanforderungen sind:
1.  Basiert auf OSM
2.  Richtet sich an Wanderer
3.  Hat eine Legende für Wanderwege
4.  Deckt zumindest ein Kontinent ab
5.  Aktualisiert zumindest 1x jährlich
6.  Stellt sac_scale zumindest in 2 Gruppen dar

„trail_visibility“ darzustellen halte ich für keine Mindestanforderung.

LG Robert



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

Re: [Talk-GB] UPRN wiki page

[Robert Whittaker (OSM lists)]

On Wed, 18 Nov 2020 at 10:42, Jez Nicholson  wrote:
> My personal opinion is that UPRNs never apply to a road or road section. They 
> apply to something that you cannot see, like a grit bin that is no longer 
> there.

It's definitely possible for UPRNs to be assigned to streets. I think
you can tell this by searching for such a UPRN at
https://www.findmyaddress.co.uk/ (I don't look at that now since they
added a new T forbidding any use of the information for competing
purposes.) IIRC, that site will tell you if a UPRN you enter is a
street reference, and then refuse to provide the usual address
information.

It could well vary by local authority, but looking at the pattern of
URPNs near where I live, it certainly seems that there is one assigned
to every public road. There is consistently exactly UPRN at one end or
the other of each road. The pattern is quite obvious if you look at a
housing estate with lots of little roads.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] ALS-Daten frei zugänglich

[Robert Kaiser]

Friedrich Volkmann schrieb:
Wenn ich Talent für Schönreden hätte, wär ich Unternehmer oder Makler 
geworden und stinkreich.


Die Unternehmer in dieser Gruppe, die ziemlich sicher alle nicht 
"stinkreich" sind, können auf solche fehlplatzierten Kommentare in 
Zukunft gut verzichten. Danke!


KaiRo


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

Re: [Talk-GB] UPRN wiki page

[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-at] ALS-Daten frei zugänglich

[Robert Kaiser]

Patrick Strasser-Mikhail schrieb:
https://www.landesentwicklung.steiermark.at/cms/beitrag/12803182/142970647/ 



Was in dem Beitrag ziemlich interessant wirkt, ist - für mich zumindest 
- dass sie behaupten, dass das BEV demnächst ein 1m-Modell mit 
orthometrischen Höhen in data-gv-at zur Verfügung stellen wird. Das 
könnte für uns alle hilfreich werden, auch außerhalb der Steiermark...


KaiRo


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 11. November 2020 20:02 schrieb Richard:

> das Problem sind die Nichtwanderkarten die niemals vorhatten 
> sac_scale, via_ferrata_scale, uiaa uvm auszuwerten,
> wie soll das jemals funktionieren.

Sie darauf ansprechen - und dann vergessen, für den eigenen Seelenfrieden.
Als Mapper gehört das Kartendesign nicht zu unseren Aufgaben. Wir schauen auf 
die Richtigkeit der Daten.

LG Robert



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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Max Berger schrieb am Sep 19, 2020; 4:10pm

> Hier eine Gegend mit allen Arten von sac_scales: 
> https://opentopomap.org/#map=16/47.44846/11.78192

Super Testfall, Danke. Die Gegend um den Krahnsattel hat alle Wege von T1 bis 
T6 und einen Klettersteig. Diese Overpass Abfrage visualisiert alle 
Schwierigkeitsgrade:
sac_scale (Krahnsattel): https://overpass-turbo.eu/s/ZQ0 

Diese Overpass Abfrage visualisiert alle Sichtbarkeitsgrade:
trail_visibility (Hafelekar): https://overpass-turbo.eu/s/ZQh  
Die Gegend um den Hafelekar hat Pfade mit allen 6 Sichtbarkeitsgrade (excellent 
... no).


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 19.09.20 um 15:29 schrieb Marcus MERIGHI: 

> fuer mich ist das thema nicht eingeschlafen... 

Das Thema poppt offenbar immer wieder hoch:
Diskussion 2015: https://forum.openstreetmap.org/viewtopic.php?id=31856 
Carto Issue, offen seit 2015: 
https://github.com/gravitystorm/openstreetmap-carto/issues/1500 
Bericht CTV Canada: 
https://www.ctvnews.ca/canada/father-and-daughter-rescued-from-side-of-treacherous-b-c-mountain-1.4000757
 
Der Pilot ist der Wahnsinn!


> ich habe mir zu diesem zweck eine liste mit mir bekannten renderern 
> angelegt .. bitte gebt bekannt was ich alles vergessen habe!

Ich denke, man sollte zwischen Wanderkarten – richten sich ausdrücklich an 
Wanderer -  und Nichtwander-Karten unterscheiden. 
Die *Nichtwander-Karten* sollten die alpine Pfade (>T2) nicht oder nur sehr 
unauffällig rendern. Toursprung 
https://maptoolkit.net/#/@11.78448,47.44822,15,0,0,terrain/themes  macht das 
mMn recht gut. Andernfalls sie darauf ansprechen, so wie du es vorhast.

Die *Wanderkarten*, die das gut machen, sollten wir fördern, indem wir sie 
empfehlen. Ausgangspunkt könnte die Seite 
https://wiki.openstreetmap.org/wiki/Hiking_Maps sein. Da möchte ich etwas 
machen.


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

Re: [Talk-GB] "Survey Me" Tool Update

[Robert Whittaker (OSM lists)]

On Sat, 7 Nov 2020 at 13:02, ael via Talk-GB  wrote:
> On Sat, Nov 07, 2020 at 12:11:42PM +0000, Robert Whittaker (OSM lists) wrote:
> > For anyone who's interested, I've just updated my "Survey Me" tool at
> > https://osm.mathmos.net/survey/ .
>
> I took a look and it flagged up
>   https://www.openstreetmap.org/node/3149722064
> as having no name. But it has a perfectly good name?

It's not flagging https://www.openstreetmap.org/node/3149722064 , it's
flagging the building next to it:
https://www.openstreetmap.org/way/679205532 . That building is tagged
with shop=yes but no has name=* tag. When an issue concerns an
existing OSM object, you'll find a direct link to that object in the
popup bubble when you click/tap on the icon.

In this case see: https://osm.mathmos.net/survey/#19/51.7885/-1.4833 .
If the building is only that single shop, then you could remove the
shop node and transfer the tags to the building way. If the building
also has other uses (e.g. there's a flat above the shop, or it
contains more than one shop) then it might be better to remove the
shop=yes tag from the building, and move the shop node inside the
bounds of the building instead.

Robert.

-- 
Robert Whittaker

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

[Talk-GB] "Survey Me" Tool Update

[Robert Whittaker (OSM lists)]

For anyone who's interested, I've just updated my "Survey Me" tool at
https://osm.mathmos.net/survey/ . It now includes food retail chains
where OSM mapping doesn't agree with the "Retail Points" dataset from
Geolytix ( https://blog.geolytix.net/tag/retail-points/ ).

The idea of "Survey Me" is that it flags up potential errors or
omissions in OSM data that probably require a ground survey to
resolve. So mappers may like to have a look at their local area, or
anywhere they are visiting, to see if there's anything worth checking
out.

More details of the comparison between OSM data and Retail Points can
be found at https://osm.mathmos.net/chains/ .

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] ALS-Daten frei zugänglich

[Robert Grübler]

Am 3. Nov 2020 20:22 schrieb Patrick Strasser-Mikhail

> Ev. auch schauen auf
>  https://data.steiermark.at/
>
> Dort gibt es allerdings interessante Lizenz-Zusätze:

Die vollständigen Nutzungsbedingungen sind hier nachzulesen: 
https://data.steiermark.at/cms/ziel/95633648/DE/

Es besteht aber kein Grund zur Beunruhigung, OSM hat die Erlaubnis die Open 
Government Data der Steiermark zu verwenden: 
https://wiki.openstreetmap.org/wiki/Contributors#Austria  " Federal State of 
Styria (Land Steiermark, OGD-Portal) - Special CC BY-Statement for 
OpenStreetMap"

LG Robert


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 31. Oktober 2020 23:32 schrieb Friedrich Volkmann
...

Hallo Richard,
Lass dich von Friedrich nicht ins Bockshorn jagen, das ist seine Meinung und 
nicht die der Mapper in Österreich. Und nimm seinen Kommunikationsstil nicht 
persönlich, der entgleist öfters.

LG Robert



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

Re: [Talk-GB] OSM UK's first tile layer

[Robert Whittaker (OSM lists)]

On Sat, 17 Oct 2020 at 00:22, Rob Nickerson  wrote:
> Just in time for the AGM, I have just published OSM UK's first tile layer. No 
> don't get too excited it is not a full map render. Instead I have produced a 
> very simple tiling of the Land Registry polygon data now that this is under 
> the OGL Open Data Licence. My view is that this is a good layer to align our 
> mapping too - i.e. when tracing from imagery we should first align the 
> imagery to the Land Registry polygon layer before tracing from the imagery.
>
> The tile URL for JOSM is:
> tms[13,17]:http://tiles.osmuk.org/LRpolygons/{zoom}/{x}/{y}.png

Excellent. Ever since the new Bing imagery landed, I've been after a
good source to align things to. I've been having to rely on my own GPS
traces and/or existing mapping so far.

By the way, when there was some previous discussion on this list about
using OS data for imagery alignment, an issue was raised about needing
to ensure any transformation from OSGB grid coordinates to WGS84 is
accurate enough:
https://lists.openstreetmap.org/pipermail/talk-gb/2020-August/025077.html
. Popular transforms may be out by a few meters (which would be
noticeable in our detailed mapping.) Are you doing such a
transformation, and are you sure what you're doing is sufficiently
accurate?

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

Re: [Talk-GB] Q4 2020 Quarterly Project: Defibrillators

[Robert Whittaker (OSM lists)]

On Fri, 9 Oct 2020 at 16:20, Gareth L  wrote:
> The UK quarterly project for Q4 has been selected as Defibrillators. 
> https://wiki.openstreetmap.org/wiki/UK_2020_Q4_Project:_Defibrillators
>
> A check on taginfo shows there are 4181 nodes and ways with 
> emergency=defibrillator in Great Britain. Reading 
> https://cesafety.co.uk/list-of-public-access-defibrillators-across-the-uk 
> from August 2019 reports that there are 5304 defibrillators in London alone.

I've got the AED data from all the Ambulance Services in the UK apart
from Northern Ireland and London in my OSM comparison tool at
https://osm.mathmos.net/defib/progress/ . Much of the data is more
than a year old, but given our current levels of mapping, that
probably doesn't matter too much for now. Of the 25k AEDs in those
Ambulance Services' data, we've currently only got about 12.4% of them
mapped. So there's lots to do.

The Ambulance Services are currently moving to a central UK-wide
database of AEDs called "The Circuit" (see [1] and [2]), which is
being run by the British Heart Foundation. It's not clear whether
they're intending to publish the national set of locations, though my
local Ambulance Service (East of England) have said they intend to
keep publishing a list for their region.

It's apparent from my tool that there are a significant number of AEDs
that we have mapped in OSM but which aren't on the Ambulance Services'
lists. It would be great if we could engage with the people running
The Circuit to look into ways in which they could use OSM data to help
them discover additional AEDs that haven't yet been registered with
them. I doubt they would take our data on trust (I think they want to
have contact details for the owners and regular assurances that the
AED is being actively maintained) but it would be a good source of
hints for them in who to contact to get the missing devices registered
with them.

Robert.

[1] https://www.thecircuit.uk/
[2] 
https://www.bhf.org.uk/how-you-can-help/how-to-save-a-life/defibrillators/ndn-the-circuit

-- 
Robert Whittaker

-- 
Robert Whittaker

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

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

[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-at] Aufgelassenen Wanderweg mappen?

[Robert Grübler]

Am 4. Oktober 2020 18:44 schrieb Horst Willingshofer via Talk-at

> Ist es für Wanderwege zielführend den Tag abandoned=yes zu verwenden?
> Empfehlt ihr mir eine andere Vorgehensweise?

Ich lösche die Relation, wenn Markierungen nur mehr vereinzelt aufzufinden sind 
und keine Hoffnung auf Wiederherstellung mehr besteht. Andernfalls markiere ich 
die Relation als „Nicht-Route“:
abandoned:route=hiking
not:network=*
state= abandoned
Ich lösche auch Wege, wenn sie nicht mehr existieren. Das kommt aber eher 
selten vor, da sie meist nur verlegt werden.

Alles selbstverständlich nur nach eigener Begehung.

LG Robert


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

Re: [Talk-at] (Halb-)mechanischer Edit von Ärztenamen in Tirol

[Robert Kaiser]

Stefan Tauner schrieb:

Da dieses Schema für den deutschen Sprachraum unüblich ist, würde ich
das gerne auf "Dr.  " ändern (bzw. wäre ich natürlich
auch nicht böse, wenn das jemand anderer hackt ;)
Ich würde das ggf. per Overpass laden, exportieren in einem Texteditor,
mit sed oder vl. auch etwas OSM-spezifischen (Vorschläge?) ändern und
wieder hochladen. Allerdings wird es auf Grund von Doppelnamen und
anderen Uneindeutigkeiten ohne eine manuelle Überprüfung ohnehin kaum
gehen. Da fs_LT nichts dagegen hat, seh ich aber keine grundsätzlichen
Probleme. Trotzdem stelle ich das hier mal zur Diskussion, bevor ich
mich um die Details zu automated edits kümmere.


Sehe ich als eine gute Idee, besonders, wenn die manuelle Überprüfung 
auch gemacht wird.


Grüße,
KaiRo


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

Re: [Talk-at] Mapper A* beschädigt reihenweise Relationen

[Robert Grübler]

Die DWG hab ich informiert (Ticket#202009111326). 
In der Zwischenzeit sind mir 3 weitere CS mit beschädigten Relationen 
aufgefallen.
Heute der CS https://www.openstreetmap.org/changeset/88237088 mit 10 
beschädigten Relationen (alles Wander- und Radrouten).

Tut mir leid, mir ist das zuviel, ich räum den Scherbenhaufen nicht weiter auf.

LG Robert


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Marcus MERIGHI  schrieb am Sa. 19.09.2020 15:29

> ... ob diese unterschiede in den tags sac_scale 
> und trail_visibility darstellen (nix=keine unterscheidung)

In OSM ist die Schwierigkeitsbewertung mit sac_scale akzeptiert, aber:

Der Alpenverein Südtirol spricht sich GEGEN eine Schwierigkeitsbewertung von 
Wanderwegen aus [1, Seite 9] und beruft sich dabei auf einen einstimmigen 
Grundsatzbeschluss der CAA (1997, Chamonix)

Das Land  Tirol MACHT eine Schwierigkeitsbewertung der Wanderwege [2] und 
referenziert denselben Grundsatzbeschluss [2, Seite 5]

Kennt jemand die Motive für den Grundsatzbeschluss 1997 in Chamonix?

[1] 
http://media.alpenverein.it/crmpilot/Wege/Markierungsrichtlinien%20dt%20Web.pdf 
[2] 
https://www.tirol.gv.at/fileadmin/themen/sport/berg-und-ski/berg_und_ski/TirolerBergwegekonzept2018.pdf
 

LG Robert


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am 19. September 2020 15:29 schrieb Marcus MERIGHI 
[mailto:mcmer-openstreet...@tor.at]

> was sagt ihr zum vorhaben und zu den details?
Danke, unterstütze ich voll.

> 2) ich tagge, soweit mit OSM-tags moeglich, so genau es geht.
Es wäre super, das auch allen daran interessierten Mappern zu 
ermöglichen/erleichtern. 
Vielleicht über das WIKI? 
Sowohl in  DE:Wandern [1] als auch in DE:Key:sac_scale [2]
sind einige Punkte unklar. 

Beispiele in [1] 
(i) soll sac_scale wirklich optional sein?
(ii) was ist kein Wanderweg?
(iii) spurlose Wege?

Beispiele in [2]
https://wiki.openstreetmap.org/wiki/DE_talk:Key:sac_scale
Bitte diskutiert mit.

LG Robert


Referenzen
[1] https://wiki.openstreetmap.org/wiki/DE:Wandern
[2] https://wiki.openstreetmap.org/wiki/DE:Key:sac_scale


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


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

Re: [Talk-at] JOSM basemap.at Orthofoto maximale Zoomstufe

[Robert Kaiser]

Florian Kargl schrieb:

Gibt es eigentlich einen Grund warum in den JOSM image presets für das
basemap.at Orthofoto nur die maximale Zoomstufe 19 eingestellt ist? [1]
In Städten sind die Orthofotos bis Zoomstufe 20 verfügbar. [2]


An sich musst du da mit den Leuten reden, die das in die JOSM-Presets 
reingebracht haben.
Weißt du, was die basemap-API liefert, wenn man für einen Bereich die 
Zoomstufe 20 abfragt, für den sie nicht verfügbar ist? Wenn dort nciths 
bzw. ein Fehler kommt, wird such in JOSM eine Leer- oder Fehlerkachel 
dargestellt und man verliert die Möglichkeit, weiter rein zu zoomen und 
noch was auf dem sklierten Bildmaterial nachfahren zu können. Ev. muss 
man in diesem Fall 2 Presets machen mit verschiedenen Max-Zoom-Leveln, 
zwischen denen man herumschalten kann für verschiedene Gegenden.


KaiRo


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Kaiser]

Marcus MERIGHI schrieb:

1) ich kenne jetzt sechs faelle, in denen menschen auf von mir
eingetragenen steigen in bergnot gerieten. zum (und mit) glueck in
keinem fall (ganz) schlimme folgen.


Weißt du in diesen Fällen, ob sie OSM-basierte Karten verwendet haben, 
um dort hin zu kommen?
Es gibt wohl z.B. andere Karten, wo die auch drin sind, und darauf hat 
dein Handeln genau null Einfluss.


Es gibt zusätzlich auch genug Straßen, auf denen Unfälle passieren, ich 
mach mir da aber auch keine Sorgen, ob ich die in OSM eingetragen habe 
oder nicht.


KaiRo



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

Re: [Talk-at] Mapper A* beschädigt reihenweise Relationen

[Robert Grübler]

Am Donnerstag, 10. September 2020 01:09 schrieb Friedrich Volkmann 
[mailto:b...@volki.at]

> Er benutzt den Editor iD, und damit macht man fast zwangsweise Relationen 
> kaputt.
Leider kenn ich diesen Editor nur sehr oberflächlich - könnte der iD da etwas 
besser machen?

> Grundsätzlich finde ich Straßennamen wichtiger als solche Routenrelationen, 
> weil die Straßennamen Ortskenntnis verlangen, während die Routenrelationen 
> mit Sofamapping repariert werden können
Das seh ich vollkommen anders. Ist aber OT.

> ... aber wenn so ein Changeset revertiert wird, sollten dann manuell 
> die Straßennamen nochmal korrigiert werden
Der User hat den "Weis-Lamplweg" in „Radweg R1“ umbenannt!
Bei so einen Unsinn schau ich mir seine weitere Umbenennungen nicht mehr an.

> Die tausend Busrelationen sind ein Problem für sich und praktisch unwartbar.
> Seh ich genauso. Ich mach einen Bogen um jede Busrelation.

> Früher war das vielleicht anders, aber heute verschwimmen immer mehr 
> die Grenzen zwischen Unbedarftheit, Bequemlichkeit, Schlampigkeit und 
> Ignoranz und somit auch zwischen Absicht, Fahrlässigkeit und Irrtum.

Schön und treffend gesagt.
Stillschweigend akzeptieren mag ich es dennoch nicht. Zumindest aufzeigen, wenn 
es auch nichts ändert.

> Daher mein Rat: Solchen Leuten nicht zu viel auf einmal schreiben.
Guter Tipp, das könnte funktionieren.

LG Robert

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


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

Re: [Talk-at] Mapper A* beschädigt reihenweise Relationen

[Robert Grübler]

Am Donnerstag, 10. September 2020 00:26 schrieb Stefan Tauner 
[mailto:stefan.tau...@gmx.at]

> Bei Sprachverweigerung hilft die DWG wohl recht schnell mit einer 
> freundlichen Nachricht nach ;)

Gute Idee, werde die DWG um einen freundlichen Brief bitten.
"Hüft's nix, schodt's nix."
:-)

LG Robert

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


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

[Talk-at] Mapper A* beschädigt reihenweise Relationen

[Robert Grübler]

Ich möchte dem Mapper keine böse Absicht unterstellen, aber ich beginne mich
zu fragen, ob er nicht mehr Schaden, als Nutzen anrichtet.
Wenn mir eine beschädigte Relation auffällt und ich der Ursache nachgehe,
ist meist er der Täter. Beispiele:

CS 87122017 (https://openstreetmap.org/changeset/87122017)
der Edit von Straßen beschädigte 7 Relationen. Der CS war auch Thema auf
Talk-AT [1]. Den CS hab ich revertiert. Keine Antwort auf die CS-Kommentare.

CS 76715523 (https://openstreetmap.org/changeset/76715523 ) 
der Edit vom Kreisverkehr Bad Radkersburg beschädigte 12 Relationen. Keine
Antwort auf dem CS-Kommentar.

CS 76069278 (https://openstreetmap.org/changeset/76069278 )
der Edit vom Kreisverkehr Eibiswald beschädigte 7 Relationen. Keine Antwort
auf dem CS-Kommentar.

Was auffällt:
(1) keine Kommunikationsbereitschaft
(2) beim Kreisverkehr scheint er nichts gelernt zu haben

Generell antwortet der Mapper A* nur selten auf CS-Kommentare: Von 21
Kommentare in 12 CS gerade einmal 3 Kommentare in 2 CS [2].
Fehler passieren, das ist normal, aber Fehler wiederholen und die Diskussion
verweigern, das ist schon problematisch.

Wenn CS-Kommentare wirkungslos bleiben, was kann man noch tun?

LG Robert

[1]
http://osm-talk-at.1116557.n5.nabble.com/Talk-at-CS-87122017-reparieren-oder
-reverten-td3579.html 
[2] https://resultmaps.neis-one.org/osm-discussion-comments?uid=10398194



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

Re: [Talk-at] Fwd: What's new @ GeoDaten Burgenland

[Robert Grübler]

Am 7. September 2020 02:18 schrieb Stefan Tauner [mailto:stefan.tau...@gmx.at]

>> Wenn du die Einträge in https://josm.openstreetmap.de/wiki/Maps/Austria  
>> direkt änderst ...
> Hehe, auch das hab ich in der Zwischenzeit entdeckt gehabt. Ist jetzt drinnen 
> und scheint auch zu funktionieren.

Funktioniert perfekt, Danke!

LG Robert

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


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

Re: [Talk-at] Fwd: What's new @ GeoDaten Burgenland

[Robert Grübler]

Am , 6. September 2020 16:45 schrieb Stefan Tauner [mailto:stefan.tau...@gmx.at]

> Selbiges für die Steiermark:
> https://gis.stmk.gv.at/arcgis/services/OGD/als_schummerung/MapServer/WmsServer?request=GetCapabilities=WMS
> :
> Mag das von den Steirern vl. jemand an die JOSM-Devs melden?

Wenn du die Einträge in https://josm.openstreetmap.de/wiki/Maps/Austria  direkt 
änderst, stehen sie sofort allen JOSM Benutzern zur Verfügung.
JOSM nutzt diese Daten direkt beim Starten. Anleitung siehe 
https://josm.openstreetmap.de/wiki/Maps 
(Info stammt von Michael Kleidt).

LG Robert

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


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

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

[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

[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

[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

[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

[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

[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-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am : Dienstag, 1. September 2020 00:52 schrieb grubernd 
[mailto:li...@mehrzweckraum.com]

> Das einfache am Bergsteigen ist hinaufzukommen.
> Das schwierige ist wieder gesund nach Hause zu kommen.
> Und das kann einem niemals eine Karte abnehmen.

Schön formuliert, deinen ganzen Beitrag stimme ich zu 100% zu.


> … aber in diesem Zusammenhang auch unrealistisch klassifizierenden Ansatz 
> sehe.

Welche Klassifikation ist worin unrealistisch? 
Wenn du einen meiner Beiträge meinst, ich beziehe mich auf das Wegehandbuch der 
Alpenvereine (DE, AT):
https://www.alpenverein.at/portal_wAssets/docs/berg-aktiv/wege_touren/wegehandbuch_digital.pdf
 
Kapitel „1.6 Das Wegekonzept von DAV und OeAV“, PDF-Seite 25
Kapitel „1.6.3 Wegeklassifizierung“, PDF-Seite 30

Weiters auf das inhaltlich weitgehend identische, aber detaillierter 
formulierte „Wander- und Bergwegekonzept des Landes Tirol“:
https://www.tirol.gv.at/fileadmin/themen/sport/berg-und-ski/berg_und_ski/TirolerBergwegekonzept2018.pdf
 
Kapitel „3. Richtlinien“, PDF-Seiten 7 bis 11
Kapitel "3.5.11 Wanderkarten" PDF-Seite 21


Liebe Grüße
Robert

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


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am So. 30.08.2020 13:10 schrieb Marcus MERIGHI mcmer-openstreet...@tor.at

> Hier beginnst Du die Verschiebung der Verantwortung weg vom Bergsteiger, hin 
> zum Mapper.

Das ist nicht meine Absicht. Der Alpinist ist vollumfänglich für sein Tun 
verantwortlich. Das gilt aber auch für den Mapper! Am Gesamtgeschehen hat er 
sicher nur eine, vielleicht kleine,  Teil-Verantwortung. Aber Null ist sie 
nicht. Was ich erwarte:
* der Mapper kann seine Fachkenntnisse im alpinen Bereich realistisch 
einschätzen
* er arbeitet sorgfältig nach aktuellen Regelwerk
* im Graubereich entscheidet er begründbar
Zuviel?

> Du liegst grundlegend falsch, weil das eigentliche Problem umgehst.
> Dieses besteht in Menschen, die in Vollkasko-Mentalitaet nicht mehr wissen, 
> dass sie selbst fuer ihr > Leben und ihre Gesundheit zustaendig sind.
Ja, das ist das Kernproblem.

> Und nein, das ist an sich nicht lebensbedrohlich; es gehoert naemlich 
> immer noch ein Berggeher dazu, der sich nicht auskennt.
Du sagst es, es gehören zwei dazu.

> Auch Wege mit Wegehaltern (meist Naturfreunde/Alpenverein oder lokale
> Bergsteigergruppen) werden maximal einmal im Jahr abgegangen. Gerichte 
> sehen bei solchen Wegen die Wegehalterhaftung wegen der schwierigen 
> praktischen
> Durchfuehrbarkeit als eingeschraenkt.
So meine ich es auch. 

> Ich glaube ausserdem, dass eingezeichnete (Nicht-) Wege 
> die Sicherheit auch erhoehen koennen.
Durchaus möglich. Es ist eben nicht alles schwarz/weiß. Der Graubereich sollte 
aber einen nicht abhalten ein klares Ziel zu formulieren.

LG Robert

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


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am So. 30.08.2020 07:29 schrieb Stefan Kopetzky ste...@kopetzky.net:

> Grob fahrlässig im juristischen Sinne handelt von Deinen Beispielen nur
> einer: Der Nutzer.

Ich bin kein Jurist und kann daher nur die persönliche Verantwortung 
ansprechen. Klar, ein Anwender, der einer Karte/Router blind vertraut, handelt 
auch grob fahrlässig. Sicherheit umfasst alle Komponenten. Ein überwälzen auf 
den Anwender ist nur gestattet, wenn es keine technische Lösungsmöglichkeit 
gibt. Das ist hier nicht der Fall.
Sicherheit heißt Schutz gegen den ersten Fehler. Beide – Anbieter UND Anwender 
– sind in der Verantwortung.

> Das widerspricht fundamental dem Grundsatz zu Mappen "was ist" aka "ground 
> truth".
Überhaupt nicht. Es geht nur darum es richtig zu taggen. Es spießt sich an der 
Begrifflichkeit „Weg“. Ein alpiner Steig, dessen Begehung alpinistische 
Erfahrung erfordert, ist m.E. etwas anderes als ein Wanderweg, den jeder 
gesunde Mensch ungefährdet begehen kann.

LG Robert

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


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Grübler]

Am Donnerstag, 27. August 2020 22:05 schrieb Friedrich Volkmann 
[mailto:b...@volki.at]

> Darum kann ich euch nur eindringlich ersuchen, alle highway=via_ferrata, 
> denen ihr begegnet, auf highway=path zurückzuändern.

Alle? Wohl nicht.
Ein klassischer Klettersteig – das mit durchgehenden Stahlseil gesicherte, 
primäre Ziel einer Tour – ist mit highway=via_ferrata korrekt getaggt (s. 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata ). 


Meine Gedanken zum Ausgangsthema selbst:
Ein Mapper, der einen alpinen Pfad ohne Schwierigkeitsgrad aufnimmt, handelt 
grob fahrlässig. Keine Karte, kein Router kann wissen, dass es kein normaler 
Wanderweg ist.

Ein Mapper, der einen alpinen Pfad mit einem selbstbestimmten 
Schwierigkeitsgrad aufnimmt, nimmt eine große Verantwortung auf sich. Er muss 
ev. für die Richtigkeit geradestehen. Nicht nur jetzt, sondern auch zukünftig. 
D.h. er sollte den Schwierigkeitsgrad periodisch überprüfen.
Sicherheitshalber den höchsten Schwierigkeitsgrad zu vergeben ist keine 
besonders gute Idee, das untergräbt das Vertrauen in die Schwierigkeitsangabe.

Ein Kartenhersteller, eine Router, der die Schwierigkeitsangabe alpiner Pfade 
ignoriert, handelt grob fahrlässig. Das kann lebensbedrohlich sein.

Mein Resümee daraus:
Nur Bergwege – markierte und gewartete Steige mit Schwierigkeitsangabe vom 
Wegeerhalter – sollten in OSM aufgenommen werden. 
Ungewartete Steige sollten nicht in OSM aufgenommen werden. Vorhandene sollten 
gelöscht werden. Oder zumindest solange als „Nicht-Wege“ maskiert werden, bis 
ein etabliertes Tagging dafür existiert.

LG Robert

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


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

Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Robert Kaiser]

PPete schrieb:
Letztendlich bleibt die Eigenverantwortlichkeit das man sich vor so 
einer alpinen Tour über geeignetes Kartenmaterial informiert. Und 
zweitens muss man sich ev. als Kartenanbieter auch fragen ob ich 
wirklich jedes hochalpine Steiglein aus den OSM-Daten in meine Karte 
einzeichne, wenn diese darin nicht von gewöhnlichen, gefahrlosen 
Wanderwegerl unterscheidbar sind.


Ja, OSM ist nur eine Datenbank von Dingen, die in der Natur so da sind. 
Welche Karten man daraus macht, muss man sich sicher überlegen. Aber 
noch mehr, wenn man eine Bergtour macht (oder auch sonst wo unterwegs 
ist), dann muss man sich vernünftig vorbereiten und schauen, was da 
wirklich los ist, denn keine Karte ist perfekt. Und man muss sich 
besonders an lokale Beschilderungen und Markierungen halten, und wenn 
man keine findet, muss man genau wissen, was man tut, und sich nicht auf 
irgendeine Online-Quelle welcher Art auch immer verlassen.
Wer das nicht tut, dem bin ich vergönnt, dass er einen 
Bergrettungseinsatz voll bezahlen muss und ihm jede Versicherung auch 
aussteigt, und es finanziell wirklich weh tut. Körperlichen Schaden 
wünsche ich niemanden, aber auch damit muss man rechnen, wenn man sich 
nicht vernünftig informiert und "blind" irgendwelchen automatischen bzw. 
online gefundenen Quellen folgt.


KaiRo


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

Re: [Talk-at] GIS Stmk als JOSM Hintergrundbild

[Robert Grübler]

Am Sonntag, 23. August 2020 16:35 schrieb Horst Willingshofer:

> Kann mir irgendwer helfen wie ich die aktuellsten Orthofotos 
> aus dem GIS-Stmk als Hintergrundbild in JOSM verwenden kann?

solltest du schon haben - GIS Steiermark verwendet die Orthofotos von basemap.at

LG Robert



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


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

Re: [Talk-GB] New Bing Imagery

[Robert Whittaker (OSM lists)]

On Wed, 19 Aug 2020 at 15:36, SK53  wrote:
> This isn't necessarily true. If you open any OS Open Data product in QGIS one 
> is now confronted by a bewildering array of ways of converting from the OSGB 
> national grid co-ordinates to WGS84.
>
> The optimum one currently uses the 2015 file of detailed offset corrections 
> to the basic projection transformation. There was an earlier set of similar 
> data released in 2002. If one doesn't download this correction data then it 
> falls back on the basic transform using OSGB36 which can be anywhere between 
> 1 and 5 m off-true. In addition there has always been the slightly obscure 
> behaviour of OSGB projections specified in proj4 or WKT formats with respect 
> to the Helmert Transformation parameters (in early days of Open Data Chris 
> Hill & I found these were essential). At least part of the problem is that 
> EPSG:27700 appears to relate to several very slightly diverging projections, 
> whereas, for instance, Irish Grid changes are handled by EPSG:29001 through 
> EPSG:29003, and Swiss Grid CH1903 is EPSG:4149, CH1903+ is EPSG:4150 and the 
> newest CH1903+/LV95 is EPSG:2096.
>
> I don't know what transformation JOSM uses when reading EPSG:27700 so unless 
> one is very cautious it is not possible to be certain that one is anywhere 
> near the RMS 25 cm accuracy of OS data (especially as products, including 
> Boundary Line, may be partially generalised.

Perhaps this is what's causing the following problem for me then. I
GPS-surveyed a lot of the roads on my estate a few years ago when
aerial imagery wasn't so good. I've got GPS traces in OSM that
consistently follow the pavements on each side of the road and will
line up nicely with the aerial imagery if you put in the right
off-set. However, the required off-set for these traces is around 3m
out from the offset you need to make the OS OpenMap Local Functional
sites (as suggested above) line up, when I load the shapefile directly
in JOSM. This ~3m is very noticable when you have mapped buildings and
pavements sticking out into roads.

Perhaps it would be useful if someone could to do a correct
transformation of (e.g.) the OS OpenMap Local Functional Sites data to
a format and CRS that can be unambiguously read by JOSM, in order to
help our imagery alignment.

Robert.

-- 
Robert Whittaker

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

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

[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-at] CS 87122017 reparieren oder reverten?

[Robert Grübler]

Am : Freitag, 14. August 2020 19:16 schrieb Stefan Tauner 
[mailto:stefan.tau...@gmx.at]

< Wenn du nicht wirklich viele CS-Kommentare schreibst, 
< hast du einfach eine zu kleine Stichprobe

Treffer!
Hab grad nachgesehen: 37 CS Kommentare erstellt, 51% mit Antwort
Ist ja besser als gedacht.
:-)


LG Robert



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

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

[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

[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

[Talk-at] CS 87122017 reparieren oder reverten?

[Robert Grübler]

Schönen Nachmittag!

In CS 87122017  (https://www.openstreetmap.org/changeset/87122017 ) wurden
12 Wegsegmente gelöscht/ersetzt. Dabei wurden 7 Relation geändert. Zumindest
eine – der Sulmtalradweg R1- wurde dabei beschädigt. Die anderen habe ich
mir nicht angesehen.

Das Motiv des Mappers ist unklar, er antwortet auf den CS-Kommentar nicht.
Meine Vermutung: ihn störten die Wegsegmentierungen und er hat sie einfach
gemergt. Dadurch sind in der R1-Relation 2 Ausläufer entstanden.

Nun stellt sich die Frage: reparieren oder reverten? Ich tendiere zum
Revert, weil er einen falschen Ansatz verfolgte. 
Wie ist eure Meinung dazu?

LG Robert


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

Re: [Talk-at] OSM AT Erreichbarkeit

[Robert Kaiser]

Hör auf, hier kompletten Blödsinn zu verbreiten.

KaiRo

Johann Haag schrieb:

Leider wird auch die Webseite nicht gewartet, Anfragen bleiben monatelang 
unbeantwortet.
Das bedeutet, in Österreich an OpenStreetMap interessierte, werden auf ein 
Abstellgleis gelenkt.

Es ist längst an der Zeit, dass man den Wiener Verein aus der Liste 
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters 
 entfernt, und den Domain 
openstreetmap.at  mit openstreetmap.de 
 zusammenführt.

Grüsse Johann Haag
Aktueller Nr.1 OpenStreetMap Mitwirkender in Österreich


Am 13.08.2020 um 12:29 schrieb Stefan Tauner via Talk-at 
:

LWG-Sach



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




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

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

[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] National Cycle Network removal/reclassification

[Robert Whittaker (OSM lists)]

On Sat, 18 Jul 2020 at 14:49, Richard Fairhurst  wrote:
> Sustrans' own website mapping has just been updated to take account of this, 
> which you can see at https://osmaps.ordnancesurvey.co.uk/ncn . The dashed 
> lines are reclassified, while some sections have been removed entirely.
>
> It's not currently released under an open licence so not suitable for direct 
> inclusion into OSM. I will see if I can get permission for the data to be 
> used.

Sustrans' NCN data is available from
http://livingatlas-dcdev.opendata.arcgis.com/datasets/54a66fa3c15d4e118e085fbd9b141aae
as vector tiles under the ODbL. However, note that the "removed"
sections mostly won't be reflected on the ground yet. Also, the
dataset isn't perfect, as there's at least one bit near me where the
route Sustrans have is wrong. I think it's also likely that some of
the small gaps that have been created are inadvertent and will quickly
be filled back in as volunteers review the new network.

We also might need to think about our tagging, as there will now be
more levels of routes: Full NCN routes, other promoted named routes
that aren't on the NCN. How can we distinguish these in OSM?
network=ncn and network=rcn are typically used for national and
regional level routes rather than specifically the Sustrans NCN.

For anyone interested in working with the data, I'm wondering if
vector tiles is the most convenient format? Would a shapefile be
better for example? I was at Sustrans volunteer webinar last night,
and there was concern about getting various OSM-based maps and routers
updated. So if there's a more convenient data format for OSM mappers,
I think there's a good chance Sustrans would look in to it for us.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] Street-name toids

[Robert Whittaker (OSM lists)]

On Wed, 12 Aug 2020 at 16:56, SK53  wrote:
> OpenRoads from the Ordnance Survey contains a field containing the toid for 
> the street name. I wonder if we should include these alongside usrn & uprn. 
> They may be more useful than either for gathering complex roads which share a 
> name.

I'd tend to see the TOIDs are just an internal ID used in OS MasterMap
and not something that there's much value in adding to OSM. I'd have
thought that that USRN should be a sufficient unique reference number
for highways. (Everything in OS MasterMap has a TOID, and actually I
think streets have two -- one for the centreline geometry, and one for
the bounding polygon. If we start adding TOIDs for streets, where
would we stop?)

However, from a practical point of view, if you want to check OSM for
completeness against OS Open Roads, then having the TOID in OSM would
be useful. But perhaps a better solution would be to persuade OS that
they should be including the USRNs in OS Open Roads -- as these are
now the promoted 'gold standard' open unique identifiers for streets.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] Anfrage Mountainbike-Weg

[Robert Grübler]

On 12. August 2020 23:12, Friedrich Volkmann wrote:

> Die Tourismusverbände versuchen mit der Bewerbung von MTB-Routen, 
> die mehr oder weniger nur am Papier existieren, zahlende Gäste anzulocken. 
> Das grenzt an Betrug.

In der offizielle MTB-Karte der Region Graz 2020 gibt es diesen Trail nicht.
http://www.bikeculture.at/download.php?t=elements=2663 
Auch in den Karten davor, bis 2012 zurück, gab es ihn nicht.

Hier noch etwas zur Geschichte:
https://bikeboard.at/Board/showthread.php?232074-Plabutsch-neue-MTB-Strecke-geplant=2730705=1#post2730705
 


> Und dass zweitens die mtb:* Tags nur die Schwierigkeit beschreiben und nicht 
> die Berechtigung
+1 S.a.: https://forum.openstreetmap.org/viewtopic.php?id=69460

LG Robert


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


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

Re: [Talk-GB] OSMUK Instagram ideas

[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

[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

[Talk-at] Haben Kirchen eine Hausnummer?

[Robert Grübler]

Mir ist das bei der Fuchs-Kirche in Thal aufgefallen: 
https://www.openstreetmap.org/way/131989836 

Die Adresse „Am Kirchberg 1“ ist identisch zum alten Pfarrhof. Wurde sie
vielleicht von dort übertragen?
Wegen der Erweiterung der Volksschule wurde der alte Pfarrhof verkauft und
an andere Stelle neu errichtet. Die Adresse ist nun „Am Kirchberg 3“.

Was folgt daraus für die Kirche?

LG Robert


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

Re: [Talk-GB] Surveying rural buildings

[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

[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] Electric vehicle charging points

[Robert Whittaker (OSM lists)]

On Tue, 21 Jul 2020 at 23:12, Nick  wrote:
> Could the data be included in https://osm.mathmos.net/survey/ ?

I had a quick look at the National Charge Point Registry data a while
ago. I got as far as plotting a map showing both the OSM charge points
and those from the Registry:
https://osm.mathmos.net/chargepoint/progress/ . Unfortunately, the
Registry data seemed rather incomplete, and not always accurate. It
also wasn't clear exactly how to do matching between the two datasets.
I then got distracted by other things.

Due to the incompleteness of the Registry, there'd be no way to flag
OSM charge point objects that shouldn't be there. But if I could sort
out some way of matching between the two datasets, I would then be
able to add the charge points in the Registry that are "missing" in
OSM to https://osm.mathmos.net/survey/ .

-- 
Robert Whittaker

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

Re: [Talk-at] geoimage.at geändert

[Robert Kaiser]

Friedrich Volkmann schrieb:
Soll das heißen, dass ihr alle drei diese wichtige Info, von der 
zumindest du schon wusstest, dass ich darauf warte, 4 Tage lang 
zurückgehalten habt?




Kann sein, Keiner von uns wird dafür bezahlt, sich mit OSM zu 
beschäftigen und daher reagieren wir manchmal nicht sofort. Ich zum 
Beispiel war in letzter Zeit mit (bezahlter) Arbeit extrem eingedeckt 
und hab mit der kleinen Ausnahme am 6. seit mehr als einem Monat nicht 
mal Nachrichten in meinem OSM-Ordner gelesen und erst heute alles 
"abgearbeitet", was sich über Wochen zusammengetragen hat. Das 
inkludiert sogar Dinge, die meine offizielle Tätigkeit als 
Vorstandmitglied bzw. Kassier des Vereins angehen. Während manche Leute 
vielleicht ihre Zeit nur mit OSM verbringen, gibt es auch Leute, bei 
denen andere Dinge höhere Priorität haben.
Zusätzlich haben wir in diesem Fall so wei ich sehe auch auf die Antwort 
auf eine Rückfrage gewartet, und diese Antwort ist erst am 13. gekommen.


KaiRo


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

Re: [Talk-at] geoimage.at geändert

[Robert Kaiser]

Friedrich Volkmann schrieb:

On 13.07.20 08:46, Norbert Wenzel wrote:

Friedrich, mittlerweile ist ein Mail eingetroffen, mit der Bitte um eine
Änderung der URL.


Bei mir nicht und bei Robert auch nicht.


Auf dem Account, den sowohl ich als auch Norberet und Markus lesen, ist 
am 9. Juli eine Nachricht darübner eingegangen, darüber hat dir Norbert 
berichtet.
Du kannst nicht am 13. behaupten, dass ich nichts bekommen habe, wenn 
ich das am 6. gesagt habe, denn in der Woche dazwischen kann viel passieren.


KaiRo


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

Re: [Talk-GB] Paths on Wimbledon Common

[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-at] geoimage.at geändert

[Robert Kaiser]

Friedrich Volkmann schrieb:

On 26.12.19 17:36, Robert Kaiser wrote:

Friedrich Volkmann schrieb:

On 26.12.19 16:20, Robert Kaiser wrote:
Ja, das haben sie vor einiger Zeit an alle geschrieben, die bei 
Geoimage registriert sind, so auch auf unsere Info-Adresse:


Nicht an alle. Ich bin dort auch registriert und hab das Mail nicht 
bekommen.


Die Registrierung ist eigentlich fürn Hugo, weil man weder diese 
Benachrichtigungen zuverlässig kriegt noch den WMS-Server besser 
nutzen kann (obwohl das ursprünglich vorgesehen war).


Ah, interessant. Ich dachte, dass das wohl an alle rausgegangen ist 
und hab's daher nicht an die Liste hier weitergeleitet. Sorry. Ist 
aber jetzt auch geschehen.
Hoffentlich denken wir dran, wenn wieder mal so eine Nachricht kommen 
sollte.


Ist es jetzt wieder soweit? geoimage.at-Hintergrund geht bei mir 
mindestens seit gestern nicht mehr. basemap.at-Hintergründe gehen noch.




Keine Ahnung, ich sehe keine Nachricht von Geoimage.

KaiRo


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