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@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@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
_______________________________________________
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
