[OSM-talk] correctly mapping avenues

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl Newman wrote:
| On Feb 11, 2008 7:20 AM, Bernd Raichle <bernd at dante.de
| <mailto:bernd at dante.de>> wrote:
|
|     Hi,
|
|
|     on Sunday, 10 February 2008 08:34:31 -0800,
|     Karl Newman <siliconfiend at gmail.com <mailto:siliconfiend at gmail.com>>
|     writes:
|      > On Feb 10, 2008 4:21 AM, Frederik Ramm <frederik at remote.org
|     <mailto:frederik at remote.org>> wrote:
|      > > > Since trees lining a way/street are such a common
occurence, why
|      > > > not have a simple additional tag to the main road.
|      > > >
|      > > > lined_by_trees=yes/no/left/right
|      > >
|      > > I'm a bit unhappy about needlessly inflating the importance
of the
|      > > direction of ways. Long-term, I would actually like to get rid
|     of the
|      > > direction and express everything in relations.
|
|     This means, that you find it necessary to have something like a
|     "direction" or a "side", both of this features related to a way?
|     But you don't want to express a direction or a side by the _implicit
|     order_ of the way nodes.
|
|
|      > >                                                 The reasons for
|     this
|      > > are
|      > >
|      > > (a) the direction is too easily changed, sometimes by mistake
|
|     ... because none of the current OSM editors show direction- or
|     side-related tags explicitly.
|
|
|      > > (b) there might be multiple conflicting things that rely on the
|      > >    direction, e.g. a road that is oneway from A to B but has a
|      > >    slope from B to A
|      > >
|      > > Anything with "left/right" in it also relies on direction. I'd
|     prefer
|      > > "east/west/north/south", or using an explicit relation that says
|      > > "trees on the right between nodes A and B along road C".
|
|     I am against east/west/north/south because there are a lot of
|     ways/areas/things which do not go straight ahead.
|
|
|      > Okay, this thread is at risk of spinning wildly off-topic, but
|     I've been
|      > thinking about this situation recently. It seems to clamor for
|     the use of
|      > specialized relations that are "direction-aware". That way, if a
|     way is a
|      > member of a relation and has directional properties (left/right),
|     then the
|      > editors could look for those relations when the way is reversed
|     and either
|      > fix them automatically or at the minimum raise a warning dialog.
|      >
|      > I also had some other ideas about enforcing referential
integrity for
|      > another type of specialized relation (if one or more node
|     relation members
|      > is required to be part of a way relation member, then enforce
|     that rule).
|      > That rule could actually be enforced by the API.
|      >
|      > These specialized relations would just give some structure to the
|     wide-open
|      > relation type, without implying anything about the nature of the
|     relation.
|      > It could possibly be accomplished through special tags on the
|     existing
|      > relation structure.
|
|     Do you have any propositions how this will look like or how this
|     should be done?
|
|     A few days ago I have started a new proposal for a "Segmented Tag",
|     which relates a set of tags to a directed or undirected part of a way
|     (I have called this part "segment" inspired by GDF's "Segmented
|     Attributes").  I have not found the time yet to finalize the proposal
|     adding some examples, nonetheless it can already be found in the OSM
|     Wiki (Relations/Proposed/Segmented Tags).
|
|
|     Best wishes,
|      -bernd
|
|
| Big +1 on this proposal. That's exactly what I've been thinking about
| lately. It's stupid to chop up nice long ways just because the speed
| limit changes or the way happens to cross a bridge.

I think the opposite - we should move nearly all tags from ways into
relations so that we can chop the ways more - probably at every junction
- - without causing duplication.


Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHtNn2z+aYVHdncI0RAhBRAJ9XK0il1W4tAiAumfcKqWDqY/NR2ACg3eGx
nHl5J7hXD+iNpOOSyKADb+4=
=58IA
-----END PGP SIGNATURE-----