Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Warin]

Don't use landuse=grass.

Use surface=grass and/or landcover=grass to state the land cover, I'd 
use these with the power=plant tag.


(For those that don't know .. I hate the tag landuse=grass)

On 05/04/19 02:38, SK53 wrote:
Yup, I don't think industrial is appropriate in many circumstances, 
any more than it would be for an area of wind turbines on moorland. 
For instance I've seen sheep grazing in between the panels (which IIRC 
are mounted on heliostats) on this solar farm: 
https://www.openstreetmap.org/way/168359464#map=15/39.8239/-5.6562=N. 
I presume that after installation the ground is more-or-less as it was 
(not for instance contaminated as is the case of many rural industrial 
areas, nor with traffic of heavy goods vehicles).


Jerry

On Thu, 4 Apr 2019 at 16:25, Russ Garrett > wrote:


On Thu, 4 Apr 2019 at 16:18, Mateusz Konieczny
mailto:matkoni...@tutanota.com>> wrote:
> Why not? If area is covered by solar panels then it is used for
power generation.
> And power generation seems clear case of industrial use

I guess it is. I just think "industrial" carries a number of
connotations which solar power doesn't have. Also, in some cases the
land under/around solar farms is used for grazing, or at any rate it's
still mostly grass. I'm not too bothered either way, though.

Cheers,
-- 
Russ Garrett

r...@garrett.co.uk 




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

Re: [Talk-GB] Removal of redundant NaPTAN data

[Ed Loach]

The interactive map on the plusbus site, e.g. 
http://www.plusbus.info/clacton-on-s perhaps has a better display as it shows 
the individual stops and perhaps rather than having the area mapped we should 
add a naptan tag to the stop nodes (for signposted stops I tend to just add 
naptancode and atcocode for stops that are new since the original import, e.g.

https://www.openstreetmap.org/node/4942644320

)

 

Ed

 

From: SK53  
Sent: 04 April 2019 16:17
To: Andy Townsend 
Cc: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Removal of redundant NaPTAN data

 

Like Andy I can find these useful, particularly as the ones on local PTE 
websites are very difficult to interpret. However, they suffer from the 
deficiencies of being a) unmaintained on OSM; b) not necessarily reflecting 
multiple bus pass zones; c) being fairly crude hulls of bus stops in the zone.

 

I quickly made this comparison 
  between the 
NAPTAN pay_scale_area (plusbuszone) for Nottingham (orange) and two concave 
hulls calculated with different parameters in QGIS (cyan (0.2) and blue 
(0.15)). All Naptan stops have a field imported into OSM as 
naptan:PlusbusZoneRef, that for Nottingham being NTNG which is what I used to 
identify bus stops for calculating the area.

 

Thus providing information is held on bus stops or (tram & train stops) for a 
given transport zone  these zones can be derived from other data in OSM, and 
indeed can be derived in such as way as to be more informative (e.g. excluding 
sea for coastal towns). It may be worth discussing other ways to store 
information about bus pass zones.

 

Jerry

 

On Thu, 4 Apr 2019 at 11:28, Andy Townsend mailto:ajt1...@gmail.com> > wrote:

On 04/04/2019 11:05, Philip Barnes wrote:
> I believe they were the zones covered by plusbus tickets.
>
I believe (and Stuart will know far more about this than me!) they 
predate the widescale adoption of PlusBus in the UK. Certainly when 
PlusBus was introduced in Chesterfield it didn't match the existing pay 
scale area, and since then neither current pay scale area (there is a 
small and a large one) operated by the local monopoly bus company 
matches the pay scale area that was in OSM before I deleted it.

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] RFC: Solar panel mapping in the UK

[SK53]

Yup, I don't think industrial is appropriate in many circumstances, any
more than it would be for an area of wind turbines on moorland. For
instance I've seen sheep grazing in between the panels (which IIRC are
mounted on heliostats) on this solar farm:
https://www.openstreetmap.org/way/168359464#map=15/39.8239/-5.6562=N.
I presume that after installation the ground is more-or-less as it was (not
for instance contaminated as is the case of many rural industrial areas,
nor with traffic of heavy goods vehicles).

Jerry

