Re: [Talk-transit] NaPTAN Import

[Shaun McDonald]

The import stalled through a combination of the person doing it (Thomas Wood) 
going to university, people in various areas either not taking the project on 
or in some cases not wanting an import in their area due to having done the bus 
stops manually already. 

There is now the updating issue that has not been solve and ideally needs to be 
done in a semi automated fashion, as a lot of the naptan bus stops have been 
updated since the import, and it's quite laborious to constantly check. The 
automation would be to suggest a set of changes in a localised area for someone 
to review, which they then accept. Conflicts would be left to review on a case 
by case basis.

As an attempt to get a bit further with current tools to making an import and 
update easier, I've setup Andy Allan's Snapshot Server with the latest Naptan 
(of about a month ago) but didn't get the stage of linking it with Potlatch 2 
yet. A significant issue with this method is that there's no way of 
highlighting specific bus stops that have changed in the Naptan recently or are 
different to OSM. The system doesn't allow for diff updates to the list in the 
snapshot server based on what has changed since the last import into the 
Snapshot Server.

http://naptan.smsm1.net/projects/1

Shaun

On 11 Jun 2013, at 17:33, Christopher Baines  wrote:

> Is the NaPTAN import still in progress? I ask as the "Request for
> Import" [1] page has not been edited in quite a while?
> 
> Thanks,
> 
> Chris
> 
> 1: https://wiki.openstreetmap.org/wiki/NaPTAN/Request_for_Import
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import stop tagging

[Claudius Henrichs]

I was referring to

public_transport=platform + bus=yes

public_transport=bus_stop would not work because there are stop 
positions where trams, buses and sometimes (Karlsruhe comes to my mind) 
even light_rails stop at the same position (Image: 
http://www.dvn-berlin.de/i/verein/2009_alex_bus_hpa.jpg ) and these 
would be tagged as


public_transport=platform + bus=yes + tram=yes (+ light_rail=yes)

Claudius

Am 29.06.2010 11:32, Richard Mann:

They're all still highway=bus_stop. I think I'd need some convincing
that public_transport=platform was appropriate for bus stops.
Public_transport=bus_stop, maybe.

Why change?

Richard

On Tue, Jun 29, 2010 at 9:59 AM, Claudius Henrichs  wrote:
   

One question on the Naptan import: Did you use any tags from the
public_transport therefore? Or are these all highway=bus_stop?
Would be a great chance to increase coverage of the more detailed
public_transport=platform
Claudius
 


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import stop tagging (was: Proposed changes to oxomoa schema [part 2: stops])

[Richard Mann]

They're all still highway=bus_stop. I think I'd need some convincing
that public_transport=platform was appropriate for bus stops.
Public_transport=bus_stop, maybe.

Why change?

Richard

On Tue, Jun 29, 2010 at 9:59 AM, Claudius Henrichs  wrote:
> One question on the Naptan import: Did you use any tags from the
> public_transport therefore? Or are these all highway=bus_stop?
> Would be a great chance to increase coverage of the more detailed
> public_transport=platform
> Claudius
>
> Am 29.06.2010 02:07, Shaun McDonald:
>
> In the UK as part of the Naptan import we already have decided that bus
> stops must be marked exactly where they are on the ground and added to the
> route relation of the bus route.
> Shaun
> On 28 Jun 2010, at 19:07, Michał Borsuk wrote:
>
> Hi everybody again:
>
> This time I'd like to propose a smaller change, but this one may break
> compatibility with oxomoa - it has been, however, already commonly
> implemented.
>
> ISSUE RAISED:
> * map bus stops to their physical location, not a point on the route/street
>
> Present status: If I understand correctly, oxomoa suggests that the bus stop
> data (name, unique number, etc.) be entered as properties of a point on the
> route/street.
>
> Problems :
> * Lines often have stops that are quite far apart for each direction
> * This prohibits proper routing (GPS + walking),
> * this system is not very intuitive I find.
>
> Proposed change: bus stops to be mapped exactly to where they are, and to be
> added to relations
>
> Result:
> * better routing results e.g. one wants to find a correct way to the bus
> stop, and not to the average point somewhere between two stops of the same
> name in either direction.
> * more intuitive system -> easier "learning curve" for new users.
>
> Influence on possible future software solutions: minor. May require all the
> stops on the route to be ordered based on their geographical location, as
> opposed to their place on the route (the latter is easier).
>
> Comments: I have seen this system very often implemented - two bus stops on
> each side, so my suggestion is just to codify the situation for future
> editors.
>
> Hope this is not too much at once, for more is to follow.
>
>
> Greetings,
>
>
> --
> Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,
>
> Michał Borsuk
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>
>

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

1st August 2009 22:21:35

Although there are reportedly some technical errors in the data I took
from the NaPTAN website that are unresolvable by myself.

2009/9/2 Chris Hill :
> After a brief exchange with a senior public transport officer from a
> local council I realized that I don't know what date the NaPTAN data
> relates to.  Can anyone help?
>
> Cheers, Chris
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>



-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NAPTAN Import: Plus-bus Zones

[Chris Morley]

Roger Slevin wrote:
> The PlusBus zone data comes from PlusBus – so please don’t try to change 
> it.  If you think it is wrong, then let me know and I will ask PlusBus 
> to review the information.

The Wrexham and Ruabon PlusBus zone has been imported without any 
reference to Wrexham (the more important location):
name = Ruabon
public_transport = pay_scale_area
ref = RUABON
source = naptan_import

While this presumably corresponds to an entry in somebody's database, 
it causes a bit of FUD in OSM. Presumably I could edit the name tag, 
in spite of the admonition above. But name tags are rendered by Mapnik 
at high zooms (here as a disembodied name 16km from Ruabon). For these 
areas, it would be better to remove the name tag and use note instead, 
e.g. note = Wrexham and Ruabon PlusBus area.

Chris

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

"Ed Loach"  schrieb:

> > I am not offering to create the page so hopefully someone else
> > will do
> > that. (I am doing work on cleaning up other existing transit
> > related
> > wiki pages on when I have time).
> 
> I might do a page Tag:public_transport=pay_scale_area and divert
> PlusBus to that?
> 
> Google reveals these areas were discussed on this list while I was
> on holiday at the end of July (and not receiving any osm lists
> emails), so I guess the issues I've mentioned today are related to
> the areas not being closed in the source data and that in the source
> data they have been assumed to follow the coastline in these areas
> rather than a straight line between the first and last points.

The source data which had the not being closed polygons were not
imported. It was merely a mistake I made which Thomas luckily spotted
before he actually imported the data into the OSM database.

The zone around Clacton is probably meant to follow the coastline but
as this cannot be seen from the NPTG data it is hard to import it in
this way.

Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Peter Miller  schrieb:
> Would it be sensible to create a PlusBus page on the wiki, and link
> to it from the NaPTAN user in relation to the upload? The Wiki page
> can describe what the features are about and can also be used to
> list issues that need to be resolved.
> 
> I am not offering to create the page so hopefully someone else will
> do that. (I am doing work on cleaning up other existing transit
> related wiki pages on when I have time).

I am intending to create a page describing the NPTG/Plusbus Zone
import. I just did not get round to do it yet.

Christoph

> 
> Regards,
> 
> 
> 
> Peter
> 
> >
> >
> > Ed
> >
> >> -Original Message-
> >> From: talk-transit-boun...@openstreetmap.org [mailto:talk-
> >> transit-boun...@openstreetmap.org] On Behalf Of Roger Slevin
> >> Sent: 07 August 2009 09:20
> >> To: 'Public transport/transit/shared taxi related topics'
> >> Subject: Re: [Talk-transit] Naptan import
> >>
> >> Ed
> >>
> >> Useful feedback which I will take up with PlusBus - as they
> >> should have
> >> listed coastal boundary stops to avoid this situation.
> >>
> >> Best wishes
> >>
> >> Roger
> >>
> >> -Original Message-
> >> From: talk-transit-boun...@openstreetmap.org
> >> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Ed
> >> Loach
> >> Sent: 07 August 2009 08:59
> >> To: talk-transit@openstreetmap.org
> >> Subject: [Talk-transit] Naptan import
> >>
> >> I see some areas have been imported near here,
> >> public_transport=pay_scale_area, for Harwich and Clacton. Is
> >> there a wiki
> >> page somewhere detailing what these are (I'll search after
> >> sending this)?
> >>
> >> In the case of Clacton, it looks like it was defined as a line
> >> from the
> >> coast, inland, then back to the coast, so the segment that
> >> closes the area
> >> cuts right through the middle of town. Should I adjust this
> >> segment to
> >> follow the coastline?
> >>
> >> Clacton:
> >> http://www.openstreetmap.org/browse/way/38387713
> >>
> >> Similarly for Harwich, the northeast segment seems to almost
> >> cross the tip
> >> of the peninsula, and in so doing cuts off most of Harwich to
> >> mainly only
> >> include Dovercourt. Should I amend that segment to include
> >> Harwich?
> >>
> >> Harwich:
> >> http://www.openstreetmap.org/browse/way/38387691
> >>
> >> Thanks
> >>
> >> Ed

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Ed Loach]

> I am not offering to create the page so hopefully someone else
> will do
> that. (I am doing work on cleaning up other existing transit
> related
> wiki pages on when I have time).

I might do a page Tag:public_transport=pay_scale_area and divert
PlusBus to that?

Google reveals these areas were discussed on this list while I was
on holiday at the end of July (and not receiving any osm lists
emails), so I guess the issues I've mentioned today are related to
the areas not being closed in the source data and that in the source
data they have been assumed to follow the coastline in these areas
rather than a straight line between the first and last points.

Ed



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Peter Miller]

On 7 Aug 2009, at 10:08, Ed Loach wrote:

> Thanks Roger,
>
> If they're PlusBus zones, then Clacton railway station lies outside
> the Clacton zone as it currently stands, and while Harwich
> International (formerly Harwich Parkeston Quay) is probably a
> boundary point for the Harwich zone (though the railway station as
> marked in OSM seems to be slightly further north, so it may be the
> bus stop at the front of the station), Harwich Town (and Dovercourt)
> stations are outside the Harwich zone. A quick web search suggests
> the Harwich zone should look a bit like
> http://www.nationalrail.co.uk/system/galleries/pics/plusbus_maps/HAR
> WICH.gif
> and the Clacton one
> http://www.nationalrail.co.uk/managed/promotions/prd64ecf0a0a0024005
> ffb18c459bd0e/ticketValidityConditions/PLUSBUS%20zone%20map%20for%20
> Clacton-on-Sea.pdf
> ( or shortened: http://is.gd/26fwi )


Would it be sensible to create a PlusBus page on the wiki, and link to  
it from the NaPTAN user in relation to the upload? The Wiki page can  
describe what the features are about and can also be used to list  
issues that need to be resolved.

I am not offering to create the page so hopefully someone else will do  
that. (I am doing work on cleaning up other existing transit related  
wiki pages on when I have time).



Regards,



Peter

>
>
> Ed
>
>> -Original Message-
>> From: talk-transit-boun...@openstreetmap.org [mailto:talk-
>> transit-boun...@openstreetmap.org] On Behalf Of Roger Slevin
>> Sent: 07 August 2009 09:20
>> To: 'Public transport/transit/shared taxi related topics'
>> Subject: Re: [Talk-transit] Naptan import
>>
>> Ed
>>
>> Useful feedback which I will take up with PlusBus - as they
>> should have
>> listed coastal boundary stops to avoid this situation.
>>
>> Best wishes
>>
>> Roger
>>
>> -Original Message-
>> From: talk-transit-boun...@openstreetmap.org
>> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Ed
>> Loach
>> Sent: 07 August 2009 08:59
>> To: talk-transit@openstreetmap.org
>> Subject: [Talk-transit] Naptan import
>>
>> I see some areas have been imported near here,
>> public_transport=pay_scale_area, for Harwich and Clacton. Is
>> there a wiki
>> page somewhere detailing what these are (I'll search after
>> sending this)?
>>
>> In the case of Clacton, it looks like it was defined as a line
>> from the
>> coast, inland, then back to the coast, so the segment that
>> closes the area
>> cuts right through the middle of town. Should I adjust this
>> segment to
>> follow the coastline?
>>
>> Clacton:
>> http://www.openstreetmap.org/browse/way/38387713
>>
>> Similarly for Harwich, the northeast segment seems to almost
>> cross the tip
>> of the peninsula, and in so doing cuts off most of Harwich to
>> mainly only
>> include Dovercourt. Should I amend that segment to include
>> Harwich?
>>
>> Harwich:
>> http://www.openstreetmap.org/browse/way/38387691
>>
>> Thanks
>>
>> Ed
>>
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Ed Loach]

Thanks Roger, 

If they're PlusBus zones, then Clacton railway station lies outside
the Clacton zone as it currently stands, and while Harwich
International (formerly Harwich Parkeston Quay) is probably a
boundary point for the Harwich zone (though the railway station as
marked in OSM seems to be slightly further north, so it may be the
bus stop at the front of the station), Harwich Town (and Dovercourt)
stations are outside the Harwich zone. A quick web search suggests
the Harwich zone should look a bit like
http://www.nationalrail.co.uk/system/galleries/pics/plusbus_maps/HAR
WICH.gif
and the Clacton one
http://www.nationalrail.co.uk/managed/promotions/prd64ecf0a0a0024005
ffb18c459bd0e/ticketValidityConditions/PLUSBUS%20zone%20map%20for%20
Clacton-on-Sea.pdf
( or shortened: http://is.gd/26fwi )


Ed

> -Original Message-
> From: talk-transit-boun...@openstreetmap.org [mailto:talk-
> transit-boun...@openstreetmap.org] On Behalf Of Roger Slevin
> Sent: 07 August 2009 09:20
> To: 'Public transport/transit/shared taxi related topics'
> Subject: Re: [Talk-transit] Naptan import
> 
> Ed
> 
> Useful feedback which I will take up with PlusBus - as they
> should have
> listed coastal boundary stops to avoid this situation.
> 
> Best wishes
> 
> Roger
> 
> -Original Message-
> From: talk-transit-boun...@openstreetmap.org
> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Ed
> Loach
> Sent: 07 August 2009 08:59
> To: talk-transit@openstreetmap.org
> Subject: [Talk-transit] Naptan import
> 
> I see some areas have been imported near here,
> public_transport=pay_scale_area, for Harwich and Clacton. Is
> there a wiki
> page somewhere detailing what these are (I'll search after
> sending this)?
> 
> In the case of Clacton, it looks like it was defined as a line
> from the
> coast, inland, then back to the coast, so the segment that
> closes the area
> cuts right through the middle of town. Should I adjust this
> segment to
> follow the coastline?
> 
> Clacton:
> http://www.openstreetmap.org/browse/way/38387713
> 
> Similarly for Harwich, the northeast segment seems to almost
> cross the tip
> of the peninsula, and in so doing cuts off most of Harwich to
> mainly only
> include Dovercourt. Should I amend that segment to include
> Harwich?
> 
> Harwich:
> http://www.openstreetmap.org/browse/way/38387691
> 
> Thanks
> 
> Ed
> 
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Ed

Useful feedback which I will take up with PlusBus - as they should have
listed coastal boundary stops to avoid this situation.

Best wishes

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Ed Loach
Sent: 07 August 2009 08:59
To: talk-transit@openstreetmap.org
Subject: [Talk-transit] Naptan import

I see some areas have been imported near here,
public_transport=pay_scale_area, for Harwich and Clacton. Is there a wiki
page somewhere detailing what these are (I'll search after sending this)? 

In the case of Clacton, it looks like it was defined as a line from the
coast, inland, then back to the coast, so the segment that closes the area
cuts right through the middle of town. Should I adjust this segment to
follow the coastline?

Clacton:
http://www.openstreetmap.org/browse/way/38387713

Similarly for Harwich, the northeast segment seems to almost cross the tip
of the peninsula, and in so doing cuts off most of Harwich to mainly only
include Dovercourt. Should I amend that segment to include Harwich?

Harwich:
http://www.openstreetmap.org/browse/way/38387691

Thanks

Ed



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NAPTAN Import: Plus-bus Zones

[Roger Slevin]

PlusBus zone boundaries are defined by the stoppoints at the edges of the 
zones.  It should be possible to draw straight lines between each of the 
boundary points to define the polygon of the area they cover (all stops within 
such a polygon are members of that PlusBus zone).  The exceptional treatment of 
NET (tram) in Nottingham is not reflected in the data supplied by PlusBus – 
which is why it doesn’t show up on your mapping of the data (and it doesn’t 
show on the zone diagram on the PlusBus web site either) – I suspect that this 
is because it would be misleading as it would imply that buses can be used in 
the area of served by the tram that is beyond the main area of the PlusBus bus 
zone.

 

The PlusBus zone data comes from PlusBus – so please don’t try to change it.  
If you think it is wrong, then let me know and I will ask PlusBus to review the 
information.

 

Roger

 

From: talk-transit-boun...@openstreetmap.org 
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Jerry Clough - OSM
Sent: 05 August 2009 15:31
To: talk-transit@openstreetmap.org
Subject: [Talk-transit] NAPTAN Import: Plus-bus Zones

 

I've had a quick look at a couple of the PlusBusZones (once inadvertently, as 
the name is rendering 
inappropriately on the Mapnik map): Nottingham and Maidenhead. In both cases 
boundaries are only 
approximate, and appear to be delimited by bus stops rather than routes (e.g., 
service 6 in Maidenhead travels 
along A308, and through the Pinkneys Green area, but AFAIK does not stop). The 
Nottingham one is of particular 
interest to me as the available literature shows an extremely fuzzy map with no 
indications of the precise limits of 
the zone. 

On the routes where I know the limit of the city-wide tickets (CityRider, 
Kangaroo) the edges of the zone are from 
100-200 metres out. I wonder how we can improve this mapping in OSM. For 
instance I could ensure that the 
PlusBus zone polygon shared nodes with the bus stops at the Blue 
 
 Bell, Attenborough, and the 
Sherwin 

  Arms, Bramcote. There is one other issue: the Nottingham Tram (NET) extends 
to Hucknall, 
and I think the relevant tram stops are included in the PlusBus scheme, but 
buses are not. The Kangaroo
 includes the tram and also train services between Hucknall, Attenborough, 
Carlton and Nottingham.

Jerry
SK53

PS. First posting to list, so formatting might be an issue.

 

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Christoph Böhme]

