[Talk-gb-westmidlands] NOVAM Viewer

[Andy Robinson (blackadder-lists)]

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!
>>>>
>>>> Ciarán Mooney <general.mooney at googlemail.com> schrieb:
>>>>
>>>>> I am trying to merge some bus stops on Penns Lane, Sutton
>>>>> Coldfield.
>>>>>
>>>>> http://www.openstreetmap.org/?lat=52.53496&lon=-
>>> 1.81479&zoom=15&layers=B000FTF
>>>>>
>>>>> I have moved them all to the correct position. Some of them were
>>>>> spectacularly off, I was very surprised that the Naptan data was
>>>>> that
>>>>> bad!
>>>>>
>>>>> However on Xoff's little NOVAM viewer I can see they have changed
>>>>> colour to orange and they are incomplete, but I don't know why.
>>>>> What
>>>>> tags are they missing??
>>>>
>>>> I can only see one orange stop which is missing the shelter tag. Did
>>>> you manage to fix the other ones?
>>>>
>>>> The rules for the colouring of the bus stops are as follows:
>>>>
>>>> Bus stops should show up green if they have
>>>> 	a highway-tag [1]
>>>> 	AND a naptan:AtcoCode-tag
>>>> 	AND NO naptan:unverified-tag
>>>> 	AND NO naptan:verified=no
>>>> 	AND a 'route_ref' tag
>>>> 	AND a shelter tag.
>>>
>>> Ok, but why is the route_ref tag required? I don't intend to add
>>> route
>>> refs to the stops - I am expecting the software to pick that up from
>>> the associated routes. Can you remove that requirement or I might end
>>> up adding null route_ref tags just to make NOVAM useful to be ;)
>>
>> When surveying in Brum all the route refs are on the bus stop signs.
>> So
>> that’s why we put them on the stop (ie adding what it says on the
>> ground).
>> It's also a lot easier to add the routes if you know which stops
>> they go to
>> :-)
>>
>
>However we don't have route numbers on the flags, and many stops don't
>have timetables either so the insistent on having this tag forces me
>to either 'game' the tags to make NOVAM useful, or to ignore NOVAM
>which is a shame.

Agreed, needs a work around. I too have noted that outside the west mids,
most stops don’t carry route info. Is there an alternative entry that ought
to be there, or is the verified flag sufficient?

>
>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.

>
>>>
>>> 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