[OSM-dev] ways with 'spurs'

[Andy Robinson]

Robert (Jamie) Munro wrote:
>Sent: 26 February 2007 12:13 PM
>To: Robert Hart; dev at openstreetmap.org
>Subject: Re: [OSM-dev] ways with 'spurs'
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Robert Hart wrote:
>>
>>> IMHO, not if they're the same road, there's no point. I live in a
>>> cul-de-sac with fork in it, and it would be stupid to have to tag it
>>> twice, especially if this meant the name was rendered twice.
>> Osmarender
>>
>> You don't have to tag it twice. Just create both ways. Select them both,
>> and then tag. (in general tag names individually, but apply highway etc.
>> tags in groups)
>
>That /is/ tagging it twice. It puts duplicate data in the database. If I
>make a spelling mistake (or there is an offical change of name or
>status), it has to be fixed it twice etc. (yes I know I can fix it twice
> in one go if I am using the right tools, but that's not the point).
>
>The data model has this flexibility built in. It just seems stupid to
>not use it.
>

This comes back to the longstanding discussion about whether or not to drop
segments and only use an ordered list of nodes for ways. In that respect all
ways would therefore be linear and therefore forks would not be valid. At
the moment we have a significant db overhead just carrying segments when
there really is no need for them.

If there is a wish to reduce the volume of tag data by eliminating duplicate
tags for the same feature then we need a holder to contain all the ways that
make that feature. The tags would be applied to the holder rather than the
individual ways. "Superways" was the suggested name for this although I'm
personally not sure that fits.

Alternatively we could redefine what segments and ways mean. The segment
would become a polyline feature consisting of an ordered list of nodes and
the way would become the container for all these polylines making up the
common feature.

This node only approach makes much more sense when with time small sections
of a feature are removed to give the section more appropriate tags. Bridges
for instance.

Any change that might or might not be debated here is unlikely to be
implemented in the near future, simply because a fundamental change to the
db requires a pile of time to sort out (due to the need to migrate the
existing data to the changed rules) and since time is ever pressing on the
dev team its probably going to need a unified consensus here that its
priority has moved up a notch before the effort, and more importantly the
moving away from other tasks, is deemed worthwhile.

Cheers

Andy 

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk


>Robert (Jamie) Munro
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFF4s7ez+aYVHdncI0RAsX4AKC3vpWqxbD+7Y4KliYm21uJj6YLLACeIZpC
>VNElrI5RWQ2/jgWFMJoNyzI=
>=5eTw
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>dev mailing list
>dev at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev