Gervase Markham wrote:
> [This post contains other people's ideas and points; thanks to all of them.]
>
> It seems from the Left and Right discussion that there are many features
> we wish to map which are associated with the "side" of a way. This is a
> consequence of the fact that we are using things with zero width (ways)
> to represent real-world features which have a width (e.g. roads and canals).
>
> Examples include bus stops and shelters, parking restrictions and taxi
> ranks on roads, or mooring information, embankments and turning points
> on canals. Note that some of these are point features and others are
> length features.
>
> The key commonality is that *these are all things that would not be
> there if the way was not there*. This definition is what excludes phone
> boxes, post boxes etc. from needing this sort of association. (House
> numbers seem to me to be an edge case; let's leave that for now.)
>
> It seems to me that there are three ways we can deal with this:
>
> 0) Just place point features next to the way, with no explicit
> association apart from proximity. This is what we do now, and this lack
> of association causes problems. For linear features, you need to create
> a new, parallel way for that feature. Having to create this extra way is
> sub-optimal.
>
> One other problem with this is that it defines a set distance from the
> feature to the way.
I don't see this as a problem. It's in fact an additional useful
information that your left/right scheme just loose.
> This means that, as you zoom out, the feature icon
> migrates onto the way itself as the way rendering "thickens".
As you zoom out, the POI aren't displayed anymore, so I doubt
this can be a problem.
And if you think it's really a problem, when used along with
relations as proposed below, the renderer can treat those points
exactly as if they were part of the way with left/right tags.
> 1) Create relations to associate the point with the way - one relation
> per feature type, or perhaps a generic relation type.
That would be useful.
> Except that relations are heavyweight things
Heavyweight things ?? I don't get what you mean here.
> complicated to set up (in current editors).
The same way we shouldn't map for renderers, we also shouldn't
map for editors !
If editors are somewhat complicated at setting relations,
the should be improved...
> 2) The generic left-right scheme proposed below.
>
> Left/Right Scheme
> -----------------
>
> I propose that it be possible for features to be tagged using a generic
> left/right scheme, with left and right being relative to the direction
> of the way.
>
> So you might have a road way with a node somewhere in the middle with
> (for example):
> left:highway=bus_stop
> right:parking=pay_and_display
>
> And a way which forms part of a canal might have (for example):
> right:mooring=24h
> left:embankment
How do you specify the distance from the middle of the way ?
> Changes Needed
> --------------
>
> Renderers:
> Renderers would need to place the icon for the feature offset at right
> angles to the way, a feature-dependent distance, with a default for most
> features of "just far enough that the icon appears alongside the way",
> which is probably zoom-dependent. (This is a good thing - avoids the
> problems given above.) After moving the location, they render the
> feature as normal, as if a node were there. Renderers already have code
> for choosing a good location for icons for area features such as parking
> lots, so it'll be similar to that.
How do you render a node which has a right:highway=bus_stop tag and which
belongs to several ways ? (at an intersection for example)
|
|
|
--->-----+----->--
Here, the intersection node (+) is tagged with right:highway=bus_stop.
It's quit obvious for us what it means, but a renderer may have hard
time with it.
Note that the solution of placing a node next to the way along with
a relation allows the exact same rendering as what you propose, without
the above mentioned ambiguity.
> Editors:
> Editors would need to switch "right" for "left" and vice versa in all
> tags when reversing a way. Note that this requires no special knowledge
> of what the prefixed tag means - that's why we have a generic mechanism.
> They might also apply this switching to some special cases such as "oneway".
The problem with this is that as long as an editor without this feature
is still in use somewhere, it will get us into trouble. (and some people
tend to use old versions for a long time)
Aurel
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