Peter Miller  schrieb:

> 
> On 1 Aug 2009, at 22:51, Thomas Wood wrote:

> > Ooops, I linked the wrong changeset!
> > http://api06.dev.openstreetmap.org/browse/changeset/389 was my
> > intent.
> 
> A couple of comments.
> 
> Firstly, the locality field is an important part of the name in  
> NaPTAN. The stop name can be constructed in a number of ways
> depending on how much precision is needed and what the geographic
> context is.
> 
> For example, let's take this stop outside a pub called 'The  
> Woodman' (which is in Ashteed).
> http://api06.dev.openstreetmap.org/browse/node/396115
> 
> If the context for the enquiry was Ashteed itself, then one could
> say 'The Woodman (Adj)'. If the context was wider and one still
> needed to be precise one would say: 'Ashteed, The Woodman (Adj)'.
> 
> Localities themselves are not always unique so there is the  
> possibility for a locality to have a qualifier in NaPTAN. The full  
> description for a bus stop called 'Long Road' in Cambridge in  
> Cambridgeshire (rather than the one in Gloucestershire) would be  
> 'Cambridge (Cambs), Long Road (opp)'. If the context was east anglia  
> then one could drop the qualifier and it would become 'Cambridge,
> Long Road (opp)'. If the context was Cambridge itself then one could
> use 'Long Road (opp)'.
> 
> So... what to do. I suggest we need a naptan:locality field which  
> should contain the naptan locality name or possibly also  
> naptan:natgazid as a unique reference for the place (to accommodate  
> multiple localities with the same name).
> 
> I am not clear what we do, but we need to do something.

To me the functionality of the naptan:locality tag appears to be similar
to the one of the is_in tag on places. With the introduction of
boundaries these tags become less important in my opinion as you can
easily find out the location of a feature by looking in which areas it
is in.

I think, putting the NaPTAN data in OSM is similar to drawing them on a
map: The map (i.e. OSM) provides a rich context from which much
information wich was stored as properties of the bus stops before can
be derived.

Cheers,
Christoph

> 
> Regards,
> 
> 
> 
> Peter
> 
> 
> 
> 
> 
> >
> >>
> >>> We're then ready to begin uploading to the main database.
> >>
> >> Cool :-)
> >>
> >> Cheers,
> >> Christoph
> >>
> >> ___
> >> Talk-transit mailing list
> >> Talk-transit@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-transit
> >>
> >
> >
> >
> > -- 
> > Regards,
> > Thomas Wood
> > (Edgemaster)
> >
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Peter Miller]

On 1 Aug 2009, at 22:51, Thomas Wood wrote:

> 2009/8/1 Christoph Böhme :
>> Thomas Wood  schrieb:
>>
>>> I think all outstanding coding issues have now been dealt with.
>>> There's one minor tagging issue to address - should the source tag  
>>> be
>>> on the data or changesets.
>>
>> Since the source tag applies to the whole changeset it makes sense to
>> tag only the changeset. However, I believe editors do not display
>> changeset tags at the moment. This means changeset tags are basically
>> not visible when you edit data. While it can be handy to see the  
>> source
>> of an element when you edit it (e.g. I'm much less relucant to move
>> NPE-sourced data if it does not fit with my tracks than surveyed  
>> data)
>> this should not be a problem with the naptan-import. The naptan:-tags
>> are a very obvious hint where the data is coming from.
>>
>> So, I'd vote for placing the source-tag at the changeset.
>>
>>> Otherwise, a test upload of the Surrey data is visible here -
>>> http://api06.dev.openstreetmap.org/browse/changeset/394
>>> Comments welcomed.
>>
>> Could it be that the tags are missing? All the nodes I have looked at
>> are empty (http://api06.dev.openstreetmap.org/browse/node/416977, for
>> example)
>
> Ooops, I linked the wrong changeset!
> http://api06.dev.openstreetmap.org/browse/changeset/389 was my intent.

A couple of comments.

Firstly, the locality field is an important part of the name in  
NaPTAN. The stop name can be constructed in a number of ways depending  
on how much precision is needed and what the geographic context is.

For example, let's take this stop outside a pub called 'The  
Woodman' (which is in Ashteed).
http://api06.dev.openstreetmap.org/browse/node/396115

If the context for the enquiry was Ashteed itself, then one could say  
'The Woodman (Adj)'. If the context was wider and one still needed to  
be precise one would say: 'Ashteed, The Woodman (Adj)'.

Localities themselves are not always unique so there is the  
possibility for a locality to have a qualifier in NaPTAN. The full  
description for a bus stop called 'Long Road' in Cambridge in  
Cambridgeshire (rather than the one in Gloucestershire) would be  
'Cambridge (Cambs), Long Road (opp)'. If the context was east anglia  
then one could drop the qualifier and it would become 'Cambridge, Long  
Road (opp)'. If the context was Cambridge itself then one could use  
'Long Road (opp)'.

So... what to do. I suggest we need a naptan:locality field which  
should contain the naptan locality name or possibly also  
naptan:natgazid as a unique reference for the place (to accommodate  
multiple localities with the same name).

I am not clear what we do, but we need to do something.


Regards,



Peter





>
>>
>>> We're then ready to begin uploading to the main database.
>>
>> Cool :-)
>>
>> Cheers,
>> Christoph
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>
>
>
> -- 
> Regards,
> Thomas Wood
> (Edgemaster)
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Christoph

Thanks - if that's the case then I need to look again at the definition of this 
particular zone  I had alerted the people who had created the data a long 
time ago that it could be defined much more simply.  So let me check why this 
hasn't happened.  From memory it should only need about 12 points defining a 
"blob" rather than the very strange detail that is being defined by the more 
extensive list of points that I now see is still in the source data.

Roger


-Original Message-
From: talk-transit-boun...@openstreetmap.org 
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme
Sent: 02 August 2009 11:40
To: talk-transit@openstreetmap.org
Subject: Re: [Talk-transit] Naptan import

"Roger Slevin"  schrieb:

> Plusbus zones are polygons which are unrelated to the road network -
> so for Rye it covers a large polygon defined by straight lines
> linking each pair of adjacent nodes on the source list of defining
> points.  The representation of this "along the roads" is
> inappropriate - and certainly not how it should be should be shown in
> terms of the zone definition intended.

The representation of the plusbus zones in OSM is still as it should be.
Except for merging duplicate nodes they are the same as defined in the
NPTG data. I just tried to describe why the zone for Rye has such an
unusual shape compared to other zones. I didn't modify it to actually
follow the roads. Sorry for causing confusion!

Christoph

> The Rye example is a particularly extreme example, as there are few
> roads in the area with bus routes - and lots of marshland and open
> countryside covered by the Plusbus zone.
> 
> Roger
> 
> -Original Message-
> From: talk-transit-boun...@openstreetmap.org
> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of
> Christoph Böhme Sent: 02 August 2009 00:24 To: Thomas Wood
> Cc: Public transport/transit/shared taxi related topics
> Subject: Re: [Talk-transit] Naptan import
> 
> Thomas Wood  schrieb:
> 
> > 2009/7/30 Christoph Böhme :
> > > Thomas Wood  schrieb:
> > >> 2009/7/29 Christoph Böhme :
> > >> > I transformed the Plusbus Zones into a josm-file (XSLT is
> > >> > cool :-). Thomas can you import it using the naptan-user if no
> > >> > one objects to the tagging scheme?
> > >> >
> > >> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
> > >> >
> > >> > Cheers,
> > >> > Christoph
> > >> >
> > >> > ___
> > >> > Talk-transit mailing list
> > >> > Talk-transit@openstreetmap.org
> > >> > http://lists.openstreetmap.org/listinfo/talk-transit
> > >> >
> > >>
> > >> That looks fine, the only issue is that none of the polygons are
> > >> closed!
> > >
> > > Oh, good that you noticed this. I fixed the file and uploaded it
> > > again.
> > >
> > > Christoph
> > >
> > 
> > I have run JOSM's validator over it to clean up some duplicate ways,
> > and the more obviously incorrect polygon geometries (West Mids had a
> > weird doubleback by the look of it) a few have overlapping segments,
> > but I've chosen to ignore their 'errorness'.
> > 
> > http://www.openstreetmap.org/browse/changeset/2008301
> 
> Good idea to use JOSM's validator, I should have done it myself ...
> 
> The incorrect geometries are converted directly from the NPTG data.
> Some of the polygons there have duplicate nodes. Removing the
> duplicate nodes was a sensible choice, I think. I had a look at the
> very distorted Plusbus Zone for Rye. Its strange shape seems to stem
> from the fact that it simple spans four villages and follows the road
> between them. I think there are similar reasons for the other errors.
> 
> Thank you checking and importing the changeset!
> 
> Christoph
> 
> > -- 
> > Regards,
> > Thomas Wood
> > (Edgemaster)
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

"Roger Slevin"  schrieb:

> Plusbus zones are polygons which are unrelated to the road network -
> so for Rye it covers a large polygon defined by straight lines
> linking each pair of adjacent nodes on the source list of defining
> points.  The representation of this "along the roads" is
> inappropriate - and certainly not how it should be should be shown in
> terms of the zone definition intended.

The representation of the plusbus zones in OSM is still as it should be.
Except for merging duplicate nodes they are the same as defined in the
NPTG data. I just tried to describe why the zone for Rye has such an
unusual shape compared to other zones. I didn't modify it to actually
follow the roads. Sorry for causing confusion!

Christoph

> The Rye example is a particularly extreme example, as there are few
> roads in the area with bus routes - and lots of marshland and open
> countryside covered by the Plusbus zone.
> 
> Roger
> 
> -Original Message-
> From: talk-transit-boun...@openstreetmap.org
> [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of
> Christoph Böhme Sent: 02 August 2009 00:24 To: Thomas Wood
> Cc: Public transport/transit/shared taxi related topics
> Subject: Re: [Talk-transit] Naptan import
> 
> Thomas Wood  schrieb:
> 
> > 2009/7/30 Christoph Böhme :
> > > Thomas Wood  schrieb:
> > >> 2009/7/29 Christoph Böhme :
> > >> > I transformed the Plusbus Zones into a josm-file (XSLT is
> > >> > cool :-). Thomas can you import it using the naptan-user if no
> > >> > one objects to the tagging scheme?
> > >> >
> > >> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
> > >> >
> > >> > Cheers,
> > >> > Christoph
> > >> >
> > >> > ___
> > >> > Talk-transit mailing list
> > >> > Talk-transit@openstreetmap.org
> > >> > http://lists.openstreetmap.org/listinfo/talk-transit
> > >> >
> > >>
> > >> That looks fine, the only issue is that none of the polygons are
> > >> closed!
> > >
> > > Oh, good that you noticed this. I fixed the file and uploaded it
> > > again.
> > >
> > > Christoph
> > >
> > 
> > I have run JOSM's validator over it to clean up some duplicate ways,
> > and the more obviously incorrect polygon geometries (West Mids had a
> > weird doubleback by the look of it) a few have overlapping segments,
> > but I've chosen to ignore their 'errorness'.
> > 
> > http://www.openstreetmap.org/browse/changeset/2008301
> 
> Good idea to use JOSM's validator, I should have done it myself ...
> 
> The incorrect geometries are converted directly from the NPTG data.
> Some of the polygons there have duplicate nodes. Removing the
> duplicate nodes was a sensible choice, I think. I had a look at the
> very distorted Plusbus Zone for Rye. Its strange shape seems to stem
> from the fact that it simple spans four villages and follows the road
> between them. I think there are similar reasons for the other errors.
> 
> Thank you checking and importing the changeset!
> 
> Christoph
> 
> > -- 
> > Regards,
> > Thomas Wood
> > (Edgemaster)
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Plusbus zones are polygons which are unrelated to the road network - so for Rye 
it covers a large polygon defined by straight lines linking each pair of 
adjacent nodes on the source list of defining points.  The representation of 
this "along the roads" is inappropriate - and certainly not how it should be 
should be shown in terms of the zone definition intended.

The Rye example is a particularly extreme example, as there are few roads in 
the area with bus routes - and lots of marshland and open countryside covered 
by the Plusbus zone.

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org 
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme
Sent: 02 August 2009 00:24
To: Thomas Wood
Cc: Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] Naptan import

Thomas Wood  schrieb:

> 2009/7/30 Christoph Böhme :
> > Thomas Wood  schrieb:
> >> 2009/7/29 Christoph Böhme :
> >> > I transformed the Plusbus Zones into a josm-file (XSLT is
> >> > cool :-). Thomas can you import it using the naptan-user if no
> >> > one objects to the tagging scheme?
> >> >
> >> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
> >> >
> >> > Cheers,
> >> > Christoph
> >> >
> >> > ___
> >> > Talk-transit mailing list
> >> > Talk-transit@openstreetmap.org
> >> > http://lists.openstreetmap.org/listinfo/talk-transit
> >> >
> >>
> >> That looks fine, the only issue is that none of the polygons are
> >> closed!
> >
> > Oh, good that you noticed this. I fixed the file and uploaded it
> > again.
> >
> > Christoph
> >
> 
> I have run JOSM's validator over it to clean up some duplicate ways,
> and the more obviously incorrect polygon geometries (West Mids had a
> weird doubleback by the look of it) a few have overlapping segments,
> but I've chosen to ignore their 'errorness'.
> 
> http://www.openstreetmap.org/browse/changeset/2008301

Good idea to use JOSM's validator, I should have done it myself ...

The incorrect geometries are converted directly from the NPTG data.
Some of the polygons there have duplicate nodes. Removing the
duplicate nodes was a sensible choice, I think. I had a look at the
very distorted Plusbus Zone for Rye. Its strange shape seems to stem
from the fact that it simple spans four villages and follows the road
between them. I think there are similar reasons for the other errors.

Thank you checking and importing the changeset!

Christoph

> -- 
> Regards,
> Thomas Wood
> (Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Thomas Wood  schrieb:

> 2009/7/30 Christoph Böhme :
> > Thomas Wood  schrieb:
> >> 2009/7/29 Christoph Böhme :
> >> > I transformed the Plusbus Zones into a josm-file (XSLT is
> >> > cool :-). Thomas can you import it using the naptan-user if no
> >> > one objects to the tagging scheme?
> >> >
> >> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
> >> >
> >> > Cheers,
> >> > Christoph
> >> >
> >> > ___
> >> > Talk-transit mailing list
> >> > Talk-transit@openstreetmap.org
> >> > http://lists.openstreetmap.org/listinfo/talk-transit
> >> >
> >>
> >> That looks fine, the only issue is that none of the polygons are
> >> closed!
> >
> > Oh, good that you noticed this. I fixed the file and uploaded it
> > again.
> >
> > Christoph
> >
> 
> I have run JOSM's validator over it to clean up some duplicate ways,
> and the more obviously incorrect polygon geometries (West Mids had a
> weird doubleback by the look of it) a few have overlapping segments,
> but I've chosen to ignore their 'errorness'.
> 
> http://www.openstreetmap.org/browse/changeset/2008301

Good idea to use JOSM's validator, I should have done it myself ...

The incorrect geometries are converted directly from the NPTG data.
Some of the polygons there have duplicate nodes. Removing the
duplicate nodes was a sensible choice, I think. I had a look at the
very distorted Plusbus Zone for Rye. Its strange shape seems to stem
from the fact that it simple spans four villages and follows the road
between them. I think there are similar reasons for the other errors.

Thank you checking and importing the changeset!

Christoph

> -- 
> Regards,
> Thomas Wood
> (Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Thomas Wood]

2009/8/1 Christoph Böhme :
> Thomas Wood  schrieb:
>
>> 2009/8/1 Christoph Böhme :
>> > Thomas Wood  schrieb:
>> >> Otherwise, a test upload of the Surrey data is visible here -
>> >> http://api06.dev.openstreetmap.org/browse/changeset/394
>> >> Comments welcomed.
>> >
>> > Could it be that the tags are missing? All the nodes I have looked
>> > at are empty
>> > (http://api06.dev.openstreetmap.org/browse/node/416977, for example)
>>
>> Ooops, I linked the wrong changeset!
>> http://api06.dev.openstreetmap.org/browse/changeset/389 was my intent.
>
> That looks much better :-) I noticed that the bus stops are all tagged
> with highway=bus_stop. Is this intentional? I thought this should
> depend on what people wished for their local area.
>
> Cheers,
> Christoph
>

It is optional, by default I test with it enabled, it requires an
extra command-line option to disable.
So far most people have chosen for it to be on though -
http://wiki.openstreetmap.org/wiki/NaPTAN/Request_for_Import

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/30 Christoph Böhme :
> Thomas Wood  schrieb:
>> 2009/7/29 Christoph Böhme :
>> > I transformed the Plusbus Zones into a josm-file (XSLT is cool :-).
>> > Thomas can you import it using the naptan-user if no one objects to
>> > the tagging scheme?
>> >
>> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
>> >
>> > Cheers,
>> > Christoph
>> >
>> > ___
>> > Talk-transit mailing list
>> > Talk-transit@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-transit
>> >
>>
>> That looks fine, the only issue is that none of the polygons are
>> closed!
>
> Oh, good that you noticed this. I fixed the file and uploaded it again.
>
> Christoph
>

I have run JOSM's validator over it to clean up some duplicate ways,
and the more obviously incorrect polygon geometries (West Mids had a
weird doubleback by the look of it) a few have overlapping segments,
but I've chosen to ignore their 'errorness'.

http://www.openstreetmap.org/browse/changeset/2008301

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Christoph Böhme]

Thomas Wood  schrieb:

> 2009/8/1 Christoph Böhme :
> > Thomas Wood  schrieb:
> >> Otherwise, a test upload of the Surrey data is visible here -
> >> http://api06.dev.openstreetmap.org/browse/changeset/394
> >> Comments welcomed.
> >
> > Could it be that the tags are missing? All the nodes I have looked
> > at are empty
> > (http://api06.dev.openstreetmap.org/browse/node/416977, for example)
> 
> Ooops, I linked the wrong changeset!
> http://api06.dev.openstreetmap.org/browse/changeset/389 was my intent.

That looks much better :-) I noticed that the bus stops are all tagged
with highway=bus_stop. Is this intentional? I thought this should
depend on what people wished for their local area.

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Thomas Wood]

2009/8/1 Christoph Böhme :
> Thomas Wood  schrieb:
>
>> I think all outstanding coding issues have now been dealt with.
>> There's one minor tagging issue to address - should the source tag be
>> on the data or changesets.
>
> Since the source tag applies to the whole changeset it makes sense to
> tag only the changeset. However, I believe editors do not display
> changeset tags at the moment. This means changeset tags are basically
> not visible when you edit data. While it can be handy to see the source
> of an element when you edit it (e.g. I'm much less relucant to move
> NPE-sourced data if it does not fit with my tracks than surveyed data)
> this should not be a problem with the naptan-import. The naptan:-tags
> are a very obvious hint where the data is coming from.
>
> So, I'd vote for placing the source-tag at the changeset.
>
>> Otherwise, a test upload of the Surrey data is visible here -
>> http://api06.dev.openstreetmap.org/browse/changeset/394
>> Comments welcomed.
>
> Could it be that the tags are missing? All the nodes I have looked at
> are empty (http://api06.dev.openstreetmap.org/browse/node/416977, for
> example)

Ooops, I linked the wrong changeset!
http://api06.dev.openstreetmap.org/browse/changeset/389 was my intent.

>
>> We're then ready to begin uploading to the main database.
>
> Cool :-)
>
> Cheers,
> Christoph
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>



-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN Import

[Christoph Böhme]

Thomas Wood  schrieb:

> I think all outstanding coding issues have now been dealt with.
> There's one minor tagging issue to address - should the source tag be
> on the data or changesets.

Since the source tag applies to the whole changeset it makes sense to
tag only the changeset. However, I believe editors do not display
changeset tags at the moment. This means changeset tags are basically
not visible when you edit data. While it can be handy to see the source
of an element when you edit it (e.g. I'm much less relucant to move
NPE-sourced data if it does not fit with my tracks than surveyed data)
this should not be a problem with the naptan-import. The naptan:-tags
are a very obvious hint where the data is coming from.

So, I'd vote for placing the source-tag at the changeset.

> Otherwise, a test upload of the Surrey data is visible here -
> http://api06.dev.openstreetmap.org/browse/changeset/394
> Comments welcomed.

Could it be that the tags are missing? All the nodes I have looked at
are empty (http://api06.dev.openstreetmap.org/browse/node/416977, for
example)

> We're then ready to begin uploading to the main database.

Cool :-)

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Thomas

Thanks for this - the East Sussex one is clearly wrong (not a lot of Gaelic
spoken there) ... and is something we don't check on, and it hadn't been
spotted before.  I have asked the editor to correct it (to "blank" or "en").
I don't have that influence with Perth & Kinross - though I will try.  One
of the NaPTAN editors used by some authorities had a propensity to default
to CY - which presumably is what has happened in this case.

As you say, having alerted me to these issues, you can just ignore language
flags at present.

Best wishes

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Thomas Wood
Sent: 31 July 2009 16:14
To: Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] Naptan import

2009/7/29 Thomas Wood :
> 2009/7/29 Christoph Böhme :
[snip]
>> - Alternative names (e.g. welsh names)
>
> NaPTAN includes this too, I was going to check whether the
> functionality was required as we started on Welsh/Scottish regions, I
> can't remember the reason for not implementing it immediately other
> than awkwardness of the way I was parsing.
[snip]

I've now done a check on the Feb NaPTAN source files, there are no
language sections that seriously need to be considered, there are only
two regions that used them - East Sussex and Perth & Kinross.

The East Sussex reference was "adj", which is obviously rubbish.

All the Perth & Kinross references were on the Name element, and
referenced /Welsh/, a few examples:
South Street
Post Office
Main Entrance
A look through shows others, such as road names, but none that are
obviously in Welsh.

Thus it's fairly safe to disregard the functionality NaPTAN provides
for alternative languages at this point.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/29 Thomas Wood :
> 2009/7/29 Christoph Böhme :
[snip]
>> - Alternative names (e.g. welsh names)
>
> NaPTAN includes this too, I was going to check whether the
> functionality was required as we started on Welsh/Scottish regions, I
> can't remember the reason for not implementing it immediately other
> than awkwardness of the way I was parsing.
[snip]

I've now done a check on the Feb NaPTAN source files, there are no
language sections that seriously need to be considered, there are only
two regions that used them - East Sussex and Perth & Kinross.

The East Sussex reference was "adj", which is obviously rubbish.

All the Perth & Kinross references were on the Name element, and
referenced /Welsh/, a few examples:
South Street
Post Office
Main Entrance
A look through shows others, such as road names, but none that are
obviously in Welsh.

Thus it's fairly safe to disregard the functionality NaPTAN provides
for alternative languages at this point.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Boehme]

Christoph Böhme  wrote:
> Peter Miller  schrieb:
> > I am also aware that there is a 50K place gazetteer sitting there  
> > untouched - last week I was adding villages in Norfolk by hand and
> > the data is sitting available in NPTG.
> 
> I taught myself XSLT at the weekend and played a bit with the NPTG
> data. On http://www.mappa-mercia.org/nptg/ you can find some
> html-pages which show the hierarchies of and adjacencies between the
> localities in the NTPG data. 

I just noticed that Firefox 3.0 does only display a blank page on
http://www.mappa-mercia.org/nptg/. I have fixed this now in case
someone is still interested in the report.

Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Thomas Wood  schrieb:
> 2009/7/29 Christoph Böhme :
> > I transformed the Plusbus Zones into a josm-file (XSLT is cool :-).
> > Thomas can you import it using the naptan-user if no one objects to
> > the tagging scheme?
> >
> > http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
> >
> > Cheers,
> > Christoph
> >
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-transit
> >
> 
> That looks fine, the only issue is that none of the polygons are
> closed!

Oh, good that you noticed this. I fixed the file and uploaded it again.

Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Roger,

thank you very much, I am looking forward to analysing this. 

Please note that I only have a standard OSM excerpt of places and no
special 1950s dataset. Just in case this has not been made clear in my
previous email.

Cheers,
Christoph

"Roger Slevin"  schrieb:

> I'll see whether it is possible to get a file exported which includes
> the "inactive" localities and let you know ... there may be some
> value in running a comparison between your 1950s data and the more
> recent data in NPTG.
>
> Best wishes
> 
> Roger
> 
> 
> -Original Message-
> From: Christoph Böhme [mailto:christ...@b3e.net] 
> Sent: 29 July 2009 18:36
> To: ro...@slevin.plus.com
> Cc: 'Public transport/transit/shared taxi related topics'; 'Peter
> Miller' Subject: Re: [Talk-transit] Naptan import
> 
> "Roger Slevin"  schrieb:
> 
> > Christoph
> > 
> > Sorry - I now realise I shouldn't have referred to "inactive"
> > localities ... this is something I can see on the editor system for
> > NPTG, but the export only shows the active localities ... the
> > records of the inactive ones are not included in the standard XML
> > file.  I would need to check whether it is possible to get an
> > extract from NPTG which includes inactive records (or only
> > comprises the inactive ones) - but that is a question I will only
> > ask if someone can suggest that some useful purpose could be served
> > by having access to that data.
> 
> The only reason for using the inactive data I can see is a comparison
> with OSM-only places. This could indicate NPTG places which might have
> been deactivated because they are not part of the public transport
> network. Unless we want to add data from NPTG to existing OSM stops
> (e.g. the locality code) this information is probably more relevant to
> the DoT than OSM.
> 
> However, since places in OSM might be derived from NPE maps, OSM-only
> places could also mean that the locality has been abandoned in the
> time since 1950. Your brief history of NPTG indicates to me that the
> data is probably much more recent then NPE's 1950 data. It might
> therefore be interesting to know which places are only in OSM and not
> even in the inactive NPTG data. Such places have then probably been
> abandoned a long time ago.
> 
> Christoph
> 
> > Roger
> > 
> > -----Original Message-
> > From: Christoph Böhme [mailto:christ...@b3e.net] 
> > Sent: 28 July 2009 22:54
> > To: ro...@slevin.plus.com; Public transport/transit/shared taxi
> > related topics
> > Cc: ro...@slevin.plus.com; 'Peter Miller'
> > Subject: Re: [Talk-transit] Naptan import
> > 
> > Roger,
> > 
> > thank you for your explanations.
> > 
> > "Roger Slevin"  schrieb:
> > 
> > >  Although NPTG was originally for public transport purposes, we
> > > stressed at all times that a locality should be listed even if it
> > > has no public transport - but we know that some local editors have
> > > probably erred towards marking some unserved rural hamlets as
> > > "inactive". 
> > > 
> > > All "inactive" localities should still be in the data - so hamlets
> > > which are missing may be in NPTG, but marked as "inactive".  
> > 
> > What would an inactive entry look like in the data? The xml schema
> > does not seem to define any elements/attributes for inactive
> > entries.
> > 
> > > However they may simply never have been in the source data - and
> > > no one to date has recognised the need to add them to NPTG.  It
> > > would be interesting to see what localities OSM holds in its data
> > > which are not included in NPTG (as well as the reverse of this)
> > > if that is possible.
> > 
> > I created two tables of OSM- and NTPG-only places:
> > 
> > http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz
> > http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz
> > 
> > I considered a place to be only in one dataset if no place from the
> > other dataset exists in its proximity which has the same name.
> > Proximity was defined as an euclidian distance less than 0.3 between
> > the lat/lon positions of the places (I don't know how this relates
> > to kilometres/miles). Since the OSM data contains some nodes with
> > place-tags that have nothing with actual places, I only included
> > nodes with a place-value of either locality, island, suburb, hamlet,
> > village, municipality, town or city. I also excluded place=farm.
> > 
> > Christoph
> > 
> 

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

I'll see whether it is possible to get a file exported which includes the 
"inactive" localities and let you know ... there may be some value in running a 
comparison between your 1950s data and the more recent data in NPTG.

Best wishes

Roger


-Original Message-
From: Christoph Böhme [mailto:christ...@b3e.net] 
Sent: 29 July 2009 18:36
To: ro...@slevin.plus.com
Cc: 'Public transport/transit/shared taxi related topics'; 'Peter Miller'
Subject: Re: [Talk-transit] Naptan import

"Roger Slevin"  schrieb:

> Christoph
> 
> Sorry - I now realise I shouldn't have referred to "inactive"
> localities ... this is something I can see on the editor system for
> NPTG, but the export only shows the active localities ... the records
> of the inactive ones are not included in the standard XML file.  I
> would need to check whether it is possible to get an extract from
> NPTG which includes inactive records (or only comprises the inactive
> ones) - but that is a question I will only ask if someone can suggest
> that some useful purpose could be served by having access to that
> data.

The only reason for using the inactive data I can see is a comparison
with OSM-only places. This could indicate NPTG places which might have
been deactivated because they are not part of the public transport
network. Unless we want to add data from NPTG to existing OSM stops
(e.g. the locality code) this information is probably more relevant to
the DoT than OSM.

However, since places in OSM might be derived from NPE maps, OSM-only
places could also mean that the locality has been abandoned in the time
since 1950. Your brief history of NPTG indicates to me that the data is
probably much more recent then NPE's 1950 data. It might therefore be
interesting to know which places are only in OSM and not even in the
inactive NPTG data. Such places have then probably been abandoned a
long time ago.

Christoph

> Roger
> 
> -Original Message-
> From: Christoph Böhme [mailto:christ...@b3e.net] 
> Sent: 28 July 2009 22:54
> To: ro...@slevin.plus.com; Public transport/transit/shared taxi
> related topics
> Cc: ro...@slevin.plus.com; 'Peter Miller'
> Subject: Re: [Talk-transit] Naptan import
> 
> Roger,
> 
> thank you for your explanations.
> 
> "Roger Slevin"  schrieb:
> 
> >  Although NPTG was originally for public transport purposes, we
> > stressed at all times that a locality should be listed even if it
> > has no public transport - but we know that some local editors have
> > probably erred towards marking some unserved rural hamlets as
> > "inactive". 
> > 
> > All "inactive" localities should still be in the data - so hamlets
> > which are missing may be in NPTG, but marked as "inactive".  
> 
> What would an inactive entry look like in the data? The xml schema
> does not seem to define any elements/attributes for inactive entries.
> 
> > However they may simply never have been in the source data - and no
> > one to date has recognised the need to add them to NPTG.  It would
> > be interesting to see what localities OSM holds in its data which
> > are not included in NPTG (as well as the reverse of this) if that is
> > possible.
> 
> I created two tables of OSM- and NTPG-only places:
> 
> http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz
> http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz
> 
> I considered a place to be only in one dataset if no place from the
> other dataset exists in its proximity which has the same name.
> Proximity was defined as an euclidian distance less than 0.3 between
> the lat/lon positions of the places (I don't know how this relates to
> kilometres/miles). Since the OSM data contains some nodes with
> place-tags that have nothing with actual places, I only included nodes
> with a place-value of either locality, island, suburb, hamlet,
> village, municipality, town or city. I also excluded place=farm.
> 
>   Christoph
> 


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

The polygon should be closed by linking the final entry back to the first
entry in the file for each PlusBus Zone

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Thomas Wood
Sent: 29 July 2009 22:58
To: Public transport/transit/shared taxi related topics
Subject: Re: [Talk-transit] Naptan import

2009/7/29 Christoph Böhme :
> Christoph Böhme  schrieb:
>> Thomas Wood  schrieb:
>> > 2009/7/29 Christoph Böhme :
>> > > Talking of the NaPTAN import: The NPTG data also contains polygons
>> > > for the Plusbus Zones. This data is self-contained and can easily
>> > > be imported. They could be either imported as ways tagged with
>> > > their zone code and their name or we could create an additional
>> > > relation that holds all the bus stops which are part of the zone
>> > > as well. The latter would, of course, only be necessary if there
>> > > are bus stops within the polygon which are not part of the zone
>> > > or vice versa.
>> >
>> > I tried to create a relation for plusbus zone stops from the NaPTAN
>> > data but there were simply too many - we quickly hit the OSM
>> > relation member maximum.
>>
>> Okay, that answers the question. I simple create a polygon then. I
>> suggest the following tagging scheme for the ways:
>>
>> public_transport=pay_scale_area
>> ref=Plusbus zone ref
>> name=Plusbus zone name
>>
>> Is pay scale area the correct general name for things like the plusbus
>> zones?
>
> I transformed the Plusbus Zones into a josm-file (XSLT is cool :-).
> Thomas can you import it using the naptan-user if no one objects to the
> tagging scheme?
>
> http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
>
> Cheers,
> Christoph
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>

That looks fine, the only issue is that none of the polygons are closed!

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/29 Christoph Böhme :
> Christoph Böhme  schrieb:
>> Thomas Wood  schrieb:
>> > 2009/7/29 Christoph Böhme :
>> > > Talking of the NaPTAN import: The NPTG data also contains polygons
>> > > for the Plusbus Zones. This data is self-contained and can easily
>> > > be imported. They could be either imported as ways tagged with
>> > > their zone code and their name or we could create an additional
>> > > relation that holds all the bus stops which are part of the zone
>> > > as well. The latter would, of course, only be necessary if there
>> > > are bus stops within the polygon which are not part of the zone
>> > > or vice versa.
>> >
>> > I tried to create a relation for plusbus zone stops from the NaPTAN
>> > data but there were simply too many - we quickly hit the OSM
>> > relation member maximum.
>>
>> Okay, that answers the question. I simple create a polygon then. I
>> suggest the following tagging scheme for the ways:
>>
>> public_transport=pay_scale_area
>> ref=Plusbus zone ref
>> name=Plusbus zone name
>>
>> Is pay scale area the correct general name for things like the plusbus
>> zones?
>
> I transformed the Plusbus Zones into a josm-file (XSLT is cool :-).
> Thomas can you import it using the naptan-user if no one objects to the
> tagging scheme?
>
> http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz
>
> Cheers,
> Christoph
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>

That looks fine, the only issue is that none of the polygons are closed!

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Christoph Böhme  schrieb:
> Thomas Wood  schrieb:
> > 2009/7/29 Christoph Böhme :
> > > Talking of the NaPTAN import: The NPTG data also contains polygons
> > > for the Plusbus Zones. This data is self-contained and can easily
> > > be imported. They could be either imported as ways tagged with
> > > their zone code and their name or we could create an additional
> > > relation that holds all the bus stops which are part of the zone
> > > as well. The latter would, of course, only be necessary if there
> > > are bus stops within the polygon which are not part of the zone
> > > or vice versa.
> > 
> > I tried to create a relation for plusbus zone stops from the NaPTAN
> > data but there were simply too many - we quickly hit the OSM
> > relation member maximum.
> 
> Okay, that answers the question. I simple create a polygon then. I
> suggest the following tagging scheme for the ways:
> 
> public_transport=pay_scale_area
> ref=Plusbus zone ref
> name=Plusbus zone name
> 
> Is pay scale area the correct general name for things like the plusbus
> zones?

I transformed the Plusbus Zones into a josm-file (XSLT is cool :-).
Thomas can you import it using the naptan-user if no one objects to the
tagging scheme? 

http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Thomas Wood  schrieb:
> 2009/7/29 Christoph Böhme :
> > Peter Miller  schrieb:
> >
> >> On 27 Jul 2009, at 22:14, Christoph Böhme wrote:
> >>
> >> > Hi
> >> >
> >> > "Roger Slevin"  schrieb:
> >> >
> >> >> Locality Classification was added as a possible "nice to have"
> >> >> to the version 2 schema but it has not been populated, and no
> >> >> guidance has been created to indicate how this field should be
> >> >> used (save for a table of permitted values).  There is no
> >> >> classification data in NPTG other than that which comes from the
> >> >> source - and that is only there because it could be ... I would
> >> >> not recommend its use as it is flaky, and offers nothing in
> >> >> respect of newly created locality entries in the Gazetteer.
> >> >
> >> > So, it looks like we will not have any classification
> >> > information. Unless we just want to import the plain names this
> >> > will complicate the import a bit as we have to somehow map the
> >> > locations to OSM place- types.
> >> > At the moment I am having three ideas how we could do this:
> >> >
> >> > Based on the parent relationship we could guess if a location
> >> > might be a suburb or village.
> >> >
> >> > Many places have wikipedia entries (even villages). If we can
> >> > manage to automatically look the entries up and extract the
> >> > relevant information (population size) from the info box we
> >> > could probably classify a lot of places.
> >> >
> >> > The landsat data might give us some hints about the size of
> >> > places. We just need to find a way to retrieve this information
> >> > automatically :-)
> >> >
> >> > Alternatively we could just invent a value for unclassified
> >> > places and wait for people to classify the places.
> >> >
> >>
> >> It seems that the NPTG data is less useful than it could have been
> >> because the the lack of classification data. We do of course also
> >> have access to locality names from other sources including NPE maps
> >> for places that are more than 50 years old and our eye-balls.
> >
> > Despite the lack of classification the NPTG data can still easily be
> > matched with the data already in OSM. So, while not being able to
> > import the whole dataset we could still add some data to existing
> > places if we want. The NPTG has the following to offer:
> >
> > - Administrative Area
> > - Atco Area Code
> > - NPTG District in parts of the county (do these districts have any
> >  relation with ceremonial/administrative counties?)
> > - NPTG locality reference
> > - Alternative names (e.g. welsh names)
> 
> NaPTAN includes this too, I was going to check whether the
> functionality was required as we started on Welsh/Scottish regions, I
> can't remember the reason for not implementing it immediately other
> than awkwardness of the way I was parsing.
>
> > - Short names
> > - Qualifiers for duplicate names
> >
> > Do you think we should import any of this? Especially when taking
> > the NaPTAN import into acconut the Atco Area Code or NPTG locality
> > references might become handy, I reckon.
> 
> I'm not currently handling the NPTG locality ref. If it's deemed
> useful, we can probably do something with it.

Most of this information is probably only useful to find out in which
locality, district or area a stop or locality is. Since OSM will
(hopefully) contain boundaries which describe the extents it might not
be necessary to explicitly tag were a bus stop or locality is.
 
> > Talking of the NaPTAN import: The NPTG data also contains polygons
> > for the Plusbus Zones. This data is self-contained and can easily be
> > imported. They could be either imported as ways tagged with their
> > zone code and their name or we could create an additional relation
> > that holds all the bus stops which are part of the zone as well.
> > The latter would, of course, only be necessary if there are bus
> > stops within the polygon which are not part of the zone or vice
> > versa.
> 
> I tried to create a relation for plusbus zone stops from the NaPTAN
> data but there were simply too many - we quickly hit the OSM relation
> member maximum.

Okay, that answers the question. I simple create a polygon then. I
suggest the following tagging scheme for the ways:

public_transport=pay_scale_area
ref=Plusbus zone ref
name=Plusbus zone name

Is pay scale area the correct general name for things like the plusbus
zones?

Christoph

> >> Possibly we just provide NPTG data as a useful 'free' data overlay
> >> for creating localities in OSM in association with data from NPE
> >> but don't spend too long trying to do an automatic import of that
> >> data.
> >
> > I am of the same opinion. Most of the missing places in OSM are
> > small hamlets, villages and suburbs and it is going to be really
> > difficult to automatically distinguish these automatically. So, I
> > will rather improve the NPTG viewer a bit so that it does not
> > display NPTG places which are already in OSM anymore. This tool can
> > then be

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/29 Christoph Böhme :
> Peter Miller  schrieb:
>
>> On 27 Jul 2009, at 22:14, Christoph Böhme wrote:
>>
>> > Hi
>> >
>> > "Roger Slevin"  schrieb:
>> >
>> >> Locality Classification was added as a possible "nice to have" to
>> >> the version 2 schema but it has not been populated, and no
>> >> guidance has been created to indicate how this field should be
>> >> used (save for a table of permitted values).  There is no
>> >> classification data in NPTG other than that which comes from the
>> >> source - and that is only there because it could be ... I would
>> >> not recommend its use as it is flaky, and offers nothing in
>> >> respect of newly created locality entries in the Gazetteer.
>> >
>> > So, it looks like we will not have any classification information.
>> > Unless we just want to import the plain names this will complicate
>> > the import a bit as we have to somehow map the locations to OSM
>> > place- types.
>> > At the moment I am having three ideas how we could do this:
>> >
>> > Based on the parent relationship we could guess if a location might
>> > be a suburb or village.
>> >
>> > Many places have wikipedia entries (even villages). If we can manage
>> > to automatically look the entries up and extract the relevant
>> > information (population size) from the info box we could probably
>> > classify a lot of places.
>> >
>> > The landsat data might give us some hints about the size of places.
>> > We just need to find a way to retrieve this information
>> > automatically :-)
>> >
>> > Alternatively we could just invent a value for unclassified places
>> > and wait for people to classify the places.
>> >
>>
>> It seems that the NPTG data is less useful than it could have been
>> because the the lack of classification data. We do of course also
>> have access to locality names from other sources including NPE maps
>> for places that are more than 50 years old and our eye-balls.
>
> Despite the lack of classification the NPTG data can still easily be
> matched with the data already in OSM. So, while not being able to
> import the whole dataset we could still add some data to existing
> places if we want. The NPTG has the following to offer:
>
> - Administrative Area
> - Atco Area Code
> - NPTG District in parts of the county (do these districts have any
>  relation with ceremonial/administrative counties?)
> - NPTG locality reference
> - Alternative names (e.g. welsh names)

NaPTAN includes this too, I was going to check whether the
functionality was required as we started on Welsh/Scottish regions, I
can't remember the reason for not implementing it immediately other
than awkwardness of the way I was parsing.

> - Short names
> - Qualifiers for duplicate names
>
> Do you think we should import any of this? Especially when taking
> the NaPTAN import into acconut the Atco Area Code or NPTG locality
> references might become handy, I reckon.

I'm not currently handling the NPTG locality ref. If it's deemed
useful, we can probably do something with it.

> Talking of the NaPTAN import: The NPTG data also contains polygons for
> the Plusbus Zones. This data is self-contained and can easily be
> imported. They could be either imported as ways tagged with their zone
> code and their name or we could create an additional relation that
> holds all the bus stops which are part of the zone as well. The latter
> would, of course, only be necessary if there are bus stops within the
> polygon which are not part of the zone or vice versa.

I tried to create a relation for plusbus zone stops from the NaPTAN
data but there were simply too many - we quickly hit the OSM relation
member maximum.

>> Possibly we just provide NPTG data as a useful 'free' data overlay
>> for creating localities in OSM in association with data from NPE but
>> don't spend too long trying to do an automatic import of that data.
>
> I am of the same opinion. Most of the missing places in OSM are small
> hamlets, villages and suburbs and it is going to be really difficult to
> automatically distinguish these automatically. So, I will rather improve
> the NPTG viewer a bit so that it does not display NPTG places which are
> already in OSM anymore. This tool can then be used as a guide to find
> umapped places.
>
>> You mention matching localities up with Wikipedia. I see no
>> licensing issues with using data from Wikipieda as far as I am aware
>> btw. Would be great to tie places up with Wikipedia and possibly also
>> with woeids (http://developer.yahoo.com/geo/geoplanet/) but that
>> could be something for later.
>
> We should keep this in mind. Although, I am not sure if it makes much
> sense to add tags to OSM in a completely automated process as this
> information can easily be applied when its needed.
>
> Cheers,
> Christoph
>
>>
>>
>> Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>>
>> > Do you have any other ideas?
>> >
>> >     Cheers,
>> >     Christoph
>> >
>> > ___
>> > Talk-transit mailin

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Peter Miller  schrieb:

> On 27 Jul 2009, at 22:14, Christoph Böhme wrote:
> 
> > Hi
> >
> > "Roger Slevin"  schrieb:
> >
> >> Locality Classification was added as a possible "nice to have" to
> >> the version 2 schema but it has not been populated, and no
> >> guidance has been created to indicate how this field should be
> >> used (save for a table of permitted values).  There is no
> >> classification data in NPTG other than that which comes from the
> >> source - and that is only there because it could be ... I would
> >> not recommend its use as it is flaky, and offers nothing in
> >> respect of newly created locality entries in the Gazetteer.
> >
> > So, it looks like we will not have any classification information.
> > Unless we just want to import the plain names this will complicate
> > the import a bit as we have to somehow map the locations to OSM
> > place- types.
> > At the moment I am having three ideas how we could do this:
> >
> > Based on the parent relationship we could guess if a location might
> > be a suburb or village.
> >
> > Many places have wikipedia entries (even villages). If we can manage
> > to automatically look the entries up and extract the relevant
> > information (population size) from the info box we could probably
> > classify a lot of places.
> >
> > The landsat data might give us some hints about the size of places.
> > We just need to find a way to retrieve this information
> > automatically :-)
> >
> > Alternatively we could just invent a value for unclassified places
> > and wait for people to classify the places.
> >
> 
> It seems that the NPTG data is less useful than it could have been  
> because the the lack of classification data. We do of course also
> have access to locality names from other sources including NPE maps
> for places that are more than 50 years old and our eye-balls.

Despite the lack of classification the NPTG data can still easily be
matched with the data already in OSM. So, while not being able to
import the whole dataset we could still add some data to existing
places if we want. The NPTG has the following to offer:

- Administrative Area
- Atco Area Code 
- NPTG District in parts of the county (do these districts have any
  relation with ceremonial/administrative counties?)
- NPTG locality reference
- Alternative names (e.g. welsh names)
- Short names
- Qualifiers for duplicate names

Do you think we should import any of this? Especially when taking 
the NaPTAN import into acconut the Atco Area Code or NPTG locality
references might become handy, I reckon.

Talking of the NaPTAN import: The NPTG data also contains polygons for
the Plusbus Zones. This data is self-contained and can easily be
imported. They could be either imported as ways tagged with their zone
code and their name or we could create an additional relation that
holds all the bus stops which are part of the zone as well. The latter
would, of course, only be necessary if there are bus stops within the
polygon which are not part of the zone or vice versa.

> Possibly we just provide NPTG data as a useful 'free' data overlay
> for creating localities in OSM in association with data from NPE but
> don't spend too long trying to do an automatic import of that data.

I am of the same opinion. Most of the missing places in OSM are small
hamlets, villages and suburbs and it is going to be really difficult to
automatically distinguish these automatically. So, I will rather improve
the NPTG viewer a bit so that it does not display NPTG places which are
already in OSM anymore. This tool can then be used as a guide to find
umapped places.

> You mention matching localities up with Wikipedia. I see no
> licensing issues with using data from Wikipieda as far as I am aware
> btw. Would be great to tie places up with Wikipedia and possibly also
> with woeids (http://developer.yahoo.com/geo/geoplanet/) but that
> could be something for later.

We should keep this in mind. Although, I am not sure if it makes much
sense to add tags to OSM in a completely automated process as this
information can easily be applied when its needed.

Cheers,
Christoph
 
> 
> 
> Regards,
> 
> 
> 
> Peter
> 
> 
> 
> 
> > Do you have any other ideas?
> >
> > Cheers,
> > Christoph
> >
> > ___
> > Talk-transit mailing list
> > Talk-transit@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-transit
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

"Roger Slevin"  schrieb:

> Christoph
> 
> Sorry - I now realise I shouldn't have referred to "inactive"
> localities ... this is something I can see on the editor system for
> NPTG, but the export only shows the active localities ... the records
> of the inactive ones are not included in the standard XML file.  I
> would need to check whether it is possible to get an extract from
> NPTG which includes inactive records (or only comprises the inactive
> ones) - but that is a question I will only ask if someone can suggest
> that some useful purpose could be served by having access to that
> data.

The only reason for using the inactive data I can see is a comparison
with OSM-only places. This could indicate NPTG places which might have
been deactivated because they are not part of the public transport
network. Unless we want to add data from NPTG to existing OSM stops
(e.g. the locality code) this information is probably more relevant to
the DoT than OSM.

However, since places in OSM might be derived from NPE maps, OSM-only
places could also mean that the locality has been abandoned in the time
since 1950. Your brief history of NPTG indicates to me that the data is
probably much more recent then NPE's 1950 data. It might therefore be
interesting to know which places are only in OSM and not even in the
inactive NPTG data. Such places have then probably been abandoned a
long time ago.

Christoph

> Roger
> 
> -Original Message-
> From: Christoph Böhme [mailto:christ...@b3e.net] 
> Sent: 28 July 2009 22:54
> To: ro...@slevin.plus.com; Public transport/transit/shared taxi
> related topics
> Cc: ro...@slevin.plus.com; 'Peter Miller'
> Subject: Re: [Talk-transit] Naptan import
> 
> Roger,
> 
> thank you for your explanations.
> 
> "Roger Slevin"  schrieb:
> 
> >  Although NPTG was originally for public transport purposes, we
> > stressed at all times that a locality should be listed even if it
> > has no public transport - but we know that some local editors have
> > probably erred towards marking some unserved rural hamlets as
> > "inactive". 
> > 
> > All "inactive" localities should still be in the data - so hamlets
> > which are missing may be in NPTG, but marked as "inactive".  
> 
> What would an inactive entry look like in the data? The xml schema
> does not seem to define any elements/attributes for inactive entries.
> 
> > However they may simply never have been in the source data - and no
> > one to date has recognised the need to add them to NPTG.  It would
> > be interesting to see what localities OSM holds in its data which
> > are not included in NPTG (as well as the reverse of this) if that is
> > possible.
> 
> I created two tables of OSM- and NTPG-only places:
> 
> http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz
> http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz
> 
> I considered a place to be only in one dataset if no place from the
> other dataset exists in its proximity which has the same name.
> Proximity was defined as an euclidian distance less than 0.3 between
> the lat/lon positions of the places (I don't know how this relates to
> kilometres/miles). Since the OSM data contains some nodes with
> place-tags that have nothing with actual places, I only included nodes
> with a place-value of either locality, island, suburb, hamlet,
> village, municipality, town or city. I also excluded place=farm.
> 
>   Christoph
> 

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/26 Christoph Böhme :
> I am happy to continue working on the NPTG import if Thomas does not
> mind.

Yes, that's fine, NPTG isn't really an interest of mine, as I think I
insinuated on the wikipage writeup of the format.

2009/7/27 Peter Miller :
> My vote is to get on with it - the NPTG and NaPTAN imports are different
> enough that they can be handled separately. If Thomas focuses on the NaPTAN
> import (or hands it over to someone) and you do the NPTG then I think we
> will get there faster.

I am willing to continue. I've just spent the past few days fixing and
refactoring the bulk_upload.py script.
I just need to write a wrapper for it to simplify the NaPTAN uploads,
and we're good to go.

> Would it be worth creating a NPTG Import wiki page and an NPTG Import user
> to do the actual import - ie, keep the documentation and audit trail for the
> two imports separate?

So far they're quite closely linked on the wiki, a separate NPTG
Import user would probably make sense.

2009/7/22 Peter Miller :
> Do we need to set up a wiki page where people can request imports
> for their authority or are we going to do it without that?

http://wiki.openstreetmap.org/wiki/NaPTAN/Request_for_Import

I need to flesh out what the column headings mean.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Christoph

Sorry - I now realise I shouldn't have referred to "inactive" localities ...
this is something I can see on the editor system for NPTG, but the export
only shows the active localities ... the records of the inactive ones are
not included in the standard XML file.  I would need to check whether it is
possible to get an extract from NPTG which includes inactive records (or
only comprises the inactive ones) - but that is a question I will only ask
if someone can suggest that some useful purpose could be served by having
access to that data.

Roger

-Original Message-
From: Christoph Böhme [mailto:christ...@b3e.net] 
Sent: 28 July 2009 22:54
To: ro...@slevin.plus.com; Public transport/transit/shared taxi related
topics
Cc: ro...@slevin.plus.com; 'Peter Miller'
Subject: Re: [Talk-transit] Naptan import

Roger,

thank you for your explanations.

"Roger Slevin"  schrieb:

>  Although NPTG was originally for public transport purposes, we
> stressed at all times that a locality should be listed even if it has
> no public transport - but we know that some local editors have
> probably erred towards marking some unserved rural hamlets as
> "inactive". 
> 
> All "inactive" localities should still be in the data - so hamlets
> which are missing may be in NPTG, but marked as "inactive".  

What would an inactive entry look like in the data? The xml schema does
not seem to define any elements/attributes for inactive entries.

> However they may simply never have been in the source data - and no
> one to date has recognised the need to add them to NPTG.  It would be
> interesting to see what localities OSM holds in its data which are
> not included in NPTG (as well as the reverse of this) if that is
> possible.

I created two tables of OSM- and NTPG-only places:

http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz
http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz

I considered a place to be only in one dataset if no place from the
other dataset exists in its proximity which has the same name.
Proximity was defined as an euclidian distance less than 0.3 between
the lat/lon positions of the places (I don't know how this relates to
kilometres/miles). Since the OSM data contains some nodes with
place-tags that have nothing with actual places, I only included nodes
with a place-value of either locality, island, suburb, hamlet, village,
municipality, town or city. I also excluded place=farm.

Christoph


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Roger,

thank you for your explanations.

"Roger Slevin"  schrieb:

>  Although NPTG was originally for public transport purposes, we
> stressed at all times that a locality should be listed even if it has
> no public transport - but we know that some local editors have
> probably erred towards marking some unserved rural hamlets as
> "inactive". 
> 
> All "inactive" localities should still be in the data - so hamlets
> which are missing may be in NPTG, but marked as "inactive".  

What would an inactive entry look like in the data? The xml schema does
not seem to define any elements/attributes for inactive entries.

> However they may simply never have been in the source data - and no
> one to date has recognised the need to add them to NPTG.  It would be
> interesting to see what localities OSM holds in its data which are
> not included in NPTG (as well as the reverse of this) if that is
> possible.

I created two tables of OSM- and NTPG-only places:

http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz
http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz

I considered a place to be only in one dataset if no place from the
other dataset exists in its proximity which has the same name.
Proximity was defined as an euclidian distance less than 0.3 between
the lat/lon positions of the places (I don't know how this relates to
kilometres/miles). Since the OSM data contains some nodes with
place-tags that have nothing with actual places, I only included nodes
with a place-value of either locality, island, suburb, hamlet, village,
municipality, town or city. I also excluded place=farm.

Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Peter Miller]

On 28 Jul 2009, at 18:41, Christoph Böhme wrote:

> o...@edwardbetts.com schrieb:
>
>> Christoph Böhme  wrote:
>>> Many places have wikipedia entries (even villages). If we can manage
>>> to automatically look the entries up and extract the relevant
>>> information (population size) from the info box we could probably
>>> classify a lot of places.
>>
>> I'm afraid we can't use population data, it is under Crown Copyright.
>
> I don't know much about the licencing but I find it slightly odd that
> Wikipedia can distribute its contents under a CC-BY-SA licene when it
> contains information that is under a more restrictive licence. How  
> am I
> supposed to know that population numbers are not covered by the
> CC-BY-SA licence?
>
> I don't want to start a huge discussion here about the legal issues of
> using the population numbers. I'm just curious to learn why Crown
> Copyrighted data can be in Wikipedia.

All information in Wikipedia must be sourced from elsewhere because it  
must be verifiable. (see http://en.wikipedia.org/wiki/Wikipedia:Verifiability)

References should be to reputable sources, such as top newspapers etc.  
There are guidelines ensuring that copyright material is not used  
excessively (http://en.wikipedia.org/wiki/Wikipedia:Non-free_content)  
but in summary it seems that as long as an article is made of  
information taken from many sources and written for Wikipedia and is  
not cut and pasted from one source then it has been 'freed'.

It is then possible to take information from Wikipedia and reuse it  
with acknowledgement as per the following:

"Permission to reproduce and modify text on Wikipedia has already been  
granted to anyone anywhere by the authors of individual articles as  
long as such reproduction and modification complies with licensing  
terms (see below and Wikipedia:Mirrors and forks for specific terms).  
Images may or may not permit reuse and modification; the conditions  
for reproduction of each image should be individually checked. The  
only exceptions are those cases in which editors have violated  
Wikipedia policy by uploading copyrighted material without  
authorization, or with copyright licensing terms which are  
incompatible with those Wikipedia authors have applied to the rest of  
Wikipedia content. While such material is present on the Wikipedia  
(before it is detected and removed), it will be a copyright violation  
to copy it. For permission to use it, one must contact the owner of  
the copyright of the text or illustration in question; often, but not  
always, this will be the original author.
http://en.wikipedia.org/wiki/Wikipedia:Copyrights


Regards,



Peter

>
> Christoph
>
>
>
>> -- 
>> Edward.
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

o...@edwardbetts.com schrieb:

> Christoph Böhme  wrote:
> > Many places have wikipedia entries (even villages). If we can manage
> > to automatically look the entries up and extract the relevant
> > information (population size) from the info box we could probably
> > classify a lot of places.
> 
> I'm afraid we can't use population data, it is under Crown Copyright.

I don't know much about the licencing but I find it slightly odd that
Wikipedia can distribute its contents under a CC-BY-SA licene when it
contains information that is under a more restrictive licence. How am I
supposed to know that population numbers are not covered by the
CC-BY-SA licence?

I don't want to start a huge discussion here about the legal issues of
using the population numbers. I'm just curious to learn why Crown
Copyrighted data can be in Wikipedia.

Christoph



> -- 
> Edward.
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Peter Miller]

On 27 Jul 2009, at 22:14, Christoph Böhme wrote:

> Hi
>
> "Roger Slevin"  schrieb:
>
>> Locality Classification was added as a possible "nice to have" to the
>> version 2 schema but it has not been populated, and no guidance has
>> been created to indicate how this field should be used (save for a
>> table of permitted values).  There is no classification data in NPTG
>> other than that which comes from the source - and that is only there
>> because it could be ... I would not recommend its use as it is flaky,
>> and offers nothing in respect of newly created locality entries in
>> the Gazetteer.
>
> So, it looks like we will not have any classification information.
> Unless we just want to import the plain names this will complicate the
> import a bit as we have to somehow map the locations to OSM place- 
> types.
> At the moment I am having three ideas how we could do this:
>
> Based on the parent relationship we could guess if a location might
> be a suburb or village.
>
> Many places have wikipedia entries (even villages). If we can manage
> to automatically look the entries up and extract the relevant
> information (population size) from the info box we could probably
> classify a lot of places.
>
> The landsat data might give us some hints about the size of places. We
> just need to find a way to retrieve this information automatically :-)
>
> Alternatively we could just invent a value for unclassified places and
> wait for people to classify the places.
>

It seems that the NPTG data is less useful than it could have been  
because the the lack of classification data. We do of course also have  
access to locality names from other sources including NPE maps for  
places that are more than 50 years old and our eye-balls.

Possibly we just provide NPTG data as a useful 'free' data overlay for  
creating localities in OSM in association with data from NPE but don't  
spend too long trying to do an automatic import of that data.

You mention matching localities up with Wikipedia. I see no licensing  
issues with using data from Wikipieda as far as I am aware btw. Would  
be great to tie places up with Wikipedia and possibly also with woeids  
(http://developer.yahoo.com/geo/geoplanet/) but that could be  
something for later.



Regards,



Peter




> Do you have any other ideas?
>
>   Cheers,
>   Christoph
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[osm]

Christoph Böhme  wrote:
> Many places have wikipedia entries (even villages). If we can manage
> to automatically look the entries up and extract the relevant
> information (population size) from the info box we could probably
> classify a lot of places.

I'm afraid we can't use population data, it is under Crown Copyright.

-- 
Edward.

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Chris Hill]

Christoph Böhme wrote:
> Hi
>
> "Roger Slevin"  schrieb:
>
>   
>> Locality Classification was added as a possible "nice to have" to the
>> version 2 schema but it has not been populated, and no guidance has
>> been created to indicate how this field should be used (save for a
>> table of permitted values).  There is no classification data in NPTG
>> other than that which comes from the source - and that is only there
>> because it could be ... I would not recommend its use as it is flaky,
>> and offers nothing in respect of newly created locality entries in
>> the Gazetteer.
>> 
>
> So, it looks like we will not have any classification information.
> Unless we just want to import the plain names this will complicate the
> import a bit as we have to somehow map the locations to OSM place-types.
> At the moment I am having three ideas how we could do this:
>
> Based on the parent relationship we could guess if a location might
> be a suburb or village.
>
> Many places have wikipedia entries (even villages). If we can manage
> to automatically look the entries up and extract the relevant
> information (population size) from the info box we could probably
> classify a lot of places.
>
> The landsat data might give us some hints about the size of places. We
> just need to find a way to retrieve this information automatically :-)
>
> Alternatively we could just invent a value for unclassified places and
> wait for people to classify the places.
>
> Do you have any other ideas?
>
>   
Ask for local experts.  I have maintained a list of places in East 
Yorkshire in the wiki.  There are about 280 villages and hamlets.  I've 
visited almost 90% to map them and assess if they are really still a 
place.  Many have been added from NPE and they just don't exist on the 
ground any more.  I then judge village versus hamlet on criteria, like 
size, is there a school, church, shop etc. and what does the Wikipedia 
entry or other web sites say.  I then add local knowledge.

Having done this work I would prefer that a bulk upload doesn't add 
places in the county without prior discussion.  You would probably be 
able to find someone to do a sanity check like this for many (most? 
all?) areas.  My experience is that sources of UK places need human 
intervention to make them useful.

Cheers, Chris

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

One other possibility that might work would be to look at the number of bus
stops associated with a locality - something fairly easy to measure from
NaPTAN.  Combine this with the parent / child locality relationship could
give you a way of expressing a sort of locality type classification.

Roger


-Original Message-
From: Christoph Böhme [mailto:christ...@b3e.net] 
Sent: 27 July 2009 22:14
To: ro...@slevin.plus.com
Cc: 'Public transport/transit/shared taxi related topics'
Subject: Re: [Talk-transit] Naptan import

Hi

"Roger Slevin"  schrieb:

> Locality Classification was added as a possible "nice to have" to the
> version 2 schema but it has not been populated, and no guidance has
> been created to indicate how this field should be used (save for a
> table of permitted values).  There is no classification data in NPTG
> other than that which comes from the source - and that is only there
> because it could be ... I would not recommend its use as it is flaky,
> and offers nothing in respect of newly created locality entries in
> the Gazetteer.

So, it looks like we will not have any classification information.
Unless we just want to import the plain names this will complicate the
import a bit as we have to somehow map the locations to OSM place-types.
At the moment I am having three ideas how we could do this:

Based on the parent relationship we could guess if a location might
be a suburb or village.

Many places have wikipedia entries (even villages). If we can manage
to automatically look the entries up and extract the relevant
information (population size) from the info box we could probably
classify a lot of places.

The landsat data might give us some hints about the size of places. We
just need to find a way to retrieve this information automatically :-)

Alternatively we could just invent a value for unclassified places and
wait for people to classify the places.

Do you have any other ideas?

Cheers,
Christoph


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Hi

"Roger Slevin"  schrieb:

> Locality Classification was added as a possible "nice to have" to the
> version 2 schema but it has not been populated, and no guidance has
> been created to indicate how this field should be used (save for a
> table of permitted values).  There is no classification data in NPTG
> other than that which comes from the source - and that is only there
> because it could be ... I would not recommend its use as it is flaky,
> and offers nothing in respect of newly created locality entries in
> the Gazetteer.

So, it looks like we will not have any classification information.
Unless we just want to import the plain names this will complicate the
import a bit as we have to somehow map the locations to OSM place-types.
At the moment I am having three ideas how we could do this:

Based on the parent relationship we could guess if a location might
be a suburb or village.

Many places have wikipedia entries (even villages). If we can manage
to automatically look the entries up and extract the relevant
information (population size) from the info box we could probably
classify a lot of places.

The landsat data might give us some hints about the size of places. We
just need to find a way to retrieve this information automatically :-)

Alternatively we could just invent a value for unclassified places and
wait for people to classify the places.

Do you have any other ideas?

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

You ask about the omissions from NPTG.  Perhaps it would be helpful if I 
described the history of creating NPTG and what the brief has been to local 
data editors in terms of what is or is not included in the database.

NPTG started life as a national statistical gazetteer based on a collation of 
different statistical areas (parishes, journey to work areas, towns, cities, 
etc).  A number of unwanted types of entity in that source data were marked as 
inactive (things like area parishes which cover several villages) - and local 
editors were briefed to remove other sources of duplication.

We then had the difficulty of determining what is, and what is not, a locality. 
 The guidance we have given has been that a locality is a place which locals 
would consider they lived in, worked in, were educated in etc ... and/or to 
which highway engineers would consider it appropriate to show on road direction 
signs.  Although NPTG was originally for public transport purposes, we stressed 
at all times that a locality should be listed even if it has no public 
transport - but we know that some local editors have probably erred towards 
marking some unserved rural hamlets as "inactive". 

All "inactive" localities should still be in the data - so hamlets which are 
missing may be in NPTG, but marked as "inactive".  However they may simply 
never have been in the source data - and no one to date has recognised the need 
to add them to NPTG.  It would be interesting to see what localities OSM holds 
in its data which are not included in NPTG (as well as the reverse of this) if 
that is possible.

I hope this helps your understanding of the background.

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org 
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme
Sent: 27 July 2009 21:50
To: Peter Miller
Cc: talk-transit@openstreetmap.org
Subject: Re: [Talk-transit] Naptan import

Good evening,

Peter Miller  schrieb:
> On 26 Jul 2009, at 22:14, Christoph Böhme wrote:
> > I also created a copy of the NOVAM viewer and changed it to display
> > NTPG data instead of bus stops:
> >
> > http://www.mappa-mercia.org/cgi-bin/nptg.wsgi/viewer.html
> 
> Great stuff, and clearly there are many additional place-names in
> NPTG that are not in OSM a present in many parts of the county. I
> checked North Norfolk and bits of Scotland and there are a good
> number of additional places.

I have now also added all nodes with place=* tags from OSM. The NPTG
import will really add a lot of additional places! OSM has only 25397
places in the UK at the moment. However, I was a bit suprised to see
some hamlets in the OSM data which are not in the NPTG data. Do you
know of any gaps in the NPTG data?

> The LocalityClassification field should be more useful and should  
> contain city, town, village, hamlet, suburb, urbancentre, place of  
> interest, other, or unrecorded. I am not sure how well this field is  
> populated - possibly it is not well populated at all. UrbanCentre
> can possibly be ignored.  

The LocalityClassification tag is used 856 times in the dataset. That is
about 2% of all localities.

> The field may be well populated in some parts of the country and not
> in other. I am not sure how much NPTG is used for Points of Interest.
> There is a POI model in NPTG but possibly we treat this separately or
> not at all or import the data as invisible to start with. My main
> interest is the locality names and the main technical job will
> probably be to spot duplicates with what is in OSM already.

Finding duplicates should not be too difficult. We basically just need
to check for each imported location if there are any places with the
same name within a reasonable distance. Except for typos and different
spellings that should work very well. The positions of locations in
both datasets also match nicely which should make it even easier to
find duplicates.

> Would it be worth creating a NPTG Import wiki page and an NPTG
> Import user to do the actual import - ie, keep the documentation and
> audit trail for the two imports separate?

I am in favour of keeping them separate. Both datasets are fairly
independent and we will probably use different methods to import them.
Having everything on one wiki page will be confusing to users, who might
be interested only in one of the imports.

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Good evening,

Peter Miller  schrieb:
> On 26 Jul 2009, at 22:14, Christoph Böhme wrote:
> > I also created a copy of the NOVAM viewer and changed it to display
> > NTPG data instead of bus stops:
> >
> > http://www.mappa-mercia.org/cgi-bin/nptg.wsgi/viewer.html
> 
> Great stuff, and clearly there are many additional place-names in
> NPTG that are not in OSM a present in many parts of the county. I
> checked North Norfolk and bits of Scotland and there are a good
> number of additional places.

I have now also added all nodes with place=* tags from OSM. The NPTG
import will really add a lot of additional places! OSM has only 25397
places in the UK at the moment. However, I was a bit suprised to see
some hamlets in the OSM data which are not in the NPTG data. Do you
know of any gaps in the NPTG data?

> The LocalityClassification field should be more useful and should  
> contain city, town, village, hamlet, suburb, urbancentre, place of  
> interest, other, or unrecorded. I am not sure how well this field is  
> populated - possibly it is not well populated at all. UrbanCentre
> can possibly be ignored.  

The LocalityClassification tag is used 856 times in the dataset. That is
about 2% of all localities.

> The field may be well populated in some parts of the country and not
> in other. I am not sure how much NPTG is used for Points of Interest.
> There is a POI model in NPTG but possibly we treat this separately or
> not at all or import the data as invisible to start with. My main
> interest is the locality names and the main technical job will
> probably be to spot duplicates with what is in OSM already.

Finding duplicates should not be too difficult. We basically just need
to check for each imported location if there are any places with the
same name within a reasonable distance. Except for typos and different
spellings that should work very well. The positions of locations in
both datasets also match nicely which should make it even easier to
find duplicates.

> Would it be worth creating a NPTG Import wiki page and an NPTG
> Import user to do the actual import - ie, keep the documentation and
> audit trail for the two imports separate?

I am in favour of keeping them separate. Both datasets are fairly
independent and we will probably use different methods to import them.
Having everything on one wiki page will be confusing to users, who might
be interested only in one of the imports.

Cheers,
Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Roger Slevin]

Peter

Locality Classification was added as a possible "nice to have" to the
version 2 schema but it has not been populated, and no guidance has been
created to indicate how this field should be used (save for a table of
permitted values).  There is no classification data in NPTG other than that
which comes from the source - and that is only there because it could be ...
I would not recommend its use as it is flaky, and offers nothing in respect
of newly created locality entries in the Gazetteer.

NPTG is NOT a POI directory - and whilst there are some incorrectly created
localities for POIs we are seeking to get them removed unless they genuinely
define a locality (so the only ones that are appropriate are those which
relate to large area POIs that do not sit happily within general-purpose
POIs.

The data that is recognised as valid at present is only that which appears
in v2 CSV lists ... anything which is in the XML that is not in the CSV
output is almost certainly not populated and certainly should be ignored.

Roger

-Original Message-
From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Peter Miller
Sent: 27 July 2009 08:52
To: Christoph Böhme
Cc: talk-transit@openstreetmap.org
Subject: Re: [Talk-transit] Naptan import


On 26 Jul 2009, at 22:14, Christoph Böhme wrote:

> Hi
>
> Peter Miller  schrieb:
>> I am also aware that there is a 50K place gazetteer sitting there
>> untouched - last week I was adding villages in Norfolk by hand and
>> the data is sitting available in NPTG.
>
> I taught myself XSLT at the weekend and played a bit with the NPTG
> data. On http://www.mappa-mercia.org/nptg/ you can find some html- 
> pages
> which show the hierarchies of and adjacencies between the localities  
> in
> the NTPG data.
>
> I also created a copy of the NOVAM viewer and changed it to display
> NTPG data instead of bus stops:
>
> http://www.mappa-mercia.org/cgi-bin/nptg.wsgi/viewer.html

Great stuff, and clearly there are many additional place-names in NPTG  
that are not in OSM a present in many parts of the county. I checked  
North Norfolk and bits of Scotland and there are a good number of  
additional places.

>
> I have not changed any of the texts/images yet, so the localities will
> be displayed as bus stops :-). I will try to import an excerpt of  
> place
> names from OSM tomorrow so that we can compare both data sets.
>
> From what I have seen so far an import should not be too difficult.  
> The
> only difficulties I expect are the hierarchies and the classification
> of the localities.
>
> Does anyone know the current way to tag hierarchies of places? I had a
> look at the wiki and there seem to be two approaches: is_in and
> relations. With the addition of actual borders there is also the
> possibility of defining hierarchies purely geometrical.
>
> The location classifications in the NPTG seem to be relatively coarse.
> Everything below a parish is either a "New Entry" (Add) or a Locality.
> We need to see how this can be mapped to POI types in OSM.

SourceLocalityType is, I think, information about where the data came  
from in the first place into NPTG and is not relevant for our  
purposes, and certainly into the classification field.

The LocalityClassification field should be more useful and should  
contain city, town, village, hamlet, suburb, urbancentre, place of  
interest, other, or unrecorded. I am not sure how well this field is  
populated - possibly it is not well populated at all. UrbanCentre can  
possibly be ignored.  The field may be well populated in some parts of  
the country and not in other. I am not sure how much NPTG is used for  
Points of Interest. There is a POI model in NPTG but possibly we treat  
this separately or not at all or import the data as invisible to start  
with. My main interest is the locality names and the main technical  
job will probably be to spot duplicates with what is in OSM already.

See page 69 in the NaPTAN and NPTG scheme guide for more details of  
the formatting.
http://www.naptan.org.uk/documentation.htm

>
>> Do you need help with the NaPTAN import or are you just about ready
>> to do the work? Do we need to set up a wiki page where people can
>> request imports for their authority or are we going to do it without
>> that?
>

It would be really really good to get NaPTAN in and in soon. There are  
people keen to get on with sorting the data out in their areas who are  
sitting on their hands at present, the professional transport  
community is watching what is happening closely, and there are also  
possibly other datasets from UK authorities that could come our way  
when we have completed this one.

> I am happy to continue working on the NPTG import if Thomas does not
> mind.

My vote is t

Re: [Talk-transit] Naptan import

[Peter Miller]

On 26 Jul 2009, at 22:14, Christoph Böhme wrote:

> Hi
>
> Peter Miller  schrieb:
>> I am also aware that there is a 50K place gazetteer sitting there
>> untouched - last week I was adding villages in Norfolk by hand and
>> the data is sitting available in NPTG.
>
> I taught myself XSLT at the weekend and played a bit with the NPTG
> data. On http://www.mappa-mercia.org/nptg/ you can find some html- 
> pages
> which show the hierarchies of and adjacencies between the localities  
> in
> the NTPG data.
>
> I also created a copy of the NOVAM viewer and changed it to display
> NTPG data instead of bus stops:
>
> http://www.mappa-mercia.org/cgi-bin/nptg.wsgi/viewer.html

Great stuff, and clearly there are many additional place-names in NPTG  
that are not in OSM a present in many parts of the county. I checked  
North Norfolk and bits of Scotland and there are a good number of  
additional places.

>
> I have not changed any of the texts/images yet, so the localities will
> be displayed as bus stops :-). I will try to import an excerpt of  
> place
> names from OSM tomorrow so that we can compare both data sets.
>
> From what I have seen so far an import should not be too difficult.  
> The
> only difficulties I expect are the hierarchies and the classification
> of the localities.
>
> Does anyone know the current way to tag hierarchies of places? I had a
> look at the wiki and there seem to be two approaches: is_in and
> relations. With the addition of actual borders there is also the
> possibility of defining hierarchies purely geometrical.
>
> The location classifications in the NPTG seem to be relatively coarse.
> Everything below a parish is either a "New Entry" (Add) or a Locality.
> We need to see how this can be mapped to POI types in OSM.

SourceLocalityType is, I think, information about where the data came  
from in the first place into NPTG and is not relevant for our  
purposes, and certainly into the classification field.

The LocalityClassification field should be more useful and should  
contain city, town, village, hamlet, suburb, urbancentre, place of  
interest, other, or unrecorded. I am not sure how well this field is  
populated - possibly it is not well populated at all. UrbanCentre can  
possibly be ignored.  The field may be well populated in some parts of  
the country and not in other. I am not sure how much NPTG is used for  
Points of Interest. There is a POI model in NPTG but possibly we treat  
this separately or not at all or import the data as invisible to start  
with. My main interest is the locality names and the main technical  
job will probably be to spot duplicates with what is in OSM already.

See page 69 in the NaPTAN and NPTG scheme guide for more details of  
the formatting.
http://www.naptan.org.uk/documentation.htm

>
>> Do you need help with the NaPTAN import or are you just about ready
>> to do the work? Do we need to set up a wiki page where people can
>> request imports for their authority or are we going to do it without
>> that?
>

It would be really really good to get NaPTAN in and in soon. There are  
people keen to get on with sorting the data out in their areas who are  
sitting on their hands at present, the professional transport  
community is watching what is happening closely, and there are also  
possibly other datasets from UK authorities that could come our way  
when we have completed this one.

> I am happy to continue working on the NPTG import if Thomas does not
> mind.

My vote is to get on with it - the NPTG and NaPTAN imports are  
different enough that they can be handled separately. If Thomas  
focuses on the NaPTAN import (or hands it over to someone) and you do  
the NPTG then I think we will get there faster.

Would it be worth creating a NPTG Import wiki page and an NPTG Import  
user to do the actual import - ie, keep the documentation and audit  
trail for the two imports separate?


Regards,



Peter


>
>   Christoph


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Christoph Böhme]

Hi

Peter Miller  schrieb:
> I am also aware that there is a 50K place gazetteer sitting there  
> untouched - last week I was adding villages in Norfolk by hand and
> the data is sitting available in NPTG.

I taught myself XSLT at the weekend and played a bit with the NPTG
data. On http://www.mappa-mercia.org/nptg/ you can find some html-pages
which show the hierarchies of and adjacencies between the localities in
the NTPG data. 

I also created a copy of the NOVAM viewer and changed it to display
NTPG data instead of bus stops:

http://www.mappa-mercia.org/cgi-bin/nptg.wsgi/viewer.html

I have not changed any of the texts/images yet, so the localities will
be displayed as bus stops :-). I will try to import an excerpt of place
names from OSM tomorrow so that we can compare both data sets.

>From what I have seen so far an import should not be too difficult. The
only difficulties I expect are the hierarchies and the classification
of the localities.
 
Does anyone know the current way to tag hierarchies of places? I had a
look at the wiki and there seem to be two approaches: is_in and
relations. With the addition of actual borders there is also the
possibility of defining hierarchies purely geometrical.

The location classifications in the NPTG seem to be relatively coarse.
Everything below a parish is either a "New Entry" (Add) or a Locality.
We need to see how this can be mapped to POI types in OSM.

> Do you need help with the NaPTAN import or are you just about ready
> to do the work? Do we need to set up a wiki page where people can
> request imports for their authority or are we going to do it without
> that?

I am happy to continue working on the NPTG import if Thomas does not
mind.

Christoph

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/22 Thomas Wood :
> 2009/7/22 Peter Miller :
>>
>> On 20 Jul 2009, at 14:35, Thomas Wood wrote:
>>
>>> 2009/7/20 Peter J Stoner :

 In message on 20 Jul 2009,  Ed Loach wrote:

> I'm assuming that the naptan import when it happens will be as at a
> certain point in time, and won't include any new bus stops since that
> time?

> I'm asking because a bus route has changed in the last week or so that
> now passes my house both ways instead of just one way and rather than
> add bus stops on the other side of the road they've added a taped
> message "Buses stop here and opposite" to each of the existing bus
> stops on the road.

>

 Ed


 If the Transport authority has done its job properly then we will
 expect to see Custom and Practice stops appear in NaPTAN opposite the
>>
>> snip
>>


>>>
>>> The refreshed data is yet to be downloaded, so depending on the
>>> responsiveness of the LA, the stops may be in there by the time I get
>>> around to finalising the import.
>>
>>
>> I am conscious that it is now over 6 months since the data was offered. I do
>> realise that a lot of technical work and familiarisation has been taking
>> place but it would be great to be able to complete the import and move on.
>>
>> I am also aware that there is a 50K place gazetteer sitting there untouched
>> - last week I was adding villages in Norfolk by hand and the data is sitting
>> available in NPTG.
>
> It is, we need to start thinking about what we can do with it.
>
>> Do you need help with the NaPTAN import or are you just about ready to do
>> the work? Do we need to set up a wiki page where people can request imports
>> for their authority or are we going to do it without that?
>>
>
> I've been putting off working on it for a while as slightly more
> interesting projects seem to keep coming my way.
> Anyway, I'm now checking that the new tools that will be used to
> upload the data that have been written for 0.6 will meet our needs.
> For this I'm doing a few uploads to a dev server to see what the
> imported data looks like with regards the created changesets etc.
> I'm probably going to have to modify the uploader to record object ids
> that are being stored for missing references to stop areas.

I have just done a fairly thorough review of both the 0.6 API bulk
upload scripts. Neither works fully as expected.
I have three options, fix the python one, finish the php one, or port
the 0.5 perl one...

The first option is currently looking most tempting.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/22 Peter Miller :
>
> On 20 Jul 2009, at 14:35, Thomas Wood wrote:
>
>> 2009/7/20 Peter J Stoner :
>>>
>>> In message on 20 Jul 2009,  Ed Loach wrote:
>>>
 I'm assuming that the naptan import when it happens will be as at a
 certain point in time, and won't include any new bus stops since that
 time?
>>>
 I'm asking because a bus route has changed in the last week or so that
 now passes my house both ways instead of just one way and rather than
 add bus stops on the other side of the road they've added a taped
 message "Buses stop here and opposite" to each of the existing bus
 stops on the road.
>>>

>>>
>>> Ed
>>>
>>>
>>> If the Transport authority has done its job properly then we will
>>> expect to see Custom and Practice stops appear in NaPTAN opposite the
>
> snip
>
>>>
>>>
>>
>> The refreshed data is yet to be downloaded, so depending on the
>> responsiveness of the LA, the stops may be in there by the time I get
>> around to finalising the import.
>
>
> I am conscious that it is now over 6 months since the data was offered. I do
> realise that a lot of technical work and familiarisation has been taking
> place but it would be great to be able to complete the import and move on.
>
> I am also aware that there is a 50K place gazetteer sitting there untouched
> - last week I was adding villages in Norfolk by hand and the data is sitting
> available in NPTG.

It is, we need to start thinking about what we can do with it.

> Do you need help with the NaPTAN import or are you just about ready to do
> the work? Do we need to set up a wiki page where people can request imports
> for their authority or are we going to do it without that?
>

I've been putting off working on it for a while as slightly more
interesting projects seem to keep coming my way.
Anyway, I'm now checking that the new tools that will be used to
upload the data that have been written for 0.6 will meet our needs.
For this I'm doing a few uploads to a dev server to see what the
imported data looks like with regards the created changesets etc.
I'm probably going to have to modify the uploader to record object ids
that are being stored for missing references to stop areas.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Peter Miller]

On 20 Jul 2009, at 14:35, Thomas Wood wrote:

> 2009/7/20 Peter J Stoner :
>> In message on 20 Jul 2009,  Ed Loach wrote:
>>
>>> I'm assuming that the naptan import when it happens will be as at a
>>> certain point in time, and won't include any new bus stops since  
>>> that
>>> time?
>>
>>> I'm asking because a bus route has changed in the last week or so  
>>> that
>>> now passes my house both ways instead of just one way and rather  
>>> than
>>> add bus stops on the other side of the road they've added a taped
>>> message "Buses stop here and opposite" to each of the existing bus
>>> stops on the road.
>>
>>>
>>
>> Ed
>>
>>
>> If the Transport authority has done its job properly then we will
>> expect to see Custom and Practice stops appear in NaPTAN opposite the

snip

>>
>>
>
> The refreshed data is yet to be downloaded, so depending on the
> responsiveness of the LA, the stops may be in there by the time I get
> around to finalising the import.


I am conscious that it is now over 6 months since the data was  
offered. I do realise that a lot of technical work and familiarisation  
has been taking place but it would be great to be able to complete the  
import and move on.

I am also aware that there is a 50K place gazetteer sitting there  
untouched - last week I was adding villages in Norfolk by hand and the  
data is sitting available in NPTG.

Do you need help with the NaPTAN import or are you just about ready to  
do the work? Do we need to set up a wiki page where people can request  
imports for their authority or are we going to do it without that?




Regards,



Peter



>
> -- 
> Regards,
> Thomas Wood
> (Edgemaster)
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Thomas Wood]

2009/7/20 Peter J Stoner :
> In message on 20 Jul 2009,  Ed Loach wrote:
>
>> I'm assuming that the naptan import when it happens will be as at a
>> certain point in time, and won't include any new bus stops since that
>> time?
>
>> I'm asking because a bus route has changed in the last week or so that
>> now passes my house both ways instead of just one way and rather than
>> add bus stops on the other side of the road they've added a taped
>> message "Buses stop here and opposite" to each of the existing bus
>> stops on the road.
>
>>
>
> Ed
>
>
> If the Transport authority has done its job properly then we will
> expect to see Custom and Practice stops appear in NaPTAN opposite the
> marked stops.
>
> It may be that the stick on labels are temporary and that bus stop
> poles will appear on the other side of the road in due course, at
> which point the status of the stop in NaPTAN should change from CUS to
>
> MKD.
>
> Neither Traveline nor DfT have given an undertaking to provide updates
>
> of the data.  However I believe OSM has been able to take a refresh
> recently.
>
> Best wishes
>
>
>
> --
> Peter J Stoner
> UK Regional Coordinator         www.travelinedata.org.uk
> Traveline
>
> a trading name of
> Intelligent Travel Solutions Ltd  company number 3826797
> Drury House, 34-43 Russell Street, LONDON WC2B 5HA
> - follow us on Twitter at @traveline and @nextbuses
>

The refreshed data is yet to be downloaded, so depending on the
responsiveness of the LA, the stops may be in there by the time I get
around to finalising the import.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import

[Peter J Stoner]

In message on 20 Jul 2009,  Ed Loach wrote:

> I'm assuming that the naptan import when it happens will be as at a
> certain point in time, and won't include any new bus stops since that
> time?

> I'm asking because a bus route has changed in the last week or so that
> now passes my house both ways instead of just one way and rather than
> add bus stops on the other side of the road they've added a taped
> message "Buses stop here and opposite" to each of the existing bus
> stops on the road.

> 

Ed


If the Transport authority has done its job properly then we will
expect to see Custom and Practice stops appear in NaPTAN opposite the
marked stops.

It may be that the stick on labels are temporary and that bus stop
poles will appear on the other side of the road in due course, at
which point the status of the stop in NaPTAN should change from CUS to 

MKD.

Neither Traveline nor DfT have given an undertaking to provide updates 

of the data.  However I believe OSM has been able to take a refresh
recently.

Best wishes



-- 
Peter J Stoner
UK Regional Coordinator www.travelinedata.org.uk
Traveline

a trading name of
Intelligent Travel Solutions Ltd  company number 3826797
Drury House, 34-43 Russell Street, LONDON WC2B 5HA
- follow us on Twitter at @traveline and @nextbuses


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

2009/4/3 Thomas Wood :
> 2009/4/3 Brian Prangle :
>> Hi Thomas
>>
>> From our west mids meeting last night  a number of requests and queries came
>> up
>>
>> 1.Can you import Wolverhampton - the guys up there are ready to have a crack
>
> Ok, done.

(This is complete with Bearing and CUS tagged, where appropriate)

>
>> 2. Coventry will not be far behind but hold off until we've checked with the
>> major contributors there
>> 3. We'd like to see the NaPTAN fields LocalityName and Bearing imported
>
> This is an NPTG field, none of the NPTG stuff has been looked at yet.
>
>> 4. We're not sure if stoptypes CUS, TXR STR BCQ and BCS have been imported
>
> CUS are in, but not tagged in data, there's no TXR or STR in the West
> Mids dataset, BCQ, BCS are in, but not tagged as such since they're
> essentially the same as BCT for our purposes.


I've just done a (very crude, clashing) re-import of the West Bromwich
data to include CUS and the Bearings. Andy assured me that only his
edits were there, and that he didn't mind them getting overwritten.

I'm planning an addition of Bearing and CUS data for the rest of
Birmingham, I'll give more details once the software for it is
written.

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

2009/4/3 Brian Prangle :
> Hi Thomas
>
> From our west mids meeting last night  a number of requests and queries came
> up
>
> 1.Can you import Wolverhampton - the guys up there are ready to have a crack

Ok, done.

> 2. Coventry will not be far behind but hold off until we've checked with the
> major contributors there
> 3. We'd like to see the NaPTAN fields LocalityName and Bearing imported

This is an NPTG field, none of the NPTG stuff has been looked at yet.

> 4. We're not sure if stoptypes CUS, TXR STR BCQ and BCS have been imported

CUS are in, but not tagged in data, there's no TXR or STR in the West
Mids dataset, BCQ, BCS are in, but not tagged as such since they're
essentially the same as BCT for our purposes.

> 5. We're not sure if your local_ref field is working correctly
> -essentially  it's just repeating the naptan:Indicator field

It's a filtered version of the Indicator field, where a reference can
be pulled from it intelligibly.

> I'll be writing a short set of guidelines and also a summary of what we've
> found for the import wiki page - to be published shortly
>
> As a group we've decided to rely on our gps surveys of where bus stops are
> and move the NaPTAN data to that location for merger with our data. The
> feeling is that earlier bus stop surveys need to be repeated much more
> precisely - examining some of our earlier data suggest we weren't as
> accurate as we needed to be.
>
> Christophe seems to be making good progress with the visual verify/merge
> tool.
>
> Peter - we're very keen to get our hands on aerial imagery - what needs to
> happen to get this under way?
>
> Regards
>
> Brian
>



-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import starts - Birmingham trial area first

[Peter J Stoner]

In message <49d135f1.9010...@00l.de>
  Gerrit Lammert  wrote:

> Hi.

> I'm exited to see how this works out.
> Beeing curious, I just zoomed in into Birmingham and noticed two things:
> 1) Imported stops seem to be close to the already mapped ones but off by
> some meters
> 2) Some Streets seem to consist entirely of bus_stops.
> (http://www.openstreetmap.org/?lat=52.479838&lon=-1.896227&zoom=18&lay
> ers=B000FTF)
> Is this real??

Yes it is

-- 
Peter J Stoner
UK Regional Coordinator
Traveline   www.travelinedata.org.uk

a trading name of
Intelligent Travel Solutions Ltd  company number 3826797
Drury House, 34-43 Russell Street, LONDON WC2B 5HA


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import starts - Birmingham trial area first

[Gerrit Lammert]

Hi.

I'm exited to see how this works out.
Beeing curious, I just zoomed in into Birmingham and noticed two things:
1) Imported stops seem to be close to the already mapped ones but off by
some meters
2) Some Streets seem to consist entirely of bus_stops.
(http://www.openstreetmap.org/?lat=52.479838&lon=-1.896227&zoom=18&layers=B000FTF)
Is this real??

Gerrit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

2009/3/19 Thomas Wood :
>  - Run a conversion and filter on the West Midlands data set for just
> items in Birmingham.

I've now written the filtering code for the converter script, I think
all that's left to be done is to test the file upload against a test
OSM api, to check that the bulk_upload script is suitable for the
purpose.

Then we should continue with the first few steps as outlined previously.
I'm looking to target it to just before or after the weekend.

(By the way, there seem to be 4338 stops in Birmingham in the dataset
I'm playing with, does this sound reasonable?)

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

I'll also add that there's a googlemail account for use as a
forwarding box that's associated with the NaPTAN OSMaccount and also
the journeyweb NaPTAN data download user account (username:
OpenStreetMap). I won't post the address here for spam reasons.
The secondary password holder will recieve all these account details.


2009/3/19 Thomas Wood :
> 2009/3/19 Peter Miller :
>>
>> On 19 Mar 2009, at 17:18, Thomas Wood wrote:
>>
>>> Yes, this is the first message since the confirmation we can use the data.
>>>
>>> I did a little more tweaking to the StopArea code at the weekend (not
>>> that it matters for the WestMids data).
>>>
>>> I propose we now do the following:
>>> - Download the whole NaPTAN dataset, so to simplify the update
>>> process in the future (it'll be easier to merge a complete data set
>>> with a single noted timestamp)
>>> - Run a conversion and filter on the West Midlands data set for just
>>> items in Birmingham.
>>> - Show the list 5 or so example stops to show how they've been
>>> converted, so we can fix any issues before an import. (And possibly
>>> produce a slimmed down slippymap showing the density of data we're
>>> importing). If a consensus is reached, we'll run an import under the
>>> NaPTAN account. (http://www.openstreetmap.org/user/NaPTAN, which I
>>> currently have control of).
>>> - Allow Birmingham mappers to trawl the data and work on a set of
>>> guidelines of how to bring the data more in-line with OSM, where
>>> required.
>>> - Open the import to other talk-gb regions.
>>>
>>> I also propose that the official datasets are kept (privately),
>>> converted, and uploaded on/from the OSM dev machine rather than one of
>>> our personal ones.
>>
>> All sounds good to me.
>>
>> When you create the NaPTAN Import user do give that user a description
>> saying what it is being used for and also give a link to the 'controllers'
>> of that user, ie yourself and I would suggest we have at least one other
>> person who knows the password of the NaPTAN Import user.
>
> The account has been in existence for the past few weeks, as yet
> unused. Who wants to be the second password holder?
>
> --
> Regards,
> Thomas Wood
> (Edgemaster)
>



-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

2009/3/19 Peter Miller :
>
> On 19 Mar 2009, at 17:18, Thomas Wood wrote:
>
>> Yes, this is the first message since the confirmation we can use the data.
>>
>> I did a little more tweaking to the StopArea code at the weekend (not
>> that it matters for the WestMids data).
>>
>> I propose we now do the following:
>> - Download the whole NaPTAN dataset, so to simplify the update
>> process in the future (it'll be easier to merge a complete data set
>> with a single noted timestamp)
>> - Run a conversion and filter on the West Midlands data set for just
>> items in Birmingham.
>> - Show the list 5 or so example stops to show how they've been
>> converted, so we can fix any issues before an import. (And possibly
>> produce a slimmed down slippymap showing the density of data we're
>> importing). If a consensus is reached, we'll run an import under the
>> NaPTAN account. (http://www.openstreetmap.org/user/NaPTAN, which I
>> currently have control of).
>> - Allow Birmingham mappers to trawl the data and work on a set of
>> guidelines of how to bring the data more in-line with OSM, where
>> required.
>> - Open the import to other talk-gb regions.
>>
>> I also propose that the official datasets are kept (privately),
>> converted, and uploaded on/from the OSM dev machine rather than one of
>> our personal ones.
>
> All sounds good to me.
>
> When you create the NaPTAN Import user do give that user a description
> saying what it is being used for and also give a link to the 'controllers'
> of that user, ie yourself and I would suggest we have at least one other
> person who knows the password of the NaPTAN Import user.

The account has been in existence for the past few weeks, as yet
unused. Who wants to be the second password holder?

-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Peter Miller]

On 19 Mar 2009, at 17:18, Thomas Wood wrote:

> Yes, this is the first message since the confirmation we can use the  
> data.
>
> I did a little more tweaking to the StopArea code at the weekend (not
> that it matters for the WestMids data).
>
> I propose we now do the following:
> - Download the whole NaPTAN dataset, so to simplify the update
> process in the future (it'll be easier to merge a complete data set
> with a single noted timestamp)
> - Run a conversion and filter on the West Midlands data set for just
> items in Birmingham.
> - Show the list 5 or so example stops to show how they've been
> converted, so we can fix any issues before an import. (And possibly
> produce a slimmed down slippymap showing the density of data we're
> importing). If a consensus is reached, we'll run an import under the
> NaPTAN account. (http://www.openstreetmap.org/user/NaPTAN, which I
> currently have control of).
> - Allow Birmingham mappers to trawl the data and work on a set of
> guidelines of how to bring the data more in-line with OSM, where
> required.
> - Open the import to other talk-gb regions.
>
> I also propose that the official datasets are kept (privately),
> converted, and uploaded on/from the OSM dev machine rather than one of
> our personal ones.

All sounds good to me.

When you create the NaPTAN Import user do give that user a description  
saying what it is being used for and also give a link to the  
'controllers' of that user, ie yourself and I would suggest we have at  
least one other person who knows the password of the NaPTAN Import user.



Regards,


Peter


>
>
> 2009/3/18 Christoph Böhme :
>> Hi all
>>
>> has there been any progress with the NaPTAN import yet? The list has
>> been very quiet recently.
>> I started programming the visual merge tool but I have not yet  
>> reached
>> a point where there is something to show. I decided not to modify the
>> busstop data in the osm database directly but to keep a seperate copy
>> of the relevant nodes that can be merged into the database at some
>> point when we tidied it up (basically like the dracos tool does it).
>>
>> Just wanted to let you know that I have not given up on the  
>> import ...
>>
>> Christoph
>>
>> Brian Prangle  schrieb:
>>
>>> Hi everyone
>>>
>>> Summarising where I believe we've got to:
>>>
>>> 1. Thomas: schedule for completion - we're entirely in your hands -
>>> agree it's best to avoid the API update.
>>> 2. Birmingham only for test import
>>> 3. No highway=bus_stop tags, enabling us to merge/verify existing  
>>> OSM
>>> data ( Christophe's visual tool to eventually solve this manual  
>>> task)
>>> BUT tag taxi ranks as amenity=taxi
>>> 4. Import on the basis of the current selection/naming in naptan
>>> tagging wiki. Imports to be carried out by new user naptan
>>> 5. Plusbus zones and stop areas - import the naptan data only and
>>> leave doing anything with it until the debate on stopareas reaches a
>>> conclusion
>>> 6. Roger/Peter:  is our current method of accessing the data OK? Or
>>> do you have to explicitly issue us with a dataset (perhaps the data
>>> publicly available for test is not the most current/accurate?)
>>> 7. Andy: agree on re-tagging w mids bus stops with route_ref and  
>>> using
>>> semicolons instead of pipes to separate route nos in order to
>>> standardise - presume you have an automated routine for this?
>>> 8. Update needed on wiki regarding bus_stops (Andy? I'm happy to  
>>> do a
>>> first draft for you to edit before publication - or better still
>>> submit it to this discussion list)
>>>
>>> Parked for later discussion/solution
>>>
>>> a)Stopareas (see above)
>>> b)Big-bang vs regional adoption (probably a talk gb discussion once
>>> Birmingham data and process completed)
>>> c)handling NaPTAN bus_stop updates
>>> d) importing further NaPTAN public transport data
>>> e) user feedback - there's a wide range of skill and experience in
>>> the OSM community and there are certain to be problems. An explicit
>>> route needed? f) how to maintain data integrity once it's imported
>>> and inexperienced users potentially delete data that other users  
>>> have
>>> written applications that rely on it being there. I guess this is
>>> general problem not specific to this project- but this is a donated
>>> dataset and potentially could drive a considerable number of
>>> applications
>>>
>>> Unless there are any strong objections,(or I've ommitted anything
>>> from the discussions) I'd like to think we can close the discussion
>>> on the import and let Thomas get on with finishing the coding. Thank
>>> you everyone for your time and contributions
>>>
>>> We can continue discussion on the parked items and anything else  
>>> that
>>> doesn't impact the coding for the first live Birmingham import
>>>
>>> Regards
>>>
>>> Brian
>>>
>>
>> ___
>> Talk-transit mailing list
>> Talk-transit@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-tr

Re: [Talk-transit] NaPTAN import

[Thomas Wood]

Yes, this is the first message since the confirmation we can use the data.

I did a little more tweaking to the StopArea code at the weekend (not
that it matters for the WestMids data).

I propose we now do the following:
 - Download the whole NaPTAN dataset, so to simplify the update
process in the future (it'll be easier to merge a complete data set
with a single noted timestamp)
 - Run a conversion and filter on the West Midlands data set for just
items in Birmingham.
 - Show the list 5 or so example stops to show how they've been
converted, so we can fix any issues before an import. (And possibly
produce a slimmed down slippymap showing the density of data we're
importing). If a consensus is reached, we'll run an import under the
NaPTAN account. (http://www.openstreetmap.org/user/NaPTAN, which I
currently have control of).
 - Allow Birmingham mappers to trawl the data and work on a set of
guidelines of how to bring the data more in-line with OSM, where
required.
 - Open the import to other talk-gb regions.

I also propose that the official datasets are kept (privately),
converted, and uploaded on/from the OSM dev machine rather than one of
our personal ones.

2009/3/18 Christoph Böhme :
> Hi all
>
> has there been any progress with the NaPTAN import yet? The list has
> been very quiet recently.
> I started programming the visual merge tool but I have not yet reached
> a point where there is something to show. I decided not to modify the
> busstop data in the osm database directly but to keep a seperate copy
> of the relevant nodes that can be merged into the database at some
> point when we tidied it up (basically like the dracos tool does it).
>
> Just wanted to let you know that I have not given up on the import ...
>
> Christoph
>
> Brian Prangle  schrieb:
>
>> Hi everyone
>>
>> Summarising where I believe we've got to:
>>
>> 1. Thomas: schedule for completion - we're entirely in your hands -
>> agree it's best to avoid the API update.
>> 2. Birmingham only for test import
>> 3. No highway=bus_stop tags, enabling us to merge/verify existing OSM
>> data ( Christophe's visual tool to eventually solve this manual task)
>> BUT tag taxi ranks as amenity=taxi
>> 4. Import on the basis of the current selection/naming in naptan
>> tagging wiki. Imports to be carried out by new user naptan
>> 5. Plusbus zones and stop areas - import the naptan data only and
>> leave doing anything with it until the debate on stopareas reaches a
>> conclusion
>> 6. Roger/Peter:  is our current method of accessing the data OK? Or
>> do you have to explicitly issue us with a dataset (perhaps the data
>> publicly available for test is not the most current/accurate?)
>> 7. Andy: agree on re-tagging w mids bus stops with route_ref and using
>> semicolons instead of pipes to separate route nos in order to
>> standardise - presume you have an automated routine for this?
>> 8. Update needed on wiki regarding bus_stops (Andy? I'm happy to do a
>> first draft for you to edit before publication - or better still
>> submit it to this discussion list)
>>
>> Parked for later discussion/solution
>>
>> a)Stopareas (see above)
>> b)Big-bang vs regional adoption (probably a talk gb discussion once
>> Birmingham data and process completed)
>> c)handling NaPTAN bus_stop updates
>> d) importing further NaPTAN public transport data
>> e) user feedback - there's a wide range of skill and experience in
>> the OSM community and there are certain to be problems. An explicit
>> route needed? f) how to maintain data integrity once it's imported
>> and inexperienced users potentially delete data that other users have
>> written applications that rely on it being there. I guess this is
>> general problem not specific to this project- but this is a donated
>> dataset and potentially could drive a considerable number of
>> applications
>>
>> Unless there are any strong objections,(or I've ommitted anything
>> from the discussions) I'd like to think we can close the discussion
>> on the import and let Thomas get on with finishing the coding. Thank
>> you everyone for your time and contributions
>>
>> We can continue discussion on the parked items and anything else that
>> doesn't impact the coding for the first live Birmingham import
>>
>> Regards
>>
>> Brian
>>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
>



-- 
Regards,
Thomas Wood
(Edgemaster)

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Christoph Böhme]

Hi all

has there been any progress with the NaPTAN import yet? The list has
been very quiet recently.
I started programming the visual merge tool but I have not yet reached
a point where there is something to show. I decided not to modify the
busstop data in the osm database directly but to keep a seperate copy
of the relevant nodes that can be merged into the database at some
point when we tidied it up (basically like the dracos tool does it).

Just wanted to let you know that I have not given up on the import ...

Christoph

Brian Prangle  schrieb:

> Hi everyone
> 
> Summarising where I believe we've got to:
> 
> 1. Thomas: schedule for completion - we're entirely in your hands -
> agree it's best to avoid the API update.
> 2. Birmingham only for test import
> 3. No highway=bus_stop tags, enabling us to merge/verify existing OSM
> data ( Christophe's visual tool to eventually solve this manual task)
> BUT tag taxi ranks as amenity=taxi
> 4. Import on the basis of the current selection/naming in naptan
> tagging wiki. Imports to be carried out by new user naptan
> 5. Plusbus zones and stop areas - import the naptan data only and
> leave doing anything with it until the debate on stopareas reaches a
> conclusion
> 6. Roger/Peter:  is our current method of accessing the data OK? Or
> do you have to explicitly issue us with a dataset (perhaps the data
> publicly available for test is not the most current/accurate?)
> 7. Andy: agree on re-tagging w mids bus stops with route_ref and using
> semicolons instead of pipes to separate route nos in order to
> standardise - presume you have an automated routine for this?
> 8. Update needed on wiki regarding bus_stops (Andy? I'm happy to do a
> first draft for you to edit before publication - or better still
> submit it to this discussion list)
> 
> Parked for later discussion/solution
> 
> a)Stopareas (see above)
> b)Big-bang vs regional adoption (probably a talk gb discussion once
> Birmingham data and process completed)
> c)handling NaPTAN bus_stop updates
> d) importing further NaPTAN public transport data
> e) user feedback - there's a wide range of skill and experience in
> the OSM community and there are certain to be problems. An explicit
> route needed? f) how to maintain data integrity once it's imported
> and inexperienced users potentially delete data that other users have
> written applications that rely on it being there. I guess this is
> general problem not specific to this project- but this is a donated
> dataset and potentially could drive a considerable number of
> applications
> 
> Unless there are any strong objections,(or I've ommitted anything
> from the discussions) I'd like to think we can close the discussion
> on the import and let Thomas get on with finishing the coding. Thank
> you everyone for your time and contributions
> 
> We can continue discussion on the parked items and anything else that
> doesn't impact the coding for the first live Birmingham import
> 
> Regards
> 
> Brian
> 

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Peter Miller]

On 9 Mar 2009, at 21:07, Roger Slevin wrote:


Brian and all

I am happy to arrange for an updated NaPTAN file to be used for the  
proposed test import.  I think Peter Miller may have made the  
current test data available (with my agreement) – and I am happy if  
Peter supplies the updated files as and when you are ready to use  
them.


NaPTAN data is continually changing (albeit slowly) so it is worth  
taking the most up to date data once you are ready.


Excellent news!

With regard to actually getting the data, are you able to download it  
from the Thales site? If you are then please do that. For the  
avoidance of doubt can you provide me with the URL you will be using  
to access the data to ensure that it is current.



Regards,


Peter





Best wishes

RogerS

From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org 
]On Behalf Of Brian Prangle

Sent: 09 March 2009 10:00
To: talk-transit@openstreetmap.org
Subject: [Talk-transit] NaPTAN import

Hi everyone

Summarising where I believe we've got to:

1. Thomas: schedule for completion - we're entirely in your hands -  
agree it's best to avoid the API update.

2. Birmingham only for test import
3. No highway=bus_stop tags, enabling us to merge/verify existing  
OSM data ( Christophe's visual tool to eventually solve this manual  
task) BUT tag taxi ranks as amenity=taxi
4. Import on the basis of the current selection/naming in naptan  
tagging wiki. Imports to be carried out by new user naptan
5. Plusbus zones and stop areas - import the naptan data only and  
leave doing anything with it until the debate on stopareas reaches a  
conclusion
6. Roger/Peter:  is our current method of accessing the data OK? Or  
do you have to explicitly issue us with a dataset (perhaps the data  
publicly available for test is not the most current/accurate?)
7. Andy: agree on re-tagging w mids bus stops with route_ref and  
using semicolons instead of pipes to separate route nos in order to  
standardise - presume you have an automated routine for this?
8. Update needed on wiki regarding bus_stops (Andy? I'm happy to do  
a first draft for you to edit before publication - or better still  
submit it to this discussion list)


Parked for later discussion/solution

a)Stopareas (see above)
b)Big-bang vs regional adoption (probably a talk gb discussion once  
Birmingham data and process completed)

c)handling NaPTAN bus_stop updates
d) importing further NaPTAN public transport data
e) user feedback - there's a wide range of skill and experience in  
the OSM community and there are certain to be problems. An explicit  
route needed?
f) how to maintain data integrity once it's imported and  
inexperienced users potentially delete data that other users have  
written applications that rely on it being there. I guess this is  
general problem not specific to this project- but this is a donated  
dataset and potentially could drive a considerable number of  
applications


Unless there are any strong objections,(or I've ommitted anything  
from the discussions) I'd like to think we can close the discussion  
on the import and let Thomas get on with finishing the coding. Thank  
you everyone for your time and contributions


We can continue discussion on the parked items and anything else  
that doesn't impact the coding for the first live Birmingham import


Regards

Brian
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] NaPTAN import

[Roger Slevin]

Brian and all

 

I am happy to arrange for an updated NaPTAN file to be used for the proposed
test import.  I think Peter Miller may have made the current test data
available (with my agreement) - and I am happy if Peter supplies the updated
files as and when you are ready to use them.

 

NaPTAN data is continually changing (albeit slowly) so it is worth taking
the most up to date data once you are ready.

 

Best wishes

 

RogerS 

  _  

From: talk-transit-boun...@openstreetmap.org
[mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Brian Prangle
Sent: 09 March 2009 10:00
To: talk-transit@openstreetmap.org
Subject: [Talk-transit] NaPTAN import

 

Hi everyone

Summarising where I believe we've got to:

1. Thomas: schedule for completion - we're entirely in your hands - agree
it's best to avoid the API update.
2. Birmingham only for test import
3. No highway=bus_stop tags, enabling us to merge/verify existing OSM data (
Christophe's visual tool to eventually solve this manual task) BUT tag taxi
ranks as amenity=taxi
4. Import on the basis of the current selection/naming in naptan tagging
wiki. Imports to be carried out by new user naptan
5. Plusbus zones and stop areas - import the naptan data only and leave
doing anything with it until the debate on stopareas reaches a conclusion
6. Roger/Peter:  is our current method of accessing the data OK? Or do you
have to explicitly issue us with a dataset (perhaps the data publicly
available for test is not the most current/accurate?)
7. Andy: agree on re-tagging w mids bus stops with route_ref and using
semicolons instead of pipes to separate route nos in order to standardise -
presume you have an automated routine for this?
8. Update needed on wiki regarding bus_stops (Andy? I'm happy to do a first
draft for you to edit before publication - or better still submit it to this
discussion list)

Parked for later discussion/solution

a)Stopareas (see above)
b)Big-bang vs regional adoption (probably a talk gb discussion once
Birmingham data and process completed)
c)handling NaPTAN bus_stop updates
d) importing further NaPTAN public transport data
e) user feedback - there's a wide range of skill and experience in the OSM
community and there are certain to be problems. An explicit route needed?
f) how to maintain data integrity once it's imported and inexperienced users
potentially delete data that other users have written applications that rely
on it being there. I guess this is general problem not specific to this
project- but this is a donated dataset and potentially could drive a
considerable number of applications

Unless there are any strong objections,(or I've ommitted anything from the
discussions) I'd like to think we can close the discussion on the import and
let Thomas get on with finishing the coding. Thank you everyone for your
time and contributions

We can continue discussion on the parked items and anything else that
doesn't impact the coding for the first live Birmingham import

Regards

Brian

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit