> Date: Wed, 27 Aug 2008 09:41:03 +0100
> From: "Dave Stubbs" <[EMAIL PROTECTED]>
> Subject: Re: [OSM-talk] Left and Right?
> To: "Robin Paulson" <[EMAIL PROTECTED]>
> Cc: OSM Talk <talk@openstreetmap.org>
> Message-ID:
>       <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=UTF-8
> 
> On Wed, Aug 27, 2008 at 12:13 AM, Robin Paulson <[EMAIL PROTECTED]>
> wrote:
> > 2008/8/26 Mark Williams <[EMAIL PROTECTED]>:
> >> Is 'mapping for renderers' any worse than 'mapping for routers'?
> >
> > both are bad i think
> >
> >> Step back from the "we're going to use it for routing busses" approach
> a
> >>  moment; a fair few users may wish to print a map, so the renderers
> need
> >> to do this right. I will prefer to see the bus-stops pass on the sat-
> nav
> >> map as reference as I drive by them. I might like warning of busses
> >> likelihood of stopping.
> >>
> >> My main driver on this is that they are roadside features, not highway
> >> features. As I said, like pubs, postoffices, etc. This is the real
> >> world, mapping what's on the ground, bus stops are not like
> >> mini-roundabouts or traffic lights.
> >
> > well, it's a representation of the real world, and idealised, yet
> > imperfect one at that
> >
> > i'm not sure why they're roadside features, rather than highway
> > features. the bus stops *on* the highway (which includes the path, as
> > we discussed earlier). at no point does it leave the highway
> >
> > the *sign* is on the roadside. we're not mapping signs. maps and signs
> > do the same thing, but in different ways - they contain information
> > about a mapworthy feature, but each are not mapworthy themselves.
> > we're not mapping signs
> 
> 
> What it comes down to is this: a bus stop is not the same thing as
> where the bus stops. Although they're obviously related. We have half
> the people in this discussion trying to map the bus stop, and half of
> them trying to map where the bus stops, and half happy to do either
> really... so yes, it has a sign (and possibly a shelter), but it's not
> _just_ a sign: it's a destination in its own right and about the only
> sign I can think of right now that people queue up behind. It's also
> very important where it is, unlike most signs which are just telling
> you something about somewhere else.
> 
> Whether a "bus stop" is a feature of the road, or a feature of the
> pavement is entirely a matter of perspective...
> 
> If I happen to be standing at a bus stop I really don't care which
> road the bus will come down to pick me up: I'm at the bus stop so it
> should be fairly obvious. And the only important thing is how to get
> to the bus stop, because if I'm not in the right place the bus won't
> stop even if I wave at it frantically (OK, this bit varies from place
> to place... usually inversely proportional to the number of buses :-(
> )
> 
> On the other hand if I'm on the bus, then the exact position on the
> pavement of the bus stop where I get off isn't important. I just want
> to know when the bus has got to the right part of the route and I
> should hit the button to get off. The bus will stop in the right place
> on it's own (wow, magic).
> 
> Any arguments re the pavement being part of the road anyway are
> ultimately flawed... ie: post boxes phone boxes, cycle parking and
> even ATMs would be way nodes under this definition.... and whether or
> not they should be doesn't really matter, as I don't think anyone is
> adding them as such.
> 
> We can't represent both properties properly with a single node. In
> either case we lose something, or else make reconstructing it
> difficult. So I'd suggest this: map both, or whichever you happen to
> be interested in, and someone think up a way of binding them together
> nicely with a relation for the topologists.
> 
> Personally I just stick a node where the bus stop actually is. That's
> what is most useful for me at the present time.

With regard to the Dave's important distinction between the bus stop (where
passengers wait) and the actual position on the highway where the bus stops,
let's not forget trams and trains where in some cases there may be one
location where people wait which has tracks on both sides and vehicles stop
either side of the Stop Point. This begs the question about how we map
platforms and quays for trains/trams/metro and ferry which are actually
areas features beside one or more ways. Trains also can have sub-platforms
where there is platform 4 which for some services is split into 3A and 3B on
in the case of my local station into 3A, 3B and 3C.

My vote is to map where the fixed infrastructure is (the platform, pole,
shelter) as point or area feature in the correct physical location beside
the road but possibly software will need to deal with both models for the
time being. If the separate node approach is used then the assumption should
be that the software will associate it with the nearest Way at the nearest
point and that the way should not be more than X meters from an appropriate
way. 
 
We should note however that we are drifting from a network mode (of links
and nodes) into a full 2D or even 3D modelling environment where everything
is actually a surface. Current we have bodged some surfaces (parks,
buildings, sports pitches etc etc) onto a links/nodes model. In time I think
we will need to make a clearer distinction between the different
representations.

We don't actually seem to have any applications which are using this public
transport information yet (is there one?). When we do have one I think it
will all become clearer. If a consensus emerges we can then convert the data
in the model to the appropriate format (as long as we have captured it in
the first place!). For now collecting it either way is a lot better than not
collecting it.



Regards,


Peter


> 
> Dave
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
> 
> 
> End of talk Digest, Vol 48, Issue 69
> ************************************


_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to