On Thu, 4 Apr 2019 at 16:25, Russ Garrett  wrote:

> On Thu, 4 Apr 2019 at 16:18, Mateusz Konieczny 
> wrote:
> > Why not? If area is covered by solar panels then it is used for power
> generation.
> > And power generation seems clear case of industrial use
>
> I guess it is. I just think "industrial" carries a number of
> connotations which solar power doesn't have. Also, in some cases the
> land under/around solar farms is used for grazing, or at any rate it's
> still mostly grass. I'm not too bothered either way, though.
>
> Cheers,
> --
> Russ Garrett
> r...@garrett.co.uk
>
> ___
> 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] RFC: Solar panel mapping in the UK

[Russ Garrett]

On Thu, 4 Apr 2019 at 16:18, Mateusz Konieczny  wrote:
> Why not? If area is covered by solar panels then it is used for power 
> generation.
> And power generation seems clear case of industrial use

I guess it is. I just think "industrial" carries a number of
connotations which solar power doesn't have. Also, in some cases the
land under/around solar farms is used for grazing, or at any rate it's
still mostly grass. I'm not too bothered either way, though.

Cheers,
-- 
Russ Garrett
r...@garrett.co.uk

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

Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Mateusz Konieczny]

Apr 4, 2019, 5:09 PM by r...@garrett.co.uk:

> I would argue landuse=industrial is not appropriate in this case,
> notwithstanding what the wiki says
>
Why not? If area is covered by solar panels then it is used for power 
generation.
And power generation seems clear case of industrial use

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

Re: [Talk-GB] Removal of redundant NaPTAN data

[SK53]

Like Andy I can find these useful, particularly as the ones on local PTE
websites are very difficult to interpret. However, they suffer from the
deficiencies of being a) unmaintained on OSM; b) not necessarily reflecting
multiple bus pass zones; c) being fairly crude hulls of bus stops in the
zone.

I quickly made this comparison
 between the
NAPTAN pay_scale_area (plusbuszone) for Nottingham (orange) and two concave
hulls calculated with different parameters in QGIS (cyan (0.2) and blue
(0.15)). All Naptan stops have a field imported into OSM as
naptan:PlusbusZoneRef, that for Nottingham being NTNG which is what I used
to identify bus stops for calculating the area.

Thus providing information is held on bus stops or (tram & train stops) for
a given transport zone  these zones can be derived from other data in OSM,
and indeed can be derived in such as way as to be more informative (e.g.
excluding sea for coastal towns). It may be worth discussing other ways to
store information about bus pass zones.

Jerry

On Thu, 4 Apr 2019 at 11:28, Andy Townsend  wrote:

> On 04/04/2019 11:05, Philip Barnes wrote:
> > I believe they were the zones covered by plusbus tickets.
> >
> I believe (and Stuart will know far more about this than me!) they
> predate the widescale adoption of PlusBus in the UK. Certainly when
> PlusBus was introduced in Chesterfield it didn't match the existing pay
> scale area, and since then neither current pay scale area (there is a
> small and a large one) operated by the local monopoly bus company
> matches the pay scale area that was in OSM before I deleted it.
>
> 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] RFC: Solar panel mapping in the UK

[Russ Garrett]

Hi Dave,

On Thu, 4 Apr 2019 at 14:11, Dave F via Talk-GB
 wrote:
> This would be a great project, however I think there's some confusion in
> the tagging which requires agreeing/clarifying.

Solar farms should have a power=plant covering the whole perimeter as
an area or multipolygon. I agree with you that relations shouldn't be
used because they're unnecessary. The output of the farm should be the
"plant:output:power=" tag on that object.

The use of power=plant for this was enshrined in the approved Power
Generation Refinement tagging proposal back in 2013 [1]. It also makes
sense by analogy to wind farms (where we do use power=plant on
relations).

I would argue landuse=industrial is not appropriate in this case,
notwithstanding what the wiki says, and perhaps landuse=grass is
appropriate here.

As a rule of thumb, 1 MW is probably a good initial threshold to use
when deciding whether to use the power=plant tag for solar, if only to
focus our tagging energy on larger plants to start with.

The power=generator tag should represent the arrays of panels as
closely as you can be bothered. I generally tag contiguous blocks of
panels as one power=generator, rather than every individual row. With
OpenInfraMap I'm now starting to estimate the output of solar
generators by their area, so I have a preference towards seeing them
tagged as closely as possible. However, I have little patience for
micro-mapping so I feel like each block of panels is a good
compromise.

Cheers,

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement

--
Russ Garrett
r...@garrett.co.uk

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

Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Jez Nicholson]

You are indeed right. Tagging for ground-based solar farms is varied. I am
currently collecting them at
https://wiki.openstreetmap.org/wiki/Renewable_energy_in_the_United_Kingdom#List_of_under_construction_and_operational_UK_Ground_Mounted_Solar_Farms
without
reforming the tagging and building up a tagging scheme in the process.

Use of a relation echoes that of a wind farm, which is a special case
object made up of individual nodes (turbines), ways (substation), and lines
(access tracks). The gaps in-between turbines are not physically part of
the wind farm. A solar farm relation could be replaced with a boundary
fence if one exists, with the blocks of panels as generators and the
overall relation/boundary as power:plant.

or you could be as detailed as our German colleagues.
https://www.openstreetmap.org/?mlat=51.5746=13.7358#map=15/51.5678/13.7384

On Thu, Apr 4, 2019 at 2:11 PM Dave F via Talk-GB 
wrote:

> On 03/04/2019 17:23, Dan S wrote:
> > * The tagging is already pretty well-defined.
>
>
> This would be a great project, however I think there's some confusion in
> the tagging which requires agreeing/clarifying.
>
> Most solar rural solar farms are on arable land. There's usually a
> boundary fence around the whole site. There are usually 'blocks' formed
> from numerous rows of panels. There can be multiple blocks, often one
> per field.
>
> Does a solar farm require a power=plant around the perimeter boundary?
> (no fill or border render, but the name is displayed in the 'standard'
> render)
>
> Does power=plant require a landuse=industrial tag (which does fill render)
>
> Where should the power=generator tag be placed? On the individual blocks
> or on the perimeter boundary?
> or, as in this detailed example, on individual panel rows?
> https://www.openstreetmap.org/way/654070917
>
> Similarly where should 'plant:output:electricity' go?
> (There's another example, which I'm unable to locate at present, which
> had the power output on each row).
>
> State side example:
>
> https://www.openstreetmap.org/way/340809071#map=18/33.30652/-112.83771=D
> Note they're tagged as buildings, & include the address!
>
> Some UK examples have collected 'blocks' into a relation.
> https://www.openstreetmap.org/relation/9291197
> If there's a boundary around them all I feel this that is unnecessary as
> OSM is geospatially aware. Similar to the schools project, any object
> within the amenity=school boundary is assumed to be part of the school.
>
> DaveF
>
> ___
> 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] Removal of redundant NaPTAN data

[Ed Loach]

Stuart asked:

> What do you mean by “pay scale”? Are you meaning the definition of a stop as 
> a fare stage, or as part of a zone? 

 

The pay_scale_area ways were the PlusBus zones as they were in 2009 according 
to 

https://wiki.openstreetmap.org/wiki/NaPTAN/Import

 

e.g. this one for Clacton, which was never correct as it should have followed 
the coastline, not joined the end points directly:

https://www.openstreetmap.org/way/38387713

 

Ed

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

Re: [Talk-GB] RFC: Solar panel mapping in the UK

[Dave F via Talk-GB]

On 03/04/2019 17:23, Dan S wrote:

* The tagging is already pretty well-defined.



This would be a great project, however I think there's some confusion in 
the tagging which requires agreeing/clarifying.


Most solar rural solar farms are on arable land. There's usually a 
boundary fence around the whole site. There are usually 'blocks' formed 
from numerous rows of panels. There can be multiple blocks, often one 
per field.


Does a solar farm require a power=plant around the perimeter boundary? 
(no fill or border render, but the name is displayed in the 'standard' 
render)


Does power=plant require a landuse=industrial tag (which does fill render)

Where should the power=generator tag be placed? On the individual blocks 
or on the perimeter boundary?
or, as in this detailed example, on individual panel rows? 
https://www.openstreetmap.org/way/654070917


Similarly where should 'plant:output:electricity' go?
(There's another example, which I'm unable to locate at present, which 
had the power output on each row).


State side example:
https://www.openstreetmap.org/way/340809071#map=18/33.30652/-112.83771=D
Note they're tagged as buildings, & include the address!

Some UK examples have collected 'blocks' into a relation.
https://www.openstreetmap.org/relation/9291197
If there's a boundary around them all I feel this that is unnecessary as 
OSM is geospatially aware. Similar to the schools project, any object 
within the amenity=school boundary is assumed to be part of the school.


DaveF

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

Re: [Talk-GB] New Bridge Gunnislake

[David Woolley]

Of course, that was one of my concerns. We really need some sort of
lifetime tagging with an end-date.


You can use opening hours to indicate a period in which something is closed.


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

Re: [Talk-GB] New Bridge Gunnislake

[ael via Talk-GB]

On Wed, Apr 03, 2019 at 10:49:04PM +0100, Neil Matthews wrote:
> Add a note on the main OSM site - maybe with expected finish date of
> road works -- might help as a reminder.

Oh yes. I ought to do that. I seldom generate notes, so I forget about
them.

ael


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

Re: [Talk-GB] New Bridge Gunnislake

[ael via Talk-GB]

On Wed, Apr 03, 2019 at 08:38:25PM +0100, Edward Catmur via Talk-GB wrote:
> There is also the temporary affix:
> 
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/temporary_(conditional)#Example_4:_Temporary_highway_bridge

Oh. I missed that. It would be perfect. Except, as you say :-

> I'm not entirely sure how well supported that is by routers etc though.

If I was confident that routers handled it, I would update the tagging.
Anyone know how widely it is supported?

ael


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

Re: [Talk-GB] New Bridge Gunnislake

[ael via Talk-GB]

On Wed, Apr 03, 2019 at 09:33:22PM +0200, Mateusz Konieczny wrote:
> 
> It is closed for repairs, so maybe highway=construction construction=primary
> would be better? 

I thought about that. But changing from primary seemed more
problematical if it was forgotten. 
 
> It seems that it will be more likely to be caught if forgotten, really old 
> highway=construction
> is far more suspicious that old access=no.

That also crossed my mind, but as I have alerted this list, and at least
one other mapper with an interest in the area who isn't on this list, I
doubt that it will be forgotten.
 
> There is also https://wiki.openstreetmap.org/wiki/Key:opening_date 
> 
> that allows to specify opening date - what makes possible to
> run query detecting objects that are supposed to be open now.

Yes, I guess that is a good idea. I was looking for an end-date, but
'negating' the tag - switching to construction - and the using
opening_date as the negation of "end_date" is neat. Hope routers parse
that sort of thing.

ael


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

Re: [Talk-GB] New Bridge Gunnislake

[Mateusz Konieczny]

Apr 4, 2019, 12:30 PM by talk-gb@openstreetmap.org:

> Of course, that was one of my concerns. We really need some sort of
> lifetime tagging with an end-date. 
>
There is https://wiki.openstreetmap.org/wiki/Key:opening_date 

that allows to specify opening date - what makes possible to
run query detecting objects that are supposed to be open now.

Query example for London: http://overpass-turbo.eu/s/HEq 
 (pan map
and press run to get results for other place).


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

Re: [Talk-GB] New Bridge Gunnislake

[ael via Talk-GB]

On Wed, Apr 03, 2019 at 02:59:12PM -0400, Devonshire wrote:
> Saw this on the local news last night. A 30+ mile diversion is going to cause 
> a few problems over Easter if they can't get it sorted. I am not that close 
> but have mapped this area a bit in the past.

Personally. I like the Horsebridge crossing, but we don't want to
encourage too many people who aren't used to small lanes to go that way.

> No real view either way on adding the restriction to OSM. Good for users who 
> keep their data up-to-date but potentially not so good for people who update 
> infrequently.

Of course, that was one of my concerns. We really need some sort of
lifetime tagging with an end-date. I have asked another mapper who
maps in this area, but like me isn't very local, to keep on eye on
the restriction in case I forget or whatever. Please also keep a watch
and remove the access tag as soon as the bridge re-opens if you get
there first.

