Re: [Talk-GB] New Bing Imagery

[Silent Spike]

I contribute a bit to the development of iD and have interacted with the
current lead developer (who's currently not funded to work on it full time
anymore) as well as the previous (who's moved on to RapiD) numerous times.
As it's open source software my suggestion would be to interface using the
development channels of Github (open an issue ticket concerning supporting
the offset DB, or comment on the existing one if there is one) rather than
approaching anyone in particular. This way there is a documented place for
continued/historic open discussion.

It is unlikely you will see quick movement on this though unless someone
takes on the challenge themselves (the benefit of open source - and how
I've made additions to the software in the past). The community itself has
a responsibility to contribute to and develop open source tools if they
don't meet our needs/wants.

On Wed, Aug 19, 2020 at 4:23 PM Stephen Colebourne 
wrote:

> I'm glad I started a discussion, even if there aren't any real answers. It
> is going to be an increasing problem I fear and one I think OSM needs
> a solid answer to.
>
> In SW London, I've just checked against "OS OpenData StreetView" and all
> my edits (and thus Esri World Clarity Beta) all match pretty much exactly.
> The imported boundary data is less clear, but again it favours the current
> data where I can actually determine a difference. So. I do think Bing is
> out.
>
> Does anyone have any contacts with iD developers? From reading their
> threads it seems like they want to design a brand new perfect system from
> scratch, rather than adopt the offset DB. Since JOSM is generally more
> savvy users, it is iD I care more about.
>
> I'll contact the Amazon mapper and see if I get anywhere...
>
> Stephen
>
>
>
> On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote:
> >
> > At least it sounds soluble. Given the right transform and corrections a
> "definitive" OS point in Easting/Northing format can be translated
> accurately to WGS84 lat/long. However you look at it, I would expect a
> purely mathematical transformation should have less error than a
> transformation involving "tracing" from imagery whose rectification has
> probably also involved some of these transformations each with their own
> error terms. But I suppose that it at least partly depends on your
> definition of "perfection."
> >
> >
> >
> >
> > On 2020-08-19 16:34, 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.
> >
> > Like Jass I've been looking at various data sets which can be pulled
> into editors to help with alignment. I initially used OS Open Roads, but
> this is just too generalised to be usable in many areas. Larger buildings
> from OS Open Local, although generalised, will often have corners in the
> right place. Perhaps what we need is an equivalent of TIGER Line as a GB
> specific overlay layer showing selected alignment friendly features from
> either OS Local or Vector Map. If we could borrow styling from either TIGER
> Line or the US Forest roads it might be feasible to make such a layer.
> >
> > Jerry
> >
> > On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:
> >>
> >> On 2020-08-19 12:17, Andy Townsend wrote:
> >>
> >> On 19/08/2020 10:11, Stephen Colebourne wrote:And now I can see Amazon
> mappers using an iD variant
> >> that doesn't have the offset and moving all the roads as a result:
> >>
> https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
> >>   https://www.openstreetmap.org/changeset/89549551
> >> If that's happening at all, please comment on the changeset explaining
> the problem.  In English urban areas OS OpenData StreetView is 

Re: [Talk-GB] Paths on Wimbledon Common

[Silent Spike]

The changeset comment seems backwards to me, foot=designated is more
specific than foot=yes (which would be the default for any mapped footpath).

On Fri, Jul 10, 2020 at 1:12 PM 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?
>
>
>
> On 2020-07-10 13:54, Andrew Hain wrote:
>
> I have been doing some tidying based on Osmose, including the warning for
> highway=footway foot=yes, which is often left over from a preset in
> Potlatch 1.
>
> https://www.openstreetmap.org/changeset/87672607
>
> I got a changeset comment querying the edit.
>
>
>
>- I note you have removed foot=yes from highway=footway. My
>understanding is that the default for a footway is foot=designated, but
>designated requires an explicit sign. the paths on Wimbledon Common do not
>have an explicit sign, but are legally accessible, hence foot=yes. Perhaps
>osmose is wrong.
>- Any comments?
>- --
>- Andrew
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Farmfoods clean up

[Silent Spike]

Have you considered trying to contact farmfoods themselves to ask
for permission to use their data?

Something I've pondered in the past for branded locations as it would allow
us to get full coverage importing all the locations at once. Think the
hardest part would be getting a line of contact to someone with the
authority to approve that. Perhaps an idea that would be easier if they
were approached by the OSM UK organisation than an individual.

On Wed, May 27, 2020 at 12:24 PM David Woolley 
wrote:

> On 27/05/2020 11:48, Cj Malone wrote:
> > their homepage exclusively shows ambient products
>
> All self service stores, unless completely sold out, have ambient
> products, pretty much by definition, even open air ones at the South
> pole, if such existed, and including ones that only stock frozen
> products.  Catalogue stores might be an example of ones that didn't.
>
> Did you mean room temperature?
>
>
>
> ___
> 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] Adding Leeds Bins to OpenStreetMaps

[Silent Spike]

Hey,

I think this seems like a well planned and researched proposal. Personally
would be happy to see such an import - especially since you've already got
buy-in from the council.

Only really have two questions:
- Has the accuracy of the council data been evaluated at all? I'm
personally of the opinion that mostly accurate data is better than no data
so this is more just a curiosity.
- Could you specify those steps you'd be taking for conflation? I don't
doubt the ability to do so (this seems like a very competent proposal), but
just for transparency of the process.

On Tue, Mar 24, 2020 at 11:44 AM Patrick Lake 
wrote:

> Hi,
>
>
>
> At ODI Leeds  we’re working with Leeds City
> Council to create an up-to-date, open dataset of bins and recycling points.
> Different parts of the council have different datasets about bins and
> recycling points – e.g the bins around Leeds market are maintained by a
> different department. Nobody has a full, exhaustive list of all of them, so
> we’d like to get them all in one place.
>
>
>
> We think Open Street Maps would be perfect for this, as it’s ‘open by
> default’. We’re building them a tool using the API & OAuth so that council
> workers will be able to quickly add bins (amenity=waste_basket and
> amenity=recycling) from their phones. We’d also like to add their
> existing dataset ,
> which is published under OGLv3, to Open Street Maps. We have buy-in from
> Leeds City Council but under the import guidelines
>  we also need
> community buy-in, and we’d really like some feedback from the OSM community.
>
>
>
> Here’s a quick map we made
> 
> comparing the Leeds City Council dataset of bins (yellow markers) to the
> OSM amenity=waste_baskets for Leeds (black markers). We’re aware that there
> is probably duplicates so we’ll be taking steps to remove those.
>
>
>
> We’d appreciate any comments or feedback.
>
>
>
> Cheers,
>
> Patrick Lake
>
>
>
> ODI Leeds
>
> patrick.l...@odileeds.org
>
>
>
>
> ___
> 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] Quarterly Project Suggestion - drink_water:refill

[Silent Spike]

I support and appreciate the initiative and motivation for reducing single
use plastic water bottles, but I'm not convinced mapping this data is such
a priority for a quarterly project right now.

Unsure if it differs across the UK, but I know here in Scotland I could
pretty quickly find somewhere willing to refill my water bottle in any
populated area (which makes this refill tagging most useful in more remote
locations or for analysis/statistical purposes).

Surely there's something more relevant we could prioritise with the
currently ongoing epidemic in mind.

