[Talk-gb-westmidlands] NOVAM Viewer

[Peter Miller]

On 14 Sep 2009, at 22:55, Andy Robinson (blackadder-lists) wrote:

> Peter Miller wrote:
>> Sent: 14 September 2009 10:12 PM
>> To: Andy Robinson (blackadder-lists)
>> Cc: 'Christoph Böhme'; talk-gb-westmidlands at openstreetmap.org
>> Subject: Re: [Talk-gb-westmidlands] NOVAM Viewer
>>
>>
>> On 14 Sep 2009, at 18:02, Andy Robinson (blackadder-lists) wrote:
>>
>>> Peter Miller wrote:
>>>> Sent: 10 September 2009 3:29 PM
>>>> To: Christoph Böhme
>>>> Cc: talk-gb-westmidlands at openstreetmap.org
>>>> Subject: Re: [Talk-gb-westmidlands] NOVAM Viewer
>>>>
>>>>
>>>> On 9 Sep 2009, at 22:06, Christoph Böhme wrote:
>>>>
>>>>> Hi!

snip

>>>>>
>
>>
>> Please can you disable the requirement for the route_ref tag for the
>> benefit of the great unwashed who live in parts of the world that
>> spend less on their bus stops than dear Brum.
>
> Well, we have to be ahead of the curve sometimes ;-)
>
> One other thing worth bearing I mind. I've noted that on some  
> streets some
> stops are used by some routes but other stops are used for other  
> routes.
> This assuming that a bus stops at all stops along the same street  
> need not
> always be correct. Where it’s a terminus it's easy to see this  
> because its
> generally noted at the stop. Elsewhere its not so obvious except  
> that I
> presume the bus timetable, if displayed, would note which services  
> stop at
> the particular stop in question.

Correct. For busy corridors they need to parallel up the bus stops so  
that multiple buses can be loading at the same time and there may be  
three stops in a row with bus services allocated across them suitable  
to avoid any particular stop being overloaded.

Also... traditional paper bus timetables only show some stops on the  
route (the timing points) because the full list of stops would be too  
long and this same format of information is sometimes used within in  
the timetable case and in these cases it is not possible from the  
published information to establish the calling pattern with certainty.  
In the past the system relied in part on information passed form  
person to person and only recently has a serious attempt been made to  
capture this electronically.


Regards,



Peter

>
>>
>>>>
>>>> I am not sure that the shelter tag should be essential. I have  
>>>> added
>>>> it if there is a shelter and left it off if there is not. Could you
>>>> represent in the symbol if it is a shelter, but not use  
>>>> shelter=yes/
>>>> no
>>>> as a requirement for the stop being green
>>>
>>> Forcing the shelter to be yes of no I find a useful check for
>>> situations
>>> where I added data some time ago and need to go back and wrap up
>>> verification. But I agree, its not something that needs to be
>>> "required"
>>
>> I am comfortable to go round adding shelter=no tags - not too much
>> work and it do add information. However I won't unless the  
>> requirement
>> for the route_ref tag goes because otherwise I can't get NOVAM to  
>> help
>> me.
>>>
>>>>
>>>>
>>>>>
>>>>> A stop is considered a plain naptan stop (blue) if it has
>>>>> 	NO highway-tag
>>>>> 	AND a naptan:AtcoCode-tag
>>>>> 	AND a naptan:unverified-tag OR a naptan:verified=no.
>>>>
>>>> But our import had highway=bus_stop turned on - it would be much  
>>>> more
>>>> useful for most people to ignore that tag for this test.
>>>
>>> I guess Christoph is going to need to deal with the West mids folks
>>> who have
>>> the data imported without the bus_stop attribute and everyone else
>>> that
>>> does.
>>>
>>>>
>>>>>
>>>>> Plain OSM stops (yellow) must have
>>>>> 	a highway-tag
>>>>> 	AND NO naptan:AtcoCode.
>>>>>
>>>> Fine
>>>>
>>>>> And finally there is the concept of a physically not present stop
>>>>> (grey). This is a bit unfinished as we have not really decided
>>>>> what to
>>>>> do with these stops. At the moment a stop classifies as not
>>>>> physically
>>>>> present if it has
>>>>> 	NO highway-tag (to prevent it from showing up on the map)
>>>>> 	AND a naptan:atcoCode-tag
>>>>> 	AND a physically_present tag set to 'no'.
>>>>
>>>> This would be very useful to show
>>>
>>> Yep, there are lots of customary stops in the NaPTAN data in housing
>>> estates
>>> which don’t have any physical presence.
>>
>> And in my town they are terrible for getting them all mixed up - many
>> of the ones they say are customary are really there and vice versa,  
>> so
>> it will be handy to have a clear presentation.
>>
>>>
>>>>>
>>>>> All remaining stops are displayed as an orange stop. This is a bit
>>>>> of
>>>>> catch-all which does not actually display merged stops but
>>>>> everything
>>>>> that is not explicitely marked finished or *not* merged.
>>>>>
>>>> On the basis of the above comments all my stops are orange which is
>>>> less that optimal!
>>>>
>>>>>> We could do with some more documentation! And then starting to
>>>>>> publicise it maybe?
>>>>>
>>>>> A number of people started using it (at least I am constantly
>>>>> receiving
>>>>> error reports when people try to use the not yet implemented
>>>>> functions).
>>>>>
>>>>> After talking to Brian last Thursday I have decided to not develop
>>>>> the
>>>>> actual merger any further as merging can easily be done with josm.
>>>>> Also, things like stop areas add lots of complexity to the merging
>>>>> process and it would be difficult to implement this all. So, I  
>>>>> will
>>>>> concentrate on improving the viewer which seems to be very  
>>>>> helpful.
>>>>
>>>> That sounds good. I found the 'merge' and save buttons rather scary
>>>> and wasn't sure if I had merged things or not, and if so how it  
>>>> knew
>>>> my user name etc. Personally, a straight viewer seems to be the  
>>>> best
>>>> tool. I would click on a stop expecting to see details of its  
>>>> tagging
>>>> and the icon would disappear for something to do with merging I  
>>>> later
>>>> realised.
>>>>
>>>
>>> +1, viewing only is fine for me.
>>>
>> I am glad it's not just me!
>>
>>
>> Regards,
>>
>>
>>
>>
>> Peter
>>
>>>
> cheers
>
> Andy
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb-westmidlands/attachments/20090915/5d562707/attachment.html>