ael

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

Re: [Talk-GB] Removal of redundant NaPTAN data

[Andy Townsend]

On 04/04/2019 11:05, Philip Barnes wrote:

I believe they were the zones covered by plusbus tickets.

I believe (and Stuart will know far more about this than me!) they 
predate the widescale adoption of PlusBus in the UK. Certainly when 
PlusBus was introduced in Chesterfield it didn't match the existing pay 
scale area, and since then neither current pay scale area (there is a 
small and a large one) operated by the local monopoly bus company 
matches the pay scale area that was in OSM before I deleted it.


Best Regards,

Andy



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

Re: [Talk-GB] Removal of redundant NaPTAN data

[Philip Barnes]

I believe they were the zones covered by plusbus tickets.

Although the Telford one is certainly unlikely as it has not been maintained 
since the import and Telford has expanded beyond it.

Phil (trigpoint)

On Thursday, 4 April 2019, Stuart Reynolds wrote:
> What do you mean by “pay scale”? Are you meaning the definition of a stop as 
> a fare stage, or as part of a zone?
> 
> If so, then this data needs to be deleted, forthwith, as it will never be 
> right. Outside of the regulated market that is London, different stops can be 
> fare stages for different operators, even when they are running similar 
> services along the same corridor routes. It is completely deregulated. And 
> that’s before we get onto zonal fares, which will have a different allocation 
> of stops to zones.
> 
> The Bus Services Act 2017 makes provision for the Secretary of State to 
> require bus companies to publish their fares data. There is a lot of work 
> going on at the minute within the industry to define how this will be done, 
> but the general principle (and this is all in the public domain) is that a) 
> operators will publish the data themselves; b) it will be discoverable via a 
> portal that the DfT will provide; and c) it is likely to use the CEN “NeTEx” 
> XML schema to do so. We are currently defining what the UK profile for this 
> will look like. Fares, though, won’t be mandatory until much later on - the 
> focus is initially on getting the provision of routes and timetables.
> 
> Some of this information will be “static” (or at least semi-static) i.e. 
> stops allocated to zones which will change infrequently. An individual 
> operator’s fare stages may also be relatively stable, but there is no 
> guarantee of that. So I don’t think that this should ever form part of a 
> database like OSM simply because of its lack of permanence. At best, it will 
> be an aligned data set IMHO.
> 
> 
> Regards,
> Stuart Reynolds
> for traveline south east & anglia
> 
> 
> 
> On 4 Apr 2019, at 10:37, Andy Townsend 
> mailto:ajt1...@gmail.com>> wrote:
> 
> On 04/04/2019 09:38, Brian Prangle wrote:
> Hi everyone
> 
> Back in the day of the original NapPTAN import we imported pay scale areas - 
> tagged as public_transport=pay_scale_area. I don't know why we ever did this 
> - there's no evidence on the ground and it's highly unlikely that any OSM 
> data consumer makes use of them ( if indeed they are still current).
> 
> I actually did use the local ones (when they were accurate), but as the bus 
> companies changed their rules I deleted them because they were just wrong.
> 
> 
> The information is better in public_transport applications run by public 
> transport bodies
> 
> Can you give an example of where such information might be found?  I could 
> hesitate a guess*, but I suspect not every reader of this list in the future 
> would necessarily be aware of that.
> 
> 
> 
> So I'm proposing that they are all deleted
> 
> The equivalent for anywhere with a sane public transport system might object, 
> but it could be that no such place exists outside London...
> 
> Best Regards,
> 
> Andy
> 
> * locally a combination of the council website, Bus company websites, 
> Traveline and Google Maps are all likely to be equally wrong in different 
> ways.  There is no authoritative answer.  When services were withdrawn due to 
> government cuts last year the best answer was usually to ask the driver when 
> a particular service would stop running.
> 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
> 
>

-- 
Sent from my Sailfish device
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removal of redundant NaPTAN data

[Andy Townsend]

On 04/04/2019 10:48, Stuart Reynolds wrote:
What do you mean by “pay scale”? Are you meaning the definition of a 
stop as a fare stage, or as part of a zone?



Example:

https://www.openstreetmap.org/way/38387740

(that's one that I haven't deleted yet)

Best Regards,

Andy


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

Re: [Talk-GB] Removal of redundant NaPTAN data

[Dave F via Talk-GB]

When I come across them I always delete them.

To map them as polygons was nonsense.

A few years ago the person who added them confessed he couldn't remember 
why he'd done it.


If there is a desire to to be added they should be on the bus stops, 
similar to the fare_zones I recently added to the London Underground 
stations.


DaveF



On 04/04/2019 10:00, Philip Barnes wrote:

The Telford one certainly looks highly dubious cutting residential areas and 
bus routes.

I agree these and public transport routes are best left to organisations such 
as traveline. After all a bus route without timetable information is pretty 
useless.
  
Phil (trigpoint)



On Thursday, 4 April 2019, Nick Allen wrote:

Brian,

Sounds like a good idea.

Nick
(Tallguy)

On Thu, 2019-04-04 at 09:38 +0100, Brian Prangle wrote:

Hi everyone

Back in the day of the original NapPTAN import we imported pay scale
areas - tagged as public_transport=pay_scale_area. I don't know why
we ever did this - there's no evidence on the ground and it's highly
unlikely that any OSM data consumer makes use of them ( if indeed
they are still current). The information is better in
public_transport applications run by public transport bodies

So I'm proposing that they are all deleted

Regards

Brian



___Talk-GB mailing
listtalk...@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] Removal of redundant NaPTAN data

[Stuart Reynolds]

What do you mean by “pay scale”? Are you meaning the definition of a stop as a 
fare stage, or as part of a zone?

If so, then this data needs to be deleted, forthwith, as it will never be 
right. Outside of the regulated market that is London, different stops can be 
fare stages for different operators, even when they are running similar 
services along the same corridor routes. It is completely deregulated. And 
that’s before we get onto zonal fares, which will have a different allocation 
of stops to zones.

The Bus Services Act 2017 makes provision for the Secretary of State to require 
bus companies to publish their fares data. There is a lot of work going on at 
the minute within the industry to define how this will be done, but the general 
principle (and this is all in the public domain) is that a) operators will 
publish the data themselves; b) it will be discoverable via a portal that the 
DfT will provide; and c) it is likely to use the CEN “NeTEx” XML schema to do 
so. We are currently defining what the UK profile for this will look like. 
Fares, though, won’t be mandatory until much later on - the focus is initially 
on getting the provision of routes and timetables.

Some of this information will be “static” (or at least semi-static) i.e. stops 
allocated to zones which will change infrequently. An individual operator’s 
fare stages may also be relatively stable, but there is no guarantee of that. 
So I don’t think that this should ever form part of a database like OSM simply 
because of its lack of permanence. At best, it will be an aligned data set IMHO.


Regards,
Stuart Reynolds
for traveline south east & anglia



On 4 Apr 2019, at 10:37, Andy Townsend 
mailto:ajt1...@gmail.com>> wrote:

On 04/04/2019 09:38, Brian Prangle wrote:
Hi everyone

Back in the day of the original NapPTAN import we imported pay scale areas - 
tagged as public_transport=pay_scale_area. I don't know why we ever did this - 
there's no evidence on the ground and it's highly unlikely that any OSM data 
consumer makes use of them ( if indeed they are still current).

I actually did use the local ones (when they were accurate), but as the bus 
companies changed their rules I deleted them because they were just wrong.


The information is better in public_transport applications run by public 
transport bodies

Can you give an example of where such information might be found?  I could 
hesitate a guess*, but I suspect not every reader of this list in the future 
would necessarily be aware of that.



So I'm proposing that they are all deleted

The equivalent for anywhere with a sane public transport system might object, 
but it could be that no such place exists outside London...

Best Regards,

Andy

* locally a combination of the council website, Bus company websites, Traveline 
and Google Maps are all likely to be equally wrong in different ways.  There is 
no authoritative answer.  When services were withdrawn due to government cuts 
last year the best answer was usually to ask the driver when a particular 
service would stop running.


___
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] Removal of redundant NaPTAN data

[Andy Townsend]

On 04/04/2019 09:38, Brian Prangle wrote:

Hi everyone

Back in the day of the original NapPTAN import we imported pay scale 
areas - tagged as public_transport=pay_scale_area. I don't know why we 
ever did this - there's no evidence on the ground and it's highly 
unlikely that any OSM data consumer makes use of them ( if indeed they 
are still current).


I actually did use the local ones (when they were accurate), but as the 
bus companies changed their rules I deleted them because they were just 
wrong.



The information is better in public_transport applications run by 
public transport bodies


Can you give an example of where such information might be found?  I 
could hesitate a guess*, but I suspect not every reader of this list in 
the future would necessarily be aware of that.





So I'm proposing that they are all deleted


The equivalent for anywhere with a sane public transport system might 
object, but it could be that no such place exists outside London...


Best Regards,

Andy

* locally a combination of the council website, Bus company websites, 
Traveline and Google Maps are all likely to be equally wrong in 
different ways.  There is no authoritative answer.  When services were 
withdrawn due to government cuts last year the best answer was usually 
to ask the driver when a particular service would stop running.



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

[Talk-GB] multiple GB lists

[Jez Nicholson]

Demonstrating my ignorance, I did not know until recently that there are
other GB lists, shown here with their last used date:

talk-gb-london/ 2019-03-14 14:35
talk-gb-midanglia/ 2016-06-17 15:15
talk-gb-oxoncotswolds/ 2018-11-21 18:43
talk-gb-thenorth/ 2017-06-22 11:44
talk-gb-westmidlands/ 2019-03-31 13:52
talk-scotland/ 2019-04-01 11:48

This may be a perennial discussion, but I'll naively stick my neck out
(again)

I, for one, would not be offended to read about regional activities in the
main Talk-GB list. In fact, I would welcome seeing activity around the
country even if i'm too far away to attend. They do not appear to be high
volume.

Could the owners of those lists consider culling them and merging with
Talk-GB?

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

Re: [Talk-GB] Removal of redundant NaPTAN data

[Philip Barnes]

The Telford one certainly looks highly dubious cutting residential areas and 
bus routes.

I agree these and public transport routes are best left to organisations such 
as traveline. After all a bus route without timetable information is pretty 
useless. 
 
Phil (trigpoint)


On Thursday, 4 April 2019, Nick Allen wrote:
> Brian,
> 
> Sounds like a good idea.
> 
> Nick
> (Tallguy)
> 
> On Thu, 2019-04-04 at 09:38 +0100, Brian Prangle wrote:
> > Hi everyone
> > 
> > Back in the day of the original NapPTAN import we imported pay scale
> > areas - tagged as public_transport=pay_scale_area. I don't know why
> > we ever did this - there's no evidence on the ground and it's highly
> > unlikely that any OSM data consumer makes use of them ( if indeed
> > they are still current). The information is better in
> > public_transport applications run by public transport bodies
> > 
> > So I'm proposing that they are all deleted
> > 
> > Regards
> > 
> > Brian
> > 
> > 
> > 
> > ___Talk-GB mailing
> > listtalk...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> > 
>

-- 
Sent from my Sailfish device
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removal of redundant NaPTAN data

[Nick Allen]

Brian,

Sounds like a good idea.

Nick
(Tallguy)

On Thu, 2019-04-04 at 09:38 +0100, Brian Prangle wrote:
> Hi everyone
> 
> Back in the day of the original NapPTAN import we imported pay scale
> areas - tagged as public_transport=pay_scale_area. I don't know why
> we ever did this - there's no evidence on the ground and it's highly
> unlikely that any OSM data consumer makes use of them ( if indeed
> they are still current). The information is better in
> public_transport applications run by public transport bodies
> 
> So I'm proposing that they are all deleted
> 
> Regards
> 
> Brian
> 
> 
> 
> ___Talk-GB mailing
> listtalk...@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] Removal of redundant NaPTAN data

[Brian Prangle]

Hi everyone

Back in the day of the original NapPTAN import we imported pay scale areas
- tagged as public_transport=pay_scale_area. I don't know why we ever did
this - there's no evidence on the ground and it's highly unlikely that any
OSM data consumer makes use of them ( if indeed they are still current).
The information is better in public_transport applications run by public
transport bodies

So I'm proposing that they are all deleted

Regards

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