On Sun, Mar 15, 2020 at 6:07 PM European Water Project <
europeanwaterproj...@gmail.com> wrote:

> Hi Phil,
>
> 1) I carry a reusable water bottle with me all the time and I do fill up
> when I am traveling.
>
> 2) 1 million water bottles are manufactured every minute in the world and
> one third of plastic waste on beaches is water bottles . I added subtitles
> to this French Brut video (with their permission). It gives an overview of
> the  water bottles plastic issue.
> https://drive.google.com/open?id=1Mp6Gpq32xcxQ5OFfbI_gGELRAY4k6uV-
>
> 3) Your point about supermarket packaging is not so off topic. But, I
> think it is important not to create opposition between two important
> issues. Plastic packaging needs to be addressed as well.
>
> Combatting single-use plastic for water bottles has the advantage that
> there is an readily available cheaper alternative - high quality TAP WATER
> which everyone in Europe has access to (with very few exceptions).  I hope
> people who voluntarily adopt reusable water bottles will also become more
> ecological conscious citizens and pressure supermarkets directly and
> indirectly to reduce plastic packaging.
>
> 4) Refill UK has over 25,000 establishments and there are quite a few
> parallel networks which are very similar.
>
> I agree 100% about the lack of transparency of Refill data.
>
> Best regards,
>
> Stuart
>
>
>
>
> On Sun, 15 Mar 2020 at 18:31, Philip Barnes  wrote:
>
>> On Sat, 2020-03-14 at 18:59 +0100, European Water Project wrote:
>>
>> Hi Phil,
>>
>> I respect your opinion about the fit for the Quarterly Project. I don't
>> know enough about the project criteria to have an opinion - even if I am
>> passionate on the subject.
>>
>>
>> I do understand you passion on the subject, although it does seem to me
>> to be such a tiny problem in terms of plastic waste.
>>
>> How often do you take water when you leave home and need to refill it?
>>
>> I know this is going off-topic but a far bigger problem is the recent
>> trend for supermarkets to go back to the 70s and sell fruit and vegetables
>> in plastic packaging again, rather than weigh it at the checkout.
>>
>> This unnecessary food packaging is by far the bulk of the contents of my
>> recycling box.
>>
>>
>> With respect to the locations, there are about 25,000 in the UK and
>> Northern Ireland.
>>
>>
>> I think their lack of transparency is a big problem, licensing as
>> opendata is one issue however the website doesn't even provide information
>> in for personal use.
>>
>> What information they do provide suggests there are none in either
>> Telford or Shrewsbury, or my small North Shropshire town.
>>
>> However I have since found stickers at three on cafes in my small town,
>> there are only five in total, so quite a good uptake.
>>
>> Phil (trigpoint)
>>
>> ___
> 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] Cheers Drive, Bristol

[Silent Spike]

I once watched a conference presentation on the in-house software Google
use to update their map data (forget where I came across this). While they
didn't reveal full information on it, a large part of their workflow is
semi-automated and mostly comes down to humans reviewing and intervening in
areas flagged as problematic or requiring updates.

If I remember correctly, their sources for this information were either
user feedback ("report a map issue"); data provided directly by 3rd
parties; or data indirectly sourced from news reports and similar
(presumably using pretty sophisticated machine learning systems).

Wouldn't surprise me if this was either provided directly to Google by the
local council or flagged up by a semi-automated system.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Landuse between fences?

[Silent Spike]

While there is no formally approved proposal for tagging highway areas, I'd
direct you towards `area:highway` (
https://wiki.openstreetmap.org/wiki/Key:area:highway)

Definitely don't rely on the standard map to drive tagging practise,
rendering decisions for the standard map are made based on tag usage.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Laura Ashley - looking for tagging consensus

[Silent Spike]

Thanks for all the responses, very useful discussion and I was totally
unaware that some locations bear the additional "Home" branding.

@SK53 Looks like there's only one instance of `shop=furnishings`.

I think both of these options seem sensible:
1. Add "Laura Ashley" under `shop=clothes` and "Laura Ashley Home" under
`shop=furniture` (or similar)
2. Add "Laura Ashley" under both `shop=clothes` and `shop=furniture` and
leave it up to mappers to pick what's most suitable for their location


On Fri, Dec 20, 2019 at 11:09 AM SK53  wrote:

> Hi,
>
> I actually went and scouted out one of my local stores
> <https://www.openstreetmap.org/way/244747285> after the last post. It's
> called "Laura Ashley Home" and does furniture, fabrics etc. I never checked
> usage of shop=furnishings. In days gone by there were concessions selling
> similar wares (probably more fabrics) in Homebase.
>
> I would expect that high street shops major in clothes, retail park shops
> either furniture or a mix of the two. If "Laura Ashley Home"  is a widely
> used name then that will help.
>
> I note that there are a couple of Laura Ashley branded hotels and some tea
> rooms mentioned on the website
> <https://www.lauraashley.com/en-gb/ukc/hotels-and-tea-rooms/ha100hosp>.
>
> Jerry
>
> On Fri, 20 Dec 2019 at 00:52, Silent Spike 
> wrote:
>
>> I'm a UK based maintainer of the name suggestion index
>> <https://wiki.openstreetmap.org/wiki/Name_Suggestion_Index> and would
>> like to get this brand added. Unfortunately it's not so obvious how it
>> should be tagged and I'm not comfortable making a tagging judgement call
>> alone without consulting the UK community.
>>
>> My last thread of this nature for The Range didn't attract many
>> responses, but some input is always better than none and it allowed me to
>> get that brand into the index knowing that if consensus changes then the
>> tagging can easily be updated in OSM.
>>
>> Here's the Laura Ashley website and Wikipedia page for those unaware of
>> this chain:
>> https://www.lauraashley.com/en-gb
>> https://en.wikipedia.org/wiki/Laura_Ashley_plc
>>
>> It looks like currently there are:
>>
>>- 44 shop=clothes
>>- 20 shop=furniture
>>- 15 shop=interior_decoration
>>- 4 shop=houseware
>>- 1 shop=home_furnishing
>>- 1 shop=fabric
>>- 1 shop=fashion
>>
>> This makes sense as it seems that furniture and clothing are the main
>> items sold. The tagging alone seems to suggest `shop=clothing` is favoured
>> more - does this seem reasonable or do you think another tagging is more
>> suitable?
>> ___
>> 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] Disused or empty apartments prior to demolition

[Silent Spike]

The `building` tag actually specifies the original purpose or form of the
building - it just happens that this usually aligns with the current use.
As such, I think it's fine to leave them tagged as `building=apartments`.

See: https://wiki.openstreetmap.org/wiki/Key:building:use. Interestingly
that wiki page points to the lifecycle prefix page for the case of disused
buildings, but I'd say feel free to use `building:use=disused` to
explicitly tag them for future mappers to see.

On Tue, Dec 17, 2019 at 3:22 PM Jez Nicholson 
wrote:

> Change it to building=yes + disused:building=apartments ?...it's still a
> building, but the original use is now disused?
>
> - Jez
>
> On Tue, 17 Dec 2019, 14:51 Gareth L,  wrote:
>
>> There are some tower blocks near me which have been emptied of residents
>> ahead of eventual demolition of the buildings. They’re not coming back into
>> use due to issues with their construction.
>> http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo They’re
>> boarded up to secure them in the interim.
>>
>> All the guidance I can find on the abandoned or disused tags are to leave
>> the building as defined but to use abandoned/disused prefix on the amenity.
>>
>> These didn’t have an amenity though. They do still exist on the ground,
>> but no longer function as apartments.
>>
>> I’d like to use construction style tagging, but it doesn’t feel quite
>> right looking at all examples I’ve found. e.g.
>> Building=disused
>> Disused=apartments
>>
>> What have you used for buildings which are awaiting demolition, or are
>> undergoing a protracted demolition process but are not amenities?
>>
>> Gareth
>> ___
>> 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] The Range - looking for tagging consensus

[Silent Spike]

So I think what I'll do for now is go ahead and add this under
`shop=houseware` since both replies here are in favour of that. If in
future consensus changes (and adding this into the index is likely to bring
any disagreement that hasn't been raised here to the surface) then tagging
can always be updated at the locations confirmed to be this brand (using
`brand:wikidata`).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] The Range - looking for tagging consensus

[Silent Spike]

On Fri, Nov 8, 2019 at 12:08 PM SK53  wrote:

> So I'd favour the remaining candidates & I think housewares or homewares
> is probably a better fit.
>

The issue with houseware, if we're going by the wiki (
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dhouseware), is that it also
seems overly restrictive: "A shop that focuses on small items, like
cutlery, crockery, cookware and decorative items".

I'm actually leaning towards department store, but feel like OSM needs a
new tag to specify which departments a department store has so that we can
distinguish the huge ones from smaller ones like The Range or Laura Ashley
(another brand I've struggled with categorising).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Name Suggestion Index

[Silent Spike]

I'm a (UK based) maintainer of the NSI repository and can push changes
directly to it. I haven't been as active lately, but previously was working
my way through UK brands.

"The Range" is one I've looked at previously but never figured out the most
appropriate tagging which is why it still isn't in the index (for cases
like that I'd like to consult the community for some consensus). I'll
actually start a new thread to discuss this brand today.

"Hotel Chocolat" I believe is shop=confectionery in the index purely
because it was the established tagging. If there is some community
consensus it should be changed then that can be done (and this is why the
index is so useful, because all existing locations matched to the brand via
`brand:wikidata` could be automatically re-tagged with the preferred value).

If there are brands missing or issues with the current brand tagging I'd
suggest either:
- Open an issue on the repository (or a pull request if you're comfortable
with git and json) and all contributors will then see it
- If you don't have a github account and don't want one, just bring things
up on this mailing list (feel free to email me directly too) and I'll see
them and can either open an issue or push changes
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Silent Spike]

On Fri, Oct 25, 2019 at 1:26 PM Silent Spike 
wrote:

> The crossing=marked/unmarked tagging is inspired from a proposal I
> believe, because there is ambiguity to the controlled/uncontrolled tagging
> whereas there's an explicit obvious answer as to whether a crossing has
> markings or not.
>

For those who can't see the slack archive (don't have an account) in my
last post, the discussion points to these proposals:

https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_crossings
https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked
https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Silent Spike]

On Fri, Oct 25, 2019 at 12:57 PM Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

>
> It would also be really good if we could get the standard UK crossing
> types (zebra, pelican, toucan, pegasus) added to the iD presets to
> help UK editors add that information. Currently typing those names in
> iD doesn't give anything helpful (apart from zebra that returns
> "Marked Crossing") and there are only the marked and unmarked crossing
> options if you type "crossing" in.
>


I have floated this idea out before (
https://osmus.slack.com/archives/CBK3JLUJU/p1561914872093800) as it is now
possible to create region specific iD presets. However, the whole crossing
tagging scheme is a mess currently and iD would like to wait until
proposals are completed to clean it up before messing with crossing presets.

The crossing=marked/unmarked tagging is inspired from a proposal I believe,
because there is ambiguity to the controlled/uncontrolled tagging whereas
there's an explicit obvious answer as to whether a crossing has markings or
not.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Subject: Re: Thomas Cook shops

[Silent Spike]

It's unclear to me if there's a consensus on the tagging here. Personally I
like the `disused:` prefix.

I couldn't see if it was mentioned anywhere, but we can also query for all
the locations explicitly marked as part of the Thomas Cook brand using the
`brand:wikidata` tag: https://overpass-turbo.eu/s/MFP

All of the results here can really be automatically re-tagged as disused or
vacant since we explicitly know they were locations belonging to Thomas
Cook (the beauty of wikidata tagging). You might say some may already have
been sold and re-signed, but that can always be tagged after - we at least
know for certain that none of them are Thomas Cook travel agency shops
anymore.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Next quarters project will be fixmes and notes

[Silent Spike]

On Tue, Sep 24, 2019 at 3:38 PM Peter Neale  wrote:

> Thank you for trying to help me, but I am still confused (I'm getting used
> to that feeling!)
>
> Clearly I am missing something??
>

In your second screenshot, on the right hand toolbar, the icon ("Map Data")
underneath the "Background settings" one which you have selected. It will
open the Data panel (also shortcut F) which has "Data Layers" that can be
enabled - one of them is Notes.

I should clarify that until you hit "Edit" on the OSM website you're not
actually in the iD editor. The layers available before entering the editor
are part of the website itself, which is maintained by separately.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Next quarters project will be fixmes and notes

[Silent Spike]

On Tue, Sep 24, 2019 at 2:40 PM Peter Neale via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> Could this be changed to make all open Notes appear in the iD Edit
> window?  How could I request it?
>

There is an option to show notes under the data panel in the iD editor
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Georeferencing / zeroing imagery

[Silent Spike]

Take my answers with a grain of salt. I'm no expert, but these are from my
experience and current understanding.

On Sat, Sep 14, 2019 at 3:58 PM Edward Bainton 
wrote:

> A few questions:
> - Over how wide an area does an offset obtained that way hold good?
>

This varies, areas with large elevation differences (for example) are much
harder to truly align because the offset tends to have a much higher
variance. Even outside of factors like elevation, sometimes imagery is
consistently misaligned in one region, but inconsistently misaligned in
another. I think the key thing is to just keep checking features against
GPS; other imagery layers; and other features you know to be accurate.


> - Are the old OS maps better/worse/same as this system? Are they an
> alternative for zeroing imagery?
>

Again, no hard answer here. If there is a lot of GPS data available then I
believe it's likely more accurate to use the average of that. However, in
my experience the OS maps are at least consistently accurate enough that I
would trust them if I didn't trust the GPS data in an area.


> - If I know the grid reference of somewhere (eg, Environment Agency puts a
> 10-fig reference on a plaque on their assets) is that any help?
>

Yes, this is one method of aligning a feature. JOSM editor (for example)
allows you to create a node at specific coordinates and iD has a
hotkey-openable pane which will show coordinates at the current cursor
position. Keep in mind that the source of a feature's coordinates may not
be 100% accurate, there's always a level of uncertainty and it's easier to
decide the true position if that's known too. I believe there are also
intricacies to be aware of when converting coordinate systems, but that's a
little beyond my current knowledge.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Fixing shop=yes, now it no longer renders on the default OSM map

[Silent Spike]

On Mon, Sep 2, 2019 at 2:21 PM Jez Nicholson 
wrote:

> I don't know (yet) how iD generates its list of shop types. This may be
> hard-coded and/or pre-generated from the NSI.
>

I can shed some light on this. The "type" field (drop down list) on the
generic "shop" preset is generated from taginfo. However, there are also
specific shop presets (e.g. "Hardware Store") which are manually added in
iD's data files. Then even more specifically there are the brand specific
presets which are generated from the name suggestion index.

On Mon, Sep 2, 2019 at 2:31 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> And this is the problem. One of the shop=yes entries in Southend on sea is
> The Range. I wasn’t sure how to tag it (I was using iD for speed, and it’s
> list of defined shop tags is fairly minimal) so I tried an overpass query
> on Name=The Range.
>
> I have found, variously (aside from those without a shop tag at all)
> “houseware”, “household”, “doityourself”, “department_store”.
>

This is a common issue I run into when adding UK brands to the name
suggestion index, but it also highlights the power of having a
`brand:wikidata` tag. If all locations are identified by brand, then in
future if there is a tagging development or consensus change for that
brand, all of the locations can be easily converted because they're
explicitly marked. Along those lines, if there is ever discussion which
establishes some UK brand tagging consensus on the mailing list here I will
more than likely see it and adopt it into the index.

On Mon, Sep 2, 2019 at 1:43 PM Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> Any mappers with a few minutes to spare might like to have a look at
> their local area, and see if there are any shop=yes objects they could
> re-tag with a more specific value. Some resources to help:


Perhaps a https://maproulette.org challenge would be a good way to track
the progress of this?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Alignment at Point of Sleat

[Silent Spike]

Perfect thanks, I figured there was some imagery distortion relating to the
elevation difference along the coastline. Good to know about the OS
Streetview layer, I've never been sure how trustworthy its positioning is
until now.

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

[Talk-GB] Alignment at Point of Sleat

[Silent Spike]

Was recently at the Point of Sleat (Isle of Skye) and as part of the Q3
project was going to add the solar panels there
(https://imgur.com/a/VAE5A0L) into
OSM.

When I check out the area (
https://www.openstreetmap.org/#map=19/57.01809/-6.01793) I notice I can
also add some detail with the photographed railings so on, however it's
proven tricky to deduce the accurate alignment here. Aerial imagery seems
to show the path joining the base of the lighthouse on the east rather than
the west (as in reality) and unfortunately I forgot to take a GPX trace
while I was there.

Anyone more experienced with unclear alignment want to take a crack at this
one?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Amazon Logistics edits

[Silent Spike]

I've seen a suggestion somewhere to contact amazon about the possibility of
running street imagery cameras. Would be a great way to get many local
details available for so-called armchair mappers.

On Mon, Jul 29, 2019 at 2:14 PM Dave F via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> It would be good if they could add address data. Probably not postcodes
> - I assume they're a customer of Royal Mail's PAF, but house numbers &
> names.
>
> DaveF
>
> On 29/07/2019 13:32, Gregory Marler wrote:
> > I've exchanged a number of messages with the Amazon mappers and their
> team
> > lead Jothirnadh. First of all, if anything isn't quite right then I would
> > encourage the person who spots it to...
> > a) contact the editor about it (or better if you post a comment on the
> > changeset)
> > b) add tags yourself to further clarify the way (OSM is a wiki).
> > c) a combination of the above.
> >
> > Amazon are using OpenStreetMap (great) and they are putting in some work
> to
> > improve it (great).
> > They've been a bit behind on widely communicating with the community, but
> > they are slowly getting better. They're also working in a number of
> > countries, where similar concerns are coming up, and they're replying in
> > similar ways. They are keen to learn and do better.
> >
> > Communication certainly helps people get better. Most (all?) of us have
> had
> > something we've learnt from other mappers. Often we don't know a tag is
> > used, or we don't know the map data is used in a certain way.
> >
> > Amazon obviously have their specific interests in mapping, but so do all
> of
> > us. You're unlikely to see me adding tags for voltage of an electricity
> > line, but you may see me add the pylon.
> >
> >
> > Happy mapping everyone,
> > Gregory.
>
>
> ___
> 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] Gates open/closed by default

[Silent Spike]

On Fri, Jul 26, 2019 at 6:38 PM Martin Wynne  wrote:

> Sometimes deciding what is and isn't a gate is tricky. Is this a gate?
>

To me that's very clearly a gate 路‍♂️
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] NaPTAN/Lancashire import

[Silent Spike]

On Fri, Jul 26, 2019 at 4:08 PM Silent Spike 
wrote:

> It might be worth mentioning handling for stops present in NaPTAN which no
> longer exist.
>

To clarify, I mean stops marked as active which are no longer physically
there (implying the NaPTAN record is outdated).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] NaPTAN/Lancashire import

[Silent Spike]

No objections from me obviously!

I like that you included handling for records marked as deleted in NaPTAN.
Not something I considered until it was brought up after my import.

It might be worth mentioning handling for stops present in NaPTAN which no
longer exist. I've been following the original import surveying advice (
https://wiki.openstreetmap.org/wiki/NaPTAN/Surveying_and_Merging_NaPTAN_and_OSM_data)
to remove the bus stop tags and add `physically_present=no` (example
https://www.openstreetmap.org/changeset/72305337). It makes sense to me to
do this rather than delete the nodes so that if re-imports take place they
can be matched and the stops won't be accidentally re-added if they're
still not updated in NaPTAN.

Along those lines, you may want to update the overpass conflation query to
include such features:

> [out:xml][timeout:25][bbox:{{bbox}}]; (
> node["public_transport"="platform"]; node["highway"="bus_stop"];
> node["naptan:AtcoCode"]; ); (._;>;); out meta;
>

 We could perhaps update much of the wiki pages to reflect that they are
historical from the original import and establish a new page for best
practises dealing with NaPTAN data in OSM.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Gates open/closed by default

[Silent Spike]

On Fri, Jul 26, 2019 at 1:15 PM Martin Wynne  wrote:

> The tag is *barrier*=gate.
>
> A permanently open gate isn't a barrier, so I don't think it should be
> tagged as such. At least not across a way.
>

It's a common mistake to interpret keys to match their corresponding word
definitions. The gate exists and physically could be closed, therefore
should be mapped as a normal gate.

I've encountered one situation like this in the past which I decided to tag
as `permissive` at the time (https://www.openstreetmap.org/node/1823375898).
My logic is that (while this is a privately owned gate) the owner of the
gate has decided to leave it open for traffic to pass through the gate,
therefore access through the gate is permissive, but could be taken away
(therefore it would be false to tag it in a way that suggests access will
always be available). Note that I also tagged vehicle access as private,
because this is a gate which always seems to be half closed - but access
could physically be granted for vehicles if needed.

I think the key is to tag the gate's access separate from the way's access
(as Stephen suggests) because they are different things.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] NaPTAN Aberdeen Import Completion

[Silent Spike]

Just an update to say the import has been completed.

I wrote a diary entry to share some insight (
https://www.openstreetmap.org/user/TheEditor101/diary/390283), but no doubt
forgot to mention something so feel free to ask me anything.

Now it's time for me to start confirming stop details and fixing
discrepancies.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 8:04 AM Silent Spike 
wrote:

> Using the following established tags:
>

After all discussion so far I would update the list of tags to import as
follows:

   - `highway=bus_stop`
   - `public_transport=platform`
   - `bus=yes`
   - `name` [Imported - defer to existing tagging during conflation]
   - `naptan:AtcoCode` [Imported]
   - `naptan:NaptanCode` [Imported]
   - `naptan:CommonName` [Imported - should match `name` but may differ, is
   what the indicator is relative to]
   - `naptan:Indicator` [Imported - useful to distinguish stops and
   sometimes can be `loc_ref` data]
   - `naptan:verified=no` [Gets deleted upon verification according to the
   wiki]


I've checked and none of the stops here have Gaelic names (`name:gd`) -
though my script now supports them for import anyway. I also feel like
`source=naptan` is unnecessary since `naptan:verified` is basically the
same thing and the changeset(s) can have a source tag.

I'm trying to keep the amount of data somewhat minimal in line with the
following quote from the imports guidelines wiki page:

> However, don't go overboard with metadata. OSM is only interested in what
> is verifiable <https://wiki.openstreetmap.org/wiki/Verifiable>. This
> doesn't include (for example) foreign keys from another database, unless
> those are absolutely necessary for maintaining the data in future. Your
> data source may have many many fields, but OSM data elements with many many
> tags can be difficult to work with. Strike a balance. Figure out (discuss!)
> what fields the OSM community are interested in.
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:41 PM Andy Townsend  wrote:

> The most interesting bit would be the "Manually conflate and review the
> data before upload using JOSM" - any JOSM CSS style that you end up using
> to highlight duplicates would be really useful, as would a basic OSM diary
> entry describing the process and the end result.
>

Would be happy to write an entry about my process if it comes to fruition.
I suspect it won't be as interesting as you might imagine since there's
really not a huge existing coverage of stops in the area. However, anything
to help future mappers also interested in this available data.

By downloading only bus stops in JOSM from the overpass API can easily see
where duplicates exist just by proximity to the NaPTAN stops. Have
considered expanding my script to also assist in conflation (marking
possible duplicates for manual review before upload), but for the Aberdeen
area it's probably not worth it.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:33 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> what did you have in mind? To the end-user of the data (i.e. someone
> wanting to know about where to catch the bus) this is absolutely critical.
>
> For example, in my previous post I face a suggestion of “Stuart Close”
> with an indicator of “adj”. There would usually be a second stop of the
> same common name, Stuart Close, perhaps with the indicator “opp”. Without
> understanding the NaPTAN schema, “app Stuart Close” and “adj Stuart Close”
> are understandable and are service direction dependent.
>

Well I was just thinking they're often descriptive abbreviations (and
admittedly aren't hard to deduce) with limited possible values as per the
NaPTAN schema. However, if it's just following the NaPTAN schema is there a
point in including it in OSM if that data is available and more up to date
there? While tags such as the stop name have corresponding tags in OSM
which have use to consumers who are not strictly following the NaPTAN
schema.

I'm certainly not against it's inclusion and would defer to your opinion
that it's useful data.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 1:02 PM Gareth L  wrote:

> Forgive me if this is silly question/statement, but the adj/alt names etc
> are in the naptan dataset. Wouldn’t it be better to have the link made
> between the stop in OSM and the record in naptan (using the codes prior
> mentioned).
> My thinking is data consumers could link and retrieve values using that.
> Merging the extra data values again might potentially develop discrepancies
> over time.
>
> I’d think the atco code is unique and (hopefully) not reused, but the alt
> names etc could be modified over time.
>

A perfectly valid question and something I wonder also.

For example, the indicator field is somewhat meaningless to a data consumer
unless they know what it represents as per the NaPTAN schema - so perhaps
it's best left out of the OSM data?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 11:35 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> -snip-
>
> Hope that helps.
>

Pretty much the perfect response, thank you!

Good point about alternate names, will add support for those to my script
now (maybe unnecessary for my area, but I'd like to share it in future). I
see that many of the English alternate names are nearby landmarks or
features (e.g. "The Crossroads"). Should I include these too as `loc_name`
or similar (open question to all)?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:52 AM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> Yes, both are still in use
>
> -snip-
>
> Regards,
> Stuart Reynolds
> for traveline south east and anglia
>

As someone more in the know, are there any fields of the NaPTAN data which
you think should be imported which I haven't included?

___
> 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] Importing NaPTAN Data [Thread 2]

[Silent Spike]

On Fri, Jul 5, 2019 at 10:17 AM Mateusz Konieczny 
wrote:

> I reformatted
> https://wiki.openstreetmap.org/wiki/Key:naptan:AtcoCode
> https://wiki.openstreetmap.org/wiki/Key:naptan:NaptanCode
> (added templates making them machine readable, descriptions will appear
> for example at Taginfo)
>

Thank you, documentation of the tags imported previously has definitely
been lacking


> Is it useful to use both? What is the difference between them?
> Is NaptanCode actually used as planned ("referring to the stop in public
> facing systems")?
>

Of this I'm personally unsure, however there's not much harm in it and it
seems standard enough practise


> It may help to include example (of full) .osm data file to make easy for
> mappers
> to judge data quality in their area.
>

Here is a single file with all stops which I would be importing for the
Aberdeen area (
https://drive.google.com/open?id=1_QWn02Gi0YG8GCza0CeNQXtIKM_J82Y0), if
split into subdivisions there are 63 areas in total within this.


> ___
> 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] Importing NaPTAN Data [Thread 2]

[Silent Spike]

Since the other thread has become a tagging discussion on the pros and cons
of PTv2, let's try this again.

Would there be any objections to an import of the following scope:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload using JOSM
   5. Split the edits up according to the "LocalityName" data field
   (basically districts)  [or is it better to be one changeset for the whole
   area?]



Using the following established tags:

   - `highway=bus_stop`
  - `public_transport=platform`
  - `bus=yes`
  - `name=*` [Imported]
  - `naptan:AtcoCode=*` [Imported]
  - `naptan:NaptanCode=*` [Imported]
  - `source=naptan`
  - `naptan:verified=no`

Alternatively, if you support the proposal then it's also useful to know 

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

Re: [Talk-GB] Importing NaPTAN Data

[Silent Spike]

This is getting a little bit off topic. I guess to bring things back on
track, would there be any objections to an import along these lines:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload using JOSM
   5. Split the edits up according to the "LocalityName" data field
   (basically districts from what I can tell)  [or is it better to be one
   changeset for the whole area?]
   6. Tag the stops using:
  - `highway=bus_stop`
  - `public_transport=platform`
  - `bus=yes`
  - `name=*` [Imported]
  - `naptan:AtcoCode=*` [Imported]
  - `naptan:NaptanCode=*` [Imported]
  - `source=naptan`
  - `naptan:verified=no`



___
> 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] Importing NaPTAN Data

[Silent Spike]

On Thu, Jul 4, 2019 at 4:40 PM Martin Wynne  wrote:

> In rural areas there are many places where buses are timetabled to stop
> but where there is nothing physical -- no signpost or shelter.
>
> Are these highway=bus_stop in OSM?
>
> The wiki for highway says "Can be mapped more rigorously using
> public_transport=stop_position for the position where the vehicle stops
> and public_transport=platform for the place where passengers wait.
>

I believe such stops would just be mapped with stop positions. However, I
don't intend to import them currently as I'd need to look into that more
in-depth (and want to keep things simple for now). Just getting the
physical stops imported seems like a good first step which would have the
most significant improvement on available data in OSM.

___
> 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] Importing NaPTAN Data

[Silent Spike]

On Thu, Jul 4, 2019 at 4:10 PM Dave F via Talk-GB 
wrote:

>
> Please, please don't use public_transport=platform unless you're
> actually mapping an actual, physical, raised object, similar to railway
> platforms.
>
> It has now been regressed one stage further, being superfluously added
> to highway=bus_stop nodes. So much of the PT schema is just duplicating
> valid, existing data which leads to confusion & errors. It is a waste of
> time & effort.
>

My understanding is that `public_transport=platform` is any place where
public transport can be accessed and should not literally be interpreted as
a physical platform (tags not literally matching what they are used to map
seem to be very common in OSM). I think if you want to constructively
change tagging practise you need to discuss it on the tagging list and that
the import I would like to do should follow established tagging.

If anything `highway=bus_stop` is redundant data, however it's necessary
for render compatibility (violating the "don't tag for the renderer rule",
but everyone does it because default render still doesn't support PTv2
scheme).

Until the wider OSM community establishes better methods of tag creation
and deprecation these issues will continually crop up and (in my opinion)
should not impede mapping progress.


> ___
> 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] Importing NaPTAN Data

[Silent Spike]

On Tue, Jul 2, 2019 at 11:07 AM Ed Loach  wrote:

> highway=bus_stop
> public_transport=platform
> source=naptan
> naptan:verified=no
> name=(NaPTAN name)
> naptan:AtcoCode=(whatever)
> naptan:NaptanCode=(whatever)
>
> If the bus stop type is not MKD I add
>
> naptan:BusStopType=(bus stop type)
>
> and if the status is not "act" I add
>
> naptan:Status=(status)
>

These tags all seem reasonable to import to me. Would be curious to learn
more about your route maintenance process. I have a list of local bus route
relations I've been meaning to update, but it's hard to do so without all
of the stops mapped (hence my desire to import the available data).


> ___
> 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] Importing NaPTAN Data

[Silent Spike]

On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> In may experience, a lot of the original NaPTAN imports have decayed:
>
> - people have double mapped stops and the the NaPTAN one has been deleted;
>
> - stop have moved and got double mapped and deleted as a result;
>
> - stops have been temporarily out of service, e.g whilst redeveloping a
> bus station, and been deleted and then lost the NaPTAN associations when
> remapped.
>

I'm not sure why double mapping is occurring, but it seems to me that (even
with these mapping mistakes) having the stops present in OSM is better than
not using the data at all. If conflation can be done once, it can be
repeated in future if data needs to be imported as an update.

 On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> Also, all bus stops need continual maintenance because names get changed
>   as landmarks come and go.
>
> Given that few people like maintenance work, if you can't map all the
> stops from first principles, it is very unlikely that imported ones will
> get maintained.  Retaining the NaPTAN tagging is important in allowing
> any later remerge of the updated NaPTAN data.
>

I gather that you're suggesting future data imports will be needed to keep
stop data up-to-date and so the NaPTAN tagging is needed to make that
process easier? In which case I agree, although I still don't see what use
the tags other than the NaPTAN ATCO code provide. It appears to be a stable
identifier, which means by including it in OSM the NaPTAN data is directly
associated with the tagged OSM element (reducing the need to maintain
tagging in OSM).

 On Tue, Jul 2, 2019 at 10:00 AM David Woolley 
wrote:

> Another problem with NaPTAN stops, which applies to non-OSM users as
> well is that they have virtual stops in Hail and Ride areas.  Routers
> seem to only like people boarding at those place, so, in my case, can
> take me about 7 minutes out of my way against the direction of travel,
> so tell me I have missed a bus that could be easily caught


At present I don't intend to include hail and ride data in my import
process. Would need to investigate further how best to handle it and I'm
personally only interested in clearly marked bus stops.
 ___

> 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] Importing NaPTAN Data

[Silent Spike]

Hey Tony,

Glad to hear I'm not the only person interested in using this data!

Wasn't aware of the conflation plugin, will have to give it a look now.
Always interested in collaboration, sounds like you've come to the same
conclusion as myself regarding getting import authorisation.

Cheers

On Mon, Jul 1, 2019 at 5:15 PM Tony Shield  wrote:

> Hi Spike
>
> I'm interested in importing my local area - Chorley, Lancashire.
>
> I've filtered the Naptan file to get Chorley csv file. I've then imported
> into JOSM conflation plug-in. I'm starting to understand how the conflation
> tool functions and I think the results are good. I've done several dry runs
> to get the technique correct. I'm planning to manually review each bus stop
> - not too bad when there are 3-400.
>
> I too am trying to realise what Naptan codes and fields need to be
> populated for each bus stop, and agree with following the PTv2 scheme.
>
> I haven't performed the import as I haven't been through the import
> authorisation process, and as Naptan is an established data import I think
> that it will not be too difficult as long as the process is correct.
>
> Happy to work with you if you wish.
>
> Regards
>
> TonyS999
>
>
> On 01/07/2019 16:02, Silent Spike wrote:
>
> Hey folks,
>
> I'm interested in importing NaPTAN bus stop data (
> https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my
> area of the UK (Aberdeen).
>
> As far as I can tell, some progress was made previously on importing
> NaPTAN data for specific areas of the UK. However, the process for
> requesting an import on the wiki seems to have broken down somewhere along
> the line and I believe the python script mentioned on the wiki is outdated.
>
> I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN
> csv bus stops file into OSM XML which I can import using JOSM. I'm
> splitting the data into files by local area - here's an example of an area
> I'm familiar with (https://i.imgur.com/xE7TF2c.png) where you can see the
> import data (blue) line up well with the existing data (black).
>
> My plan for conflation was basically to do it by hand since I'm familiar
> with the area and can take my time to do each local area individually.
> However, I could probably also set up some data matching by checking the
> stop names and offsets of existing data.
>
> As for tagging, I'm unsure what the current status is regarding the
> `naptan:` namespace. Looking at those tags, they all seem pretty useless to
> me (except `naptan:AtcoCode` as an identifier). Currently I'm just using
> roadside bus stops marked with a shelter or pole and following the PTv2
> scheme to tag them as `highway=bus_stop`, `public_transport_platform` and
> `bus=yes`.
>
> If anyone has any suggestions or input please let me know! Obviously I
> won't be importing anything without some community approval first.
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://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] Importing NaPTAN Data

[Silent Spike]

Thanks for sharing your insight and expertise Stuart.

I can see why there might be resistance to importing data. Personally, I
take the view that it saves a lot of time even if it's not perfect
(progress being incremental and all). The majority of bus stops near me in
OSM were added by myself and that's taken a long time. If the data had been
imported already then it would be much quicker to see where stops are and
then simply verify/update the data that's there. With that in mind, that's
basically all I'm proposing - a set of human reviewed mechanical edits
specifically for the Aberdeen area as I'm familiar with it. Looking at the
data already I can see that most of it matches up with bus stops I've
mapped and some are a couple of meters off the true position.

To more accurately define the scope of what I'd like to do:

   1. Import data specifically for the Aberdeen admin area (ATCO code 639)
   2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
   3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
   4. Manually conflate and review the data before upload
   5. Split the edits up according to the "LocalityName" data field
   (basically districts from what I can tell)

If I'm able to make it through that process then a methodology will have
been established which perhaps others can use for their areas too. Then
perhaps I can investigate other types of stop (hail and ride, custom,
flexible) and transport.

As for `naptan:` tagging (
https://wiki.openstreetmap.org/wiki/NaPTAN/Tag_mappings), I guess I'm just
not sure why much of that data has to be present in OSM. Surely just the
identifier is enough as it provides a link to the NaPTAN data itself.


On Mon, Jul 1, 2019 at 4:21 PM Stuart Reynolds <
stu...@travelinesoutheast.org.uk> wrote:

> Hi Spike,
>
> There are two aspects to your question. The first is around mechanical
> edits (i.e. importing NaPTAN), and I’ll defer to the group for that because
> while I would like to use NaPTAN (matained, mostly) to update OSM (not
> maintained, mostly) across the UK, there is resistance to that - and it is
> because of that “mostly” issue, because in some areas bus stops have been
> more accurately surveyed.
>
> However, one of my many hats (as a consultant) is as the DfT’s “Public
> Transport Data Standards” expert (Transport is a devolved power, but the
> Scottish Parliament usually keeps Scotland broadly aligned with England).
> If you want to know specific things about NaPTAN fields, then I can tell
> you what they are for and why we need them - either email me direct, or
> reply here if you think that it would be more widely interesting. That is
> particularly true of stop points which are “Custom & Practice” or “Hail &
> Ride” which are not marked on the ground at all (so are perhaps irrelevant
> from a mapping perspective), but are nevertheless valid stopping points
> (and very important from a PT perspective)
>
> As a general note to both you and the wider community, the (English) Bus
> Services Act 2017 provides powers to compel Local Authorities to maintain
> NaPTAN data, and there are steps being discussed to assist in bulk
> “improvements” to the stop data ahead of the timetable provision which is
> intended to commence Jan 2020, mandatory by Jan 2021 (these dates all in
> the public domain, by the way). There is a similar Bill going through
> Holyrood at present, but I don’t know precisely what powers it will contain
> or what dates it will mandate.
>
> Regards,
> Stuart Reynolds
> for traveline south east and anglia
>
> On 1 Jul 2019, at 16:02, Silent Spike  wrote:
>
> Hey folks,
>
> I'm interested in importing NaPTAN bus stop data (
> https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my
> area of the UK (Aberdeen).
>
> As far as I can tell, some progress was made previously on importing
> NaPTAN data for specific areas of the UK. However, the process for
> requesting an import on the wiki seems to have broken down somewhere along
> the line and I believe the python script mentioned on the wiki is outdated.
>
> I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN
> csv bus stops file into OSM XML which I can import using JOSM. I'm
> splitting the data into files by local area - here's an example of an area
> I'm familiar with (https://i.imgur.com/xE7TF2c.png) where you can see the
> import data (blue) line up well with the existing data (black).
>
> My plan for conflation was basically to do it by hand since I'm familiar
> with the area and can take my time to do each local area individually.
> However, I could probably also set up some data matching by checking the
> stop names and offsets of existing data.
>
> As for tagging, I'm unsure what the current status is

[Talk-GB] Importing NaPTAN Data

[Silent Spike]

Hey folks,

I'm interested in importing NaPTAN bus stop data (
https://wiki.openstreetmap.org/wiki/NaPTAN/Import) specifically for my area
of the UK (Aberdeen).

As far as I can tell, some progress was made previously on importing NaPTAN
data for specific areas of the UK. However, the process for requesting an
import on the wiki seems to have broken down somewhere along the line and I
believe the python script mentioned on the wiki is outdated.

I went ahead and wrote a 5 minute python 3 script to convert the NaPTAN csv
bus stops file into OSM XML which I can import using JOSM. I'm splitting
the data into files by local area - here's an example of an area I'm
familiar with (https://i.imgur.com/xE7TF2c.png) where you can see the
import data (blue) line up well with the existing data (black).

My plan for conflation was basically to do it by hand since I'm familiar
with the area and can take my time to do each local area individually.
However, I could probably also set up some data matching by checking the
stop names and offsets of existing data.

As for tagging, I'm unsure what the current status is regarding the
`naptan:` namespace. Looking at those tags, they all seem pretty useless to
me (except `naptan:AtcoCode` as an identifier). Currently I'm just using
roadside bus stops marked with a shelter or pole and following the PTv2
scheme to tag them as `highway=bus_stop`, `public_transport_platform` and
`bus=yes`.

If anyone has any suggestions or input please let me know! Obviously I
won't be importing anything without some community approval first.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] DoBIH Update - Permission Received

[Silent Spike]

Yes I think we could establish which entries are suitable for use (i.e.
those with an entry in the "survey" field of the database) and note this
guideline on the wiki under third party data here
.
Perhaps introduce a standard of tagging "source=DoBIH" where the data has
been used.

On Mon, Feb 25, 2019 at 8:29 AM Steven Horner 
wrote:

> I would think it would be the actual surveyed heights and exact locations
> that would be the most use for OSM. Could we not use only the ones that
> have been surveyed in the DoBH data, then this could not be claimed to be
> Ordnance Surveys data.
>
> Regards,
> Steven
>
> On Sun, Feb 24, 2019 at 12:14 AM Andy Townsend  wrote:
>
>> On 23/02/2019 23:04, Adam Snape wrote:
>> >
>> > Most of the heights should be derivable from OS Open Data mapping layers
>>
>> ... or from out of copyright OS data.  Hills don't change their height
>> much over a human timescale.
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] DoBIH Update - Permission Received

[Silent Spike]

Starting a new thread as I noticed the old one is somehow entangled with
the M1 Junction thread on the archive (see "Database of British and Irish
Hills").

I have a signed copy of the CC BY 3.0 permission document, received from
Chris Crocker who handles copyright and licensing issues on behalf of the
DoBIH editorial team. So as far as the DoBIH is concerned, OSM may
incorporate the data in their database if attribution is added as per the
document.

Regarding the raised point on derived data, I had mentioned this to Chris
in our correspondence and he first explained:

I don't believe you need any other permissions to use data from the DoBIH.
> OS maps, being creative works, are subject to Crown copyright and OS
> requires an acknowledgement for their reuse, but I have always understood
> that heights and grid references are scientific fact and as such are not
> copyrightable. Certainly there are hundreds of commercial publications in
> the hillwaking world that tabulate such data. None of those that I've read
> do more than mention OS maps as the source of their data. The OS data we
> use is derived from the maps on geograph.org.uk which gives OS mapping at
> all scales from 1:250,000 to 1:10,000. According to the site the Geograph
> maps are licensed under the OS OpenSpace Developer Agreement. I note that
> your Contributors page credits Ordnance Survey OpenData. Other heights and
> grid references are derived from the Environmental Agency's LIDAR surveys
> which are freely available on the DEFRA platform, from detailed hill
> surveys conducted by ourselves and third parties who supply data to us, and
> from numerous walkers who submit 10-figure grid references (these are
> responsible for over 60% of summit GRs).


 Later sharing some more insight on the subject:

There is greater clarity in the more litigious US, where it has been
> established in US copyright law that most data are considered "facts", i.e.
> belonging to the domain of knowledge (a public benefit), and therefore not
> copyrightable. This was clarified in an addendum that reads “*In no case
> does copyright protection for an original work of authorship extend to any
> idea, procedure, process, system, method of operation, concept, principle,
> or discovery, regardless of the form in which it is described, explained,
> illustrated, or embodied in such work.*” The effort in obtaining the data
> is irrelevant. In essence, observational and experimental data are “facts”
> that are free to be shared and reused without copyright restriction. The
> only data that are copyrightable are those containing what the US calls
> expressive choice, such as photographs, drawings, graphs or visualisations
> (but you would be free to make your own drawing from a photograph or a map,
> as Wainwright did). There is nothing to contradict this in the UK Copyright
> and Patents Act, which specifies "Any literary, dramatic, design, musical
> or artistic work". The requirement in both the US and Europe is creativity.
> So the way data is structured (e.g. the grouping of hills into Catchments
> and Watersheds in the DoBIH) might be copyrightable.
>
> Database right, which is applicable to the DoBIH in the EU, is something
> different. It protects the structure of a database, provided there is
> sufficient intellectual creativity (dumping data into a spreadsheet is not
> enough!), but not on its own the data inside it. However database right
> protects against the abstaction of a substantial proportion of a database
> without permission.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Database of British and Irish hills

[Silent Spike]

I got in touch with Chris Crocker who is listed on the DoBIH homepage as a
contact (and as it turns out is a very friendly and knowledgeable person).
I'm quoting here his initial response (with permission to share it) to
further discussion:

We would be happy to see DoBIH data used in OpenStreetMap. One of the
> motivations behind the creation of the DoBIH in 2001 was to resolve
> conflicting sources of information on the web by providing a database that
> we hoped would be definitive. We've had some success as two-thirds of
> hillwalking websites and all the current smartphone apps take data from the
> DoBIH.
>
> I don't have a problem with signing your document but I'll run it past the
> other editors.
>
> I don't believe you need any other permissions to use data from the DoBIH.
> OS maps, being creative works, are subject to Crown copyright and OS
> requires an acknowledgement for their reuse, but I have always understood
> that heights and grid references are scientific fact and as such are not
> copyrightable. Certainly there are hundreds of commercial publications in
> the hillwaking world that tabulate such data. None of those that I've read
> do more than mention OS maps as the source of their data. The OS data we
> use is derived from the maps on geograph.org.uk which gives OS mapping at
> all scales from 1:250,000 to 1:10,000. According to the site the Geograph
> maps are licensed under the OS OpenSpace Developer Agreement. I note that
> your Contributors page credits Ordnance Survey OpenData. Other heights and
> grid references are derived from the Environmental Agency's LIDAR surveys
> which are freely available on the DEFRA platform, from detailed hill
> surveys conducted by ourselves and third parties who supply data to us, and
> from numerous walkers who submit 10-figure grid references (these are
> responsible for over 60% of summit GRs). We acknowledge all sources and
> contributors in the Database Notes as you have observed.
>
> You might have noticed that our popular Hill Bagging website, which hosts
> the interactive version of the database, recently added links to OSM on
> each hill's data page. See for example
> http://www.hill-bagging.co.uk/mountaindetails.php?qu=S=278
>
> I expect the DoBIH could contribute much to OSM, but personally I am too
> busy maintaining the DoBIH to do so myself! I probably speak for the other
> editors too. I believe one of our users, who goes under the name of 
> Talkytoaster
> on your forum, has contributed to OSM for many years.
>
Regards

On Tue, Feb 12, 2019 at 11:28 AM Andy Townsend  wrote:

> On 11/02/2019 23:31, Silent Spike wrote:
>
> I recently came across the DoBIH
> <http://www.hills-database.co.uk/downloads.html> which you can see is
> licensed under CC BY 3.0.
>
>
> At least one user claims already asked for permission to use this data:
>
> https://www.openstreetmap.org/changeset/36758689
>
> (I've not seen anything public from that source though, and of course
> whether they gave permission doesn't address whether some of the data has
> actually come from another source first, such as the OS).
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] Database of British and Irish hills

[Silent Spike]

On further thought I'll just go ahead and do it with my real email.

Will share the response here if/when it comes.

On Mon, Feb 11, 2019 at 11:31 PM Silent Spike 
wrote:

> I recently came across the DoBIH
> <http://www.hills-database.co.uk/downloads.html> which you can see is
> licensed under CC BY 3.0.
>
> This could be a valuable source of accurate height and position
> information for "natural = peak" nodes in the UK + Ireland (maybe even an
> import candidate).
>
> Would anyone be interested in requesting permission following the wiki
> guidelines <https://wiki.openstreetmap.org/wiki/Import/Getting_permission>?
> I'd do it myself, but it would probably be more professional coming from
> someone else.
>
> Regards
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Database of British and Irish hills

[Silent Spike]

I recently came across the DoBIH
 which you can see is
licensed under CC BY 3.0.

This could be a valuable source of accurate height and position information
for "natural = peak" nodes in the UK + Ireland (maybe even an import
candidate).

Would anyone be interested in requesting permission following the wiki
guidelines ?
I'd do it myself, but it would probably be more professional coming from
someone else.

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

[Talk-GB] Mapping Driving Test Centres

[Silent Spike]

Searching the wiki I can't find anything that feels right for mapping
driving test centres.

If anyone has mapped these in the past I'd be curious to know how you
tagged them (both practical and theory test centres).

Also curious as to how they've been named (if at all) as the DVSA just
refers to them by where they are located.

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

Re: [Talk-GB] Rendering Problems

[Silent Spike]

I've noticed my edits yesterday are not yet rendered (usually almost
instant). Presumably just a temporary slowdown due to heavy load or
something.

On Fri, Jan 18, 2019 at 10:31 AM Gareth L  wrote:

> I’ve noticed. A bunch of edits around Rugby (by you, I think?) are only
> being rendered on humanitarian tiles.
> Gareth
>
> > On 18 Jan 2019, at 09:50, Brian Prangle  wrote:
> >
> > Has anyone else noticed problems with edits failing to render?. Stuff I
> did 2 days ago still not showing up
> > ___
> > 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] Spam GPS traces

[Silent Spike]

Ah thank you, that explains it!

Although I couldn't find any previous talk on the matter, but did find the
relevant potlatch commit diff

(for
anyone else curious like me).

On Wed, Nov 14, 2018 at 5:37 PM Tom Hughes  wrote:

> No that's the effect of us (correctly) anonymising the order of points
> in private and public traces.
>
> Potlatch has been fixed to handle it but JOSM hasn't (yet).
>
> See previous talk thread for more.
>
> Tom
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Spam GPS traces

[Silent Spike]

Hi folks,

I'm editing this area (
https://www.openstreetmap.org/#map=17/57.17591/-2.12320) in JOSM and the
GPS data in the area contains some traces uploaded which look like spam
(loads of horizontal lines which seem to form the shape of the river and
other features).

I'm unsure of the extent of the data, but it looks as though they are all
marked as recorded from 01/01/70 01:00 - 01:00.

Is there somewhere to report this so that they can be removed? I had a look
around the wiki and found the data working group, but it's not clear
whether they deal with GPS traces and I couldn't find anywhere that
specifically discusses them except a figure caption on the page for
vandalism.

Here's a screenshot from JOSM  since
private traces aren't visible on the website
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb