<DIV>Hi <STRONG><EM>Frederik Ramm,</EM></STRONG></DIV>  <DIV><EM></EM> </DIV>  <DIV>You two main reasons to keep the segment may not valid.</DIV>  <DIV> </DIV>  <DIV><<<</DIV>  <DIV>1. Currently, we can have branching ways (e.g. Y-shaped). These need <BR>to be split into several ways when we remove segments. This is <BR>possible but probably difficult to automate fully (e.g. if you have a <BR>main road with lots of little branches, you want the branches to be <BR>split off and the main road to remain in one piece!).<BR> >>></DIV>  <DIV> </DIV>  <DIV>Your argument is not valid because you are assuming that branching ways (Y-shaped) are 2 ways direction but they may be one way direction in the real life!</DIV>  <DIV> </DIV>  <DIV>For example: if we have an one-way direction high way that has 2 branches: 1 branch go in the main high way and another branch go out from the main high way, how you use way's segments to model
 this way without break it to 2 ways? Remember we do not have tag oneway=yes for each segment, we only have one tag oneway=yes for each way!</DIV>  <DIV> </DIV>  <DIV>Please see the attached picture for more details.</DIV>  <DIV> </DIV>  <DIV><<<</DIV>  <DIV>2. Currently, we can have non-contiguous ways, which are sometimes <BR>used to model "areas with holes" (say you have a forest with a <BR>clearing, then the forest will be one "ring" with clockwise segments <BR>and the clearing another "ring" with anticlockwise segments and both <BR>joined into one way). You cannot model this with simple ways alone; <BR>another way would have to be found for areas with holes in them.<BR>>>></DIV>  <DIV> </DIV>  <DIV>Without segments, I still can use simple way to model area with hole.</DIV>  <DIV>For example: I have 11 nodes. Node: 1, 2, 3, 4, 10, 11 form the outer ring clockwise and nodes: 5, 6, 7, 8, 9 form inner
 ring anticlockwise. Two rings joined at node 4 and 5.</DIV>  <DIV> </DIV>  <DIV>So, to model the above area with hole, I can use simple way like this (1, 2, 3, 4, 5, 6, 7, 8, 9, 5, 4, 10, 11)</DIV>  <DIV> </DIV>  <DIV>Please see the attached picture for more details.</DIV>  <DIV> </DIV>  <DIV>For your information, Garmin is using this method to model polygon with hole. They have only 2 data types (polygon has same structure with polyline):</DIV>  <DIV> </DIV>  <DIV>point(label,type,lat,lon)</DIV>  <DIV>polyline(label,type,lat[0],lon[0],....,lat[n],lon[n])</DIV>  <DIV>polygon(label,type,lat[0],lon[0],....,lat[n],lon[n])</DIV>  <DIV> </DIV>  <DIV> </DIV>  <DIV>Please bear in mind two things:</DIV>  <DIV> </DIV>  <DIV>1. When you design data structure for map, you need to save any space as much as possible because map data are very huge.</DIV>  <DIV> </DIV>  <DIV>2. Data structure must be simple enough so that other program can
 process your data. If your data structure is so complicated (nodes, segments, ways) other program may not able to calculate shortest way for route planning or the program will spend a lot of time to calculate the route --> slow respond to user.</DIV>  <DIV> </DIV>  <DIV>I hope osm foundation will consider my arguments and take out the segment component from planet.osm xml file.</DIV>  <DIV> </DIV>  <DIV>If we can implement data structure like this:</DIV>  <DIV>nodes (id, lat, lon, tag)<BR minmax_bound="true">ways (id, nodeid[0],nodeid[1],...,nodeid[n], tag)<BR minmax_bound="true"></DIV>  <DIV>Then we can save a lot of space in planet.osm xml file and other program will process osm data more easily (trim, convert...)</DIV>  <DIV> </DIV>  <DIV> </DIV>  <DIV>Regards,</DIV>  <DIV> </DIV>  <DIV> </DIV>  <DIV>Frederik Ramm's arguments:<BR><<<</DIV>  <DIV>Chien,</DIV>  <DIV>it is well known and long discussed that removing
 segments will <BR>make things easier.</DIV>  <DIV>You are, however, slightly underestimating the complexity of the <BR>task, because of two reasons:</DIV>  <DIV>1. Currently, we can have branching ways (e.g. Y-shaped). These need <BR>to be split into several ways when we remove segments. This is <BR>possible but probably difficult to automate fully (e.g. if you have a <BR>main road with lots of little branches, you want the branches to be <BR>split off and the main road to remain in one piece!).</DIV>  <DIV>2. Currently, we can have non-contiguous ways, which are sometimes <BR>used to model "areas with holes" (say you have a forest with a <BR>clearing, then the forest will be one "ring" with clockwise segments <BR>and the clearing another "ring" with anticlockwise segments and both <BR>joined into one way). You cannot model this with simple ways alone; <BR>another way would have to be found for areas with holes in them.</DIV>  <DIV>Bye<BR>Frederik</DIV> 
 <DIV>>>><BR></DIV>  <DIV> </DIV>  <DIV>Chien Nguyen Khac's arguments:</DIV>  <DIV><<<</DIV>  <DIV minmax_bound="true">I have studied osm data stucture.<BR minmax_bound="true">osm data stucture contains 3 main components (nodes,segments,ways):<BR minmax_bound="true">nodes (id, lat, lon, tag)<BR minmax_bound="true">segments (id, fromnodeid, tonodeid)<BR minmax_bound="true">ways (id, segmentid[0],segmentid[1],...,segmentid[n], tag)<BR minmax_bound="true"><BR minmax_bound="true"><BR minmax_bound="true">Actually, to store a map data we need only 2 components: nodes and ways.<BR minmax_bound="true">nodes (id, lat, lon, tag)<BR minmax_bound="true">ways (id, nodeid[0],nodeid[1],...,nodeid[n], tag)<BR minmax_bound="true"><BR minmax_bound="true">I wonder why osm foundation introduce segment component in between node and way component? So I read the osm's wiki to find the answer.<BR minmax_bound="true">osm foundation said that they need to use segment component
 because ways can share segment!<BR minmax_bound="true">Well, it may be true in theory but in the real life how many segments have been shared among ways? I guess not so many.<BR minmax_bound="true"><BR minmax_bound="true">So, by introducing segment component in between node and way to save some spaces (sharing segments between ways), osm foundation make osm data structure design waste a lot of space when they output the osm data to planet.osm in xml format!<BR minmax_bound="true"><BR minmax_bound="true">Users (who use planet.osm like me) need to write our own program (perl, java or whatever language) to process a 4GB planet.osm text file. And this 4GB will grow up very fast in the near furture.<BR minmax_bound="true"><BR minmax_bound="true">Furthermore, the current osm data structure design (nodes,segments,ways) make thing very dificult to process planet.osm xml file.<BR minmax_bound="true"><BR minmax_bound="true">Forexample: if I want to get the data from London city from
 planet.osm, what I need to do?<BR minmax_bound="true">My program need to do the following tasks:<BR minmax_bound="true"><BR minmax_bound="true">1. Open and read planet.osm xml file<BR minmax_bound="true">2. Trim all the nodes that are outside London's bounds --> write result to file<BR minmax_bound="true">3. Trim all segments that are outside London's bounds --> write result to file<BR minmax_bound="true">4. Trim all ways that are outside London's bounds --> write result to file<BR minmax_bound="true"><BR minmax_bound="true"><BR minmax_bound="true">Task 2 is very simple, just check the node's lat and lon within the bounds --> after task 2 finish we have a set of nodes within bounds<BR minmax_bound="true">Task 3 is a little bit complicated, we need to check segment's fromnodeid and tonodeid against the set of nodes within bounds -->  after task 3 finish we have a set of segments within bounds<BR minmax_bound="true">Task 4 is extremely complicated, we
 need to check way's segment against the set of segments within bounds.<BR minmax_bound="true"><BR minmax_bound="true"><BR minmax_bound="true">If we can implement a new data structure like this:<BR minmax_bound="true">nodes (id, lat, lon, tag)<BR minmax_bound="true">ways (id, nodeid[0],nodeid[1],...,nodeid[n], tag)<BR minmax_bound="true"><BR minmax_bound="true">Then we can save a lof of space in planet.osm xml file and it is also easy for other programs to process planet.osm file.<BR minmax_bound="true"><BR minmax_bound="true">Other programs just need to do fewer tasks:<BR minmax_bound="true">1. Open and read planet.osm xml file<BR minmax_bound="true">2. Trim all the nodes that are outside London's bounds --> write result to file<BR minmax_bound="true">3. Trim all ways that are outside London's bounds --> write result to file<BR minmax_bound="true"><BR minmax_bound="true">The program will require less memory and run faster because it does not need to allocate memory
 to store and process segment components.</DIV>  <DIV minmax_bound="true"> </DIV>  <DIV minmax_bound="true">>>></DIV><p>
      <hr size=1>Be a better Globetrotter. <a href="http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545469">Get better travel answers </a>from someone who knows.<br>Yahoo! Answers - Check it out.