<div><STRONG><EM>Frederik,</EM></STRONG></div> <div><STRONG><EM></EM></STRONG> </div> <div><<<<BR>Of course in that case it has to be modelled as another way. (Even <BR>though it is a very theoretical situation.)<BR>>>></div> <div> </div> <div>No, it is a very "real life" situation. On road can change it direction arrow very often (1 or 2 years). It depends on how bad the traffic jam is in your city and police may want to re-route the traffic by changing direction arrow in any road they like.</div> <div><BR><<<<BR>Because of the relatively small amount of one-way residential <BR>streets, many roads are currently modelled as single ways with <BR>branches. Nobody says that *every* residential road can be modelled <BR>as one single way with branches. But just because you can demonstrate <BR>one example in which doesn't work does not mean that it is not done <BR>at all!<BR>>>></div>
<div> </div> <div>For me, a model should work in all situation. If it has exception then I do not use it because it is a source of bug in our program.<BR></div> <div>Segement model does not work on one-way roads so I will not use it.</div> <div><BR><<<<BR>The routing application can of course just look at the underlying <BR>segments. This is what the existing routing applications do.</div> <div>You will have to simplify the graph anyway before you run the <BR>algorithm, it is really not so hard to include segments as well.<BR>>>></div> <div> </div> <div>I am not talking about other routing application. I am talking about osm routing application itself. If it is easy to implement routing on current osm data then why osm still not have routing feature displaying in the web brower like google map and yahoo map?</div> <div><BR><<<<BR>> If we want we can break polygon with hole into 2 simple polygon <BR>>
without hole. for example: a polygon with hole "O" shaped can break <BR>> into 2 polygons: 1 polygon "(" shaped + 1 polygon ")" shaped.<BR>><BR>> If you model an area as a complex polygon it will be difficult for <BR>> render program to fill complex polygon. Break that area into <BR>> serveral simple polygons and render program can render them faster <BR>> by using simple filling polygon algorithmn.</div> <div>Yes, but this will still cause edges to be drawn where the polygons <BR>touch each other.<BR>>>></div> <div> </div> <div>It does not matter. it still apear on the map as a polygon with hole!</div> <div><BR><<<<BR>Our map data is not primarily aimed at letting programs run faster. <BR>The most important thing about our map data is that it is easy to <BR>maintain. Any kind of conversion or optimisation for a specific <BR>purpose can be done *afterwards* - renderers can throw
away the bits <BR>they don't need, route planners can throw away other bits.</div> <div>A large forest area is, at least as fast as I am concerned, easiest <BR>to maintain if I can model it as what it is - one large forest area <BR>called so-and-so. Not 5 simple polygons making up one forest.<BR>>>></div> <div> </div> <div>What is the main purpose of osm project? make a project easy to edit and maintain? or make a project easy to use?<BR></div> <div>We need to balance both purpose. We can not just focus on easy to edit and maintain. If osm data so difficult to use, users or even developers who has limitation knowlege in geometry may not able to use osm data.</div> <div><BR><<<<BR>The planet file is a raw data transport file. It is not intended to <BR>be completely read by some auto-routing algorithm and then worked on; <BR>it is inteded to be converted into whatever format the application <BR>needs. For
rendering, we have mapnik which uses a converted version <BR>of the planet file (in a PostGIS database, with no segments at all!). <BR>Routing can be done using the existing application "gosmore", which <BR>reformats and indexes a planet file into its own data format, <BR>throwing away everything that is not needed (a whole planet file in <BR>gosmore format needs 256 MB or so).</div> <div> </div> <div>I am repeatng myself when I say that I, too, would like to wave <BR>goodbye to segments but I view this as cosmetics rather than as the <BR>huge obstacle for automatic data processing that you seem to make out.<BR>>>></div> <div> </div> <div>Even convert to orther format is very diffcult. We need to process a very huge text file with uneccessary segments information.<BR></div> <div>It take tim to download, it take time to unzip, it take time to process it.</div> <div> </div> <div>If we can make the
planet.osm smaller without losing any information, why we dont do that? </div> <div><BR><<<<BR>The reason why some people tag addresses to segments is that they can <BR>specify house number ranges with sub-way granularity (e.g. "smallest <BR>number=40, largest number=80, even numbers only"). I don't like <BR>segments being used for this but tagging *every* *single* house <BR>number with a node of its own is not feasible so we have to find a <BR>good way for this.<BR>>>></div> <div> </div> <div>You can use new data type like this:<BR><address id ="1234" fromnodeid="345" tonodeid="5674"/><BR><tag k="smallestnumber', v="40"/><BR><tag k="largesttnumber', v="80"/><BR><tag k="evenonly", v="yes"/><BR>...</div> <div> </div> <div>Then you can tight address id to any object you want.</div> <div> </div> <div>Regards,<BR><BR><BR><B><I>Frederik Ramm <frederik@remote.org></I></B>
wrote:</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Chien,<BR><BR>> Let say today you used segments to model a residential road with <BR>> its branches. One month later, one branch of the residential road <BR>> change from 2 ways to 1 way road. How you modify your segment model <BR>> without break that branch to another way?<BR><BR>Of course in that case it has to be modelled as another way. (Even <BR>though it is a very theoretical situation.)<BR><BR>Because of the relatively small amount of one-way residential <BR>streets, many roads are currently modelled as single ways with <BR>branches. Nobody says that *every* residential road can be modelled <BR>as one single way with branches. But just because you can demonstrate <BR>one example in which doesn't work does not mean that it is not done <BR>at all!<BR><BR>> Furthermore, if you allow using of segments to model ways, user can <BR>> model
Y-shaped ways, T-shaped ways, H-shaped ways, K-shaped ways <BR>> and no routing application can calculate shortest way with Y-shaped <BR>> ways, T-shaped ways, H-shaped ways, K-shaped ways...<BR><BR>The routing application can of course just look at the underlying <BR>segments. This is what the existing routing applications do.<BR><BR>> Compare to Google map and Yahoo map, osm can only render the map in <BR>> the web browser while Google map and Yahoo map can let user key in <BR>> start point and end point then they calculate the route and show in <BR>> the web browser. If you try to apply A* algorithm (finding shortest <BR>> algorithm) to do the same for osm, you will know how difficult to <BR>> do that with current osm data structure (nodes/segments/ways).<BR><BR>You will have to simplify the graph anyway before you run the <BR>algorithm, it is really not so hard to include segments as well.<BR><BR>> If we want we can break polygon with hole
into 2 simple polygon <BR>> without hole. for example: a polygon with hole "O" shaped can break <BR>> into 2 polygons: 1 polygon "(" shaped + 1 polygon ")" shaped.<BR>><BR>> If you model an area as a complex polygon it will be difficult for <BR>> render program to fill complex polygon. Break that area into <BR>> serveral simple polygons and render program can render them faster <BR>> by using simple filling polygon algorithmn.<BR><BR>Yes, but this will still cause edges to be drawn where the polygons <BR>touch each other.<BR><BR>> We have to avoid complex polygons in our map data. It is to help <BR>> render program run faster.<BR><BR>Our map data is not primarily aimed at letting programs run faster. <BR>The most important thing about our map data is that it is easy to <BR>maintain. Any kind of conversion or optimisation for a specific <BR>purpose can be done *afterwards* - renderers can throw away the bits <BR>they don't need, route planners can
throw away other bits.<BR><BR>A large forest area is, at least as fast as I am concerned, easiest <BR>to maintain if I can model it as what it is - one large forest area <BR>called so-and-so. Not 5 simple polygons making up one forest.<BR><BR>> No, your solution does not solve the space issue problem. The <BR>> planet.osm file still wastes a lot of space for string's id. The <BR>> data structure still has 3 components (nodes, strings, ways) which <BR>> is difficult for converting, clipping, routing, and finding <BR>> shorttest way.<BR><BR>The planet file is a raw data transport file. It is not intended to <BR>be completely read by some auto-routing algorithm and then worked on; <BR>it is inteded to be converted into whatever format the application <BR>needs. For rendering, we have mapnik which uses a converted version <BR>of the planet file (in a PostGIS database, with no segments at all!). <BR>Routing can be done using the existing application "gosmore",
which <BR>reformats and indexes a planet file into its own data format, <BR>throwing away everything that is not needed (a whole planet file in <BR>gosmore format needs 256 MB or so).<BR><BR>I am repeatng myself when I say that I, too, would like to wave <BR>goodbye to segments but I view this as cosmetics rather than as the <BR>huge obstacle for automatic data processing that you seem to make out.<BR><BR>> Please do not to tag address to segment. You can tag address to <BR>> node. The xml format of the node will be:<BR>> <NODE id=1234 lon="..." lat="..." /><BR>> <WAY id="123'/> <-- point to the road id that this node's addres <br>> is belong to<br>> <tag k=" v="430" HouseNumber?, /><BR>> <TAG v="123456" , k="PostalCode" /><BR>> <TAG v="23453-4567" , k="Phone" /><BR>> </NODE><BR><BR>The reason why some people tag addresses to segments is that they can <BR>specify house number ranges with sub-way granularity (e.g. "smallest <BR>number=40, largest
number=80, even numbers only"). I don't like <BR>segments being used for this but tagging *every* *single* house <BR>number with a node of its own is not feasible so we have to find a <BR>good way for this.<BR><BR>Bye<BR>Frederik<BR><BR>-- <BR>Frederik Ramm ## eMail frederik@remote.org ## N49°00.09' E008°23.33'<BR><BR><BR></BLOCKQUOTE><BR><p>
<hr size=1>Building a website is a piece of cake. <br>Yahoo! Small Business gives you <a href="http://us.rd.yahoo.com/evt=48251/*http://smallbusiness.yahoo.com/webhosting/?p=PASSPORTPLUS">all the tools to get online.</a>