I think most of these issues stem from a few fields that were
inadvertantly missed from the Birmingham area import. They were later
corrected on the other regions within the West Midlands, but I witheld
from doing a blanket fix since some of the Birmingham data had already
been corrected by the time I realised.
It was planned to merge in the missing tags at a later point through
an automated change comparison process with the source data.
My focus will be once again on the NaPTAN import in about a month.

On 26/05/2009, Peter Miller <[email protected]> wrote:
>
> On 26 May 2009, at 18:09, Roger Slevin wrote:
>
>> Brian
>>
>> I would be very interested to have the evidence about the transposed
>> stops if that is possible.  Thanks.
>>
>> Do you not have access to “bearing” – it’s in the source data, but I
>> am not sure what you have access to.  I can certainly let you have a
>> file with the bearing data in it, if you do not have access to this
>> from anywhere else.
>
> I think the bearing must be one of the fields that has been 'culled'
> during the import; personally I would consider it essential
> information for the next import/update  pass. Without that information
> will be hard to know if the name/identifier or bearing should be
> changed. It is actually necessary to have access to the schedules
> themselves to know how the stops are being used.
>>
>> CUS is a fact of life – nothing I can offer in response to that.
>
> The Stop-Type field would indicate what sort of stop it is (CUS for
> customary) if it had been imported. Without this information it is
> hard to review the NaPTAN data well and provide hard-hitting feedback
> on the data.
>
> I know that as the number of tags for a node increasing that it
> becomes difficult for Potlatch to manage, but I think that we are
> going to solve that one to get the most out of this data-set. Possibly
> someone needs to talk to Richard.
>
> You can of course also check data you are not sure about using the ITO
> NaPTAN service that we gave a few people in the area access to for
> evaluation purposes during the initial import. That will reflect the
> current data rather than the data at the time of the import and will
> include all the tags including the ones that have not been imported
> into OSM this time.
>
>
>
> Regards,
>
>
>
> Peter
>
>
>>
>> If stops have been removed – but not removed or replaced in NaPTAN –
>> then I would again like evidence to take back to colleagues who
>> maintain NaPTAN.   It is possible that they have changed the stop
>> sub-type from MKD to HAR – that is the preferred method of handling
>> this situation in NaPTAN.   A formal HAR record has an entry point,
>> what I call an “anchor” point in the middle, and an exit point.  The
>> guidance tells editors that these should all fall on the same named
>> road (but in practice we know that a lot of them do not adhere to
>> this rule).  What is almost certainly the case in almost every case
>> is that the length of the HAR section is not the same as the full
>> length of the road ... most well-created HAR records would have
>> entry and exit points which are at least a few metres short of the
>> road junctions at each end.
>>
>> Best wishes
>>
>> Roger
>>
>> From: [email protected]
>> [mailto:[email protected]
>> ] On Behalf Of Brian Prangle
>> Sent: 26 May 2009 17:19
>> To: [email protected]
>> Subject: [Talk-transit] NaPTAN data import in Birmingham update
>>
>> Having surveyed (and resurveyed) about three hundred bus stops I
>> think I could draft (soon)  a definitive report on how to proceed.
>>
>> There's also a few points to emerge about the Birmingham data
>>
>> 1. I'm coming across regular transpositon of stops from opposite
>> sides of the road ( would be useful to have bearing data)
>> 2. Not having the CUS marker on customary stops makes for hard work
>> surveying and editing on estates where practically every other stop
>> is CUS
>> 3. Came across two routes (36 and 36C) where whole roads have had
>> their bus stops physically removed (still showing as NaPTAN data)
>> and the timetables show the roads as Hail and Ride zones. Couple of
>> things here - I presume that actual practice has gone beyond the
>> capacity of NapTAN data to keep pace ( I'll add the details to the
>> NaPTAN error log on the mappamercia wiki shortly) and how do we
>> import the HAR data - or represent it ( I can't remember  where our
>> previous discussions got to). In the meantime I'll probably just tag
>> the roads as HAR=yes and HAR_route_ref= xx.  (Without the timetable
>> there's nothing visible on the ground to indicate to surveyors that
>> they are in a HAR zone)
>>
>> Note for Thomas - I know you're into exam season - none of this is
>> desperate - there's a few thousand more bus stops to survey and
>> verify yet!
>> _______________________________________________
>> Talk-transit mailing list
>> [email protected]
>> http://lists.openstreetmap.org/listinfo/talk-transit
>
>


-- 
Regards,
Thomas Wood
(Edgemaster)

_______________________________________________
Talk-transit mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-transit

Reply via email to