[Talk-gb-westmidlands] NOVAM Viewer

Peter Miller peter.miller at itoworld.com
Wed Sep 16 08:03:23 BST 2009


On 15 Sep 2009, at 23:25, Christoph Böhme wrote:

> Peter,
>
> thank you for your comments. The problems with the current colour
> scheme in NOVAM are mostly down to the workflow that I originally
> envisioned for importing/activating NaPTAN bus stops. This workflow
> concentrated on the idea of merging OSM and NaPTAN bus stop nodes.
> Hence, I defined three basic states to distinguish OSM, NaPTAN and
> *merged* stops.
>
> However, it has turned out now that no one is actually merging stops
> but just deleting OSM nodes, modifying NaPTAN nodes and -- in
> Birmingham -- switching them on by adding highway=bus_stop. So, the
> three colours actually describe:
>
> yellow - rendered bus stops without NaPTAN data (old OSM stop)
> blue - not rendered bus stops with NaPTAN data
> orange - rendered bus stops with NaPTAN data
>
> I am not really sure what the best approach to redefining the colour
> scheme would be. One posibility would be to leave it as it is and just
> change the descriptions. Another, probaly better solution, would be to
> use blue for rendered stops with NaPTAN data and some other colour for
> not rendered NaPTAN stops (dark blue, grey, transparent?). Orange and
> green could then be used once a stop has naptan:verified=no removed to
> highlight bus stops which do not yet comply to the (to be defined)
> tagging scheme.

I would like to use the tool to check for unverified NaPTAN stops, for  
additional stops in OSM that are not in NaPTAN and also for stop that  
have NaPTAN tags but don't have highway=bus_stop for some reason.  ie:

1) Regular verified bus stops (with highway=bus_stop and not with  
'verified=no')
2) Bus stops in OSM that don't have NaPTAN values (ie with  
highway=bus_stop but not 'naptan:AtcoCode' key)
3) NaPTAN stops in OSM which are not rendered on the map (ie they have  
a 'naptan:AtcoCode' but not a highway=bus_stop)

This would allow me to complete the verification, and then keep  
highlight the differences that I have spotted between the two. I guess  
it could also be interesting to track the differences between the  
NaPTAN tag values and the OSM tag values to check which ones have been  
changed (ie 'local_ref' does not match 'naptan:indicator' but that is  
something to do later.

Do also bear in mind that we have ferry terminals, airports, tram  
stops and taxi ranks to import at some point. Far fewer of these, but  
the same tool could be useful.

> PS: I am currently changing NOVAM and NPTG-Viewer to use
> Postgres/PostGIS instead of MySQL as I am moving to a new webserver at
> the end of September. For this reason I would like to postpone the
> implementation of a new colouring scheme until this move has  
> completed.

No problem - I will do a 'tidy up' review of NaPTAN when it is done.


Thanks,


Peter

>
> Peter Miller <peter.miller at itoworld.com> schrieb:
>
>>
>> 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 ;)
>>
>> 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
>>
>>
>>>
>>> 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.
>>
>>>
>>> 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
>>>
>>> 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.
>>
>>
>> Regards,
>>
>>
>>
>>
>> Peter
>>
>>
>>>
>>> Cheers,
>>> Christoph
>>>
>>> _______________________________________________
>>> Talk-gb-westmidlands mailing list
>>> Talk-gb-westmidlands at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>





More information about the Talk-gb-westmidlands mailing list