[OSM-talk] Left and Right?

[Karl Newman]

On Tue, Aug 26, 2008 at 1:30 AM, Andy Robinson (blackadder-lists) <
ajrlists at googlemail.com> wrote:

> Chris Morley wrote:
> >Sent: 24 August 2008 8:51 PM
> >Cc: talk at openstreetmap.org
> >Subject: Re: [OSM-talk] Left and Right?
> >
> >Karl Newman wrote:
> >> On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann <rory at technomancy.org
> >>     Gervase Markham wrote:
> >>      > What's current tagging best practice with things which are to the
> >>     left
> >>      > or the right of a way (e.g. bus stops)?
> >>      >
> >>      > A nearly-approved proposal for a canal-side object has been
> >>     objected to
> >>      > by someone who thinks that the tag should be on a node which is
> >>     part of
> >>      > the canal rather than next to it, with left/right indicated as
> >>     part of
> >>      > the tag key name.
> >>      >
> http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring
> >>      >
> >>      > Do we do that for any other tags? Do we have
> >highway:left=bus_stop?
> >>
> >>     Personally I add the node to left of the way, not as part of the
> way.
> >I
> >>     believe the OSM theory is that the way represents the middle of the
> >>     road. So things like mini-roundabounds and traffic lights are part
> of
> >>     the way (ie road), but a bus stop is off to the side of the road.
> >>
> >>     A similar thinking is obvious in the Karlsruhe House Address Scheme
> >>
> >(
> http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Ka
> >rlsruhe_Schema),
> >>     since the buildings that are numbered are not physically in the
> >middle
> >>     of the road, they are added as nodes to the left or right of the
> way.
> >>
> >> Yes, and that method is not topological, which makes it very difficult
> >> to associate that feature (bus stop, house number, whatever) with the
> >> way that it's actually located on. It should either be a node that is
> >> part of the way, or have a relation to connect the node with the way.
> >
> >I think that the topological aspect of OSM's data structure is important
> >and well worth maintaining in nodes and ways as well as in relations. We
> >are not just drawing pictures, we are also recording relationships. This
> >is why the representation of a mooring - a stretch of canal where boats
> >tie up - as a separate way not connected to the canal seems wrong to me.
> >In this case and with bus stops or house numbers, if you convey which
> >side it is on by having a separate node or way displaced an arbitary
> >short distance to one side, then you lose this side information at lower
> >scales, when it may still be important to a user. With a topological
> >description it is still available.
>
> I totally agree on this approach, ie the node is part of the way, but only
> for features which have direct relationship to each other. This for a bus
> stop of a mooring I make the node part of the way because these are
> features
> that apply and have a relationship with the way itself. For house numbers
> however I make a separate node. I do this for two reasons, the first is
> that
> the house has no relevance to the way it is alongside. We think of house


What? Of course it has relevance. The number means nothing without the
street. Houses don't have GUIDs. It has to be associated with it's street if
you ever want to look it up by address.


> numbers being part of a street but in reality they aren't, they are
> references for buildings. The second reason is that if we were to add nodes
> for every house on both sides of the street to every way we would soon find
> out ways totally unmanageable. As a further reason, houses are normally
> connected to the street with a driveway/footpath. In a fully featured map
> you would draw these in eventually. Its these that make the true
> relationship between building and street.
>

There's no need to add house numbers at every node in a way (except for
weird cases where the house numbers are not sequential). Put the numbers at
intervals and let interpolation take care of the rest.

>
> Always try top keep things simple. Keep like with like and don't try to
> over
> engineer the result and generally the result will be more than sufficient.
>

The Karlsruhe schema is an example of what you get without any engineering
at all--just look how many different scenarios are presented on that page!
The common method used by other systems which store house numbers (for
example, TIGER) is to associate a house number with the way and indicate if
it's on the left or right. This is done only at certain points, and linear
interpolation takes care of the rest. This is also what's expected by
existing navigational systems (e.g., Garmin GPS) and if we ever hope to be
able to use our house number data there, it needs to be able to be
transformed into that format. The Karlsruhe schema does not allow for that
without a huge amount of work and a lot of uncertainty about the result.

I'm not opposed to putting the house number on a separate node, but it needs
to be topologically connected with the way using a relation in that case,
because in real life, the house address *is* associated with the street it's
on.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20080826/6c4b9df6/attachment.html>