On 10/23/06, <b class="gmail_sendername">bvh</b> <<a href="mailto:bvh-osm@irule.be">bvh-osm@irule.be</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> >On Mon, Oct 23, 2006 at 03:37:19PM +0100, Etienne wrote:<br>> >> Ways are *ordered* lists of segments.<br>> ><br>> >On what basis should the ordering take place?<br>><br>><br>> In a .osm file the <seg> elements within a <way> element are listed in the

<br>> order defined in the database.<br>><br>> In JOSM segments are sequenced in ways in the order in which they were<br>> added.  So each time a segment is added it will be added to the end of the<br>> list.  Once exception, if a node is inserted then the new segment is

> inserted adjacent to the segment at the insertion point (which is what you > would expect). > > There is no direct way of viewing or altering the segment order in JOSM.  I > think there is a way view and edit the segment order in the Applet.

<br>><br><br>So basically, although a way is an ordered list of segments, there<br>is no (easy) way to change or view the order, the server doesn't care<br>about the order and there is no rule as to how the order should be

interpreted in terms of structures in reality.</blockquote><div> The order of segments is used for a number of purposes: 1) Route planning applications need to know where a way starts, where it ends and how long it is between those two points.

2) Osmarender uses the node order (implied by the segment order and direction) to be able to draw names along the path of a street 3) Node order (implied from segment direction) is used to indicate one-way streets, river flow, etc.

<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For all intents and purposes it seems that a way is actually<br>an unordered list of segments from the point of view of a client

<br>editor.<br><br>I think I agree more with the other poster, that a way is (should be)<br>conceptually just an (unordered) collection of segments.<br><br>> Each non-contiguous part of the street would be a separate way.  There is a

> subsiduary proposal to implement a hierarch of ways which would enable a > group of ways to be annotated with a common set of tag values (such as the > street's name). That's just absurd! What would be the advantage to the current system?

<br>To me that just seems as if ways become segments and something newly<br>invented becomes ways. It is better the way it is imho.</blockquote><div><br>The current system does not allow two ways to share the same pair of nodes but with different directions.  

An alternative implementation would be to allow segments to be polylines (an ordered list of nodes) and then treat ways as an unordered collection of segments.  You might feel more comfortable about this, but in fact it is structurally the same solution as that which I tried to explain earlier.

<br><br></div>Etienne<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">cu bart<br><br>_______________________________________________<br>

dev mailing list<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a>

<br></blockquote></div><br>