[OSM-dev] Suggestion about design of OSM data structure (take out segments)

[Chien Nguyen Khac]

Frederik,
   
  <<<
Of course in that case it has to be modelled as another way. (Even  
though it is a very theoretical situation.)
>>>
   
  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.
  
<<<
Because of the relatively small amount of one-way residential  
streets, many roads are currently modelled as single ways with  
branches. Nobody says that *every* residential road can be modelled  
as one single way with branches. But just because you can demonstrate  
one example in which doesn't work does not mean that it is not done  
at all!
>>>
   
  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.

  Segement model does not work on one-way roads so I will not use it.
  
<<<
The routing application can of course just look at the underlying  
segments. This is what the existing routing applications do.
  You will have to simplify the graph anyway before you run the  
algorithm, it is really not so hard to include segments as well.
>>>
   
  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?
  
<<<
> If we want we can break polygon with hole into 2 simple polygon  
> without hole. for example: a polygon with hole "O" shaped can break  
> into 2 polygons: 1 polygon "(" shaped + 1 polygon ")" shaped.
>
> If you model an area as a complex polygon it will be difficult for  
> render program to fill complex polygon. Break that area into  
> serveral simple polygons and render program can render them faster  
> by using simple filling polygon algorithmn.
  Yes, but this will still cause edges to be drawn where the polygons  
touch each other.
>>>
   
  It does not matter. it still apear on the map as a polygon with hole!
  
<<<
Our map data is not primarily aimed at letting programs run faster.  
The most important thing about our map data is that it is easy to  
maintain. Any kind of conversion or optimisation for a specific  
purpose can be done *afterwards* - renderers can throw away the bits  
they don't need, route planners can throw away other bits.
  A large forest area is, at least as fast as I am concerned, easiest  
to maintain if I can model it as what it is - one large forest area  
called so-and-so. Not 5 simple polygons making up one forest.
>>>
   
  What is the main purpose of osm project? make a project easy to edit and maintain? or make a project easy to use?

  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.
  
<<<
The planet file is a raw data transport file. It is not intended to  
be completely read by some auto-routing algorithm and then worked on;  
it is inteded to be converted into whatever format the application  
needs. For rendering, we have mapnik which uses a converted version  
of the planet file (in a PostGIS database, with no segments at all!).  
Routing can be done using the existing application "gosmore", which  
reformats and indexes a planet file into its own data format,  
throwing away everything that is not needed (a whole planet file in  
gosmore format needs 256 MB or so).
   
  I am repeatng myself when I say that I, too, would like to wave  
goodbye to segments but I view this as cosmetics rather than as the  
huge obstacle for automatic data processing that you seem to make out.
>>>
   
  Even convert to orther format is very diffcult. We need to process a very huge text file with uneccessary segments information.

  It take tim to download, it take time to unzip, it take time to process it.
   
  If we can make the planet.osm smaller without losing any information, why we dont do that? 
  
<<<
The reason why some people tag addresses to segments is that they can  
specify house number ranges with sub-way granularity (e.g. "smallest  
number=40, largest number=80, even numbers only"). I don't like  
segments being used for this but tagging *every* *single* house  
number with a node of its own is not feasible so we have to find a  
good way for this.
>>>
   
  You can use new data type like this:
<address id ="1234" fromnodeid="345" tonodeid="5674"/>
<tag k="smallestnumber', v="40"/>
<tag k="largesttnumber', v="80"/>
<tag k="evenonly", v="yes"/>
...
   
  Then you can tight address id to any object you want.
   
  Regards,


Frederik Ramm <frederik at remote.org> wrote:
  Chien,

> Let say today you used segments to model a residential road with 
> its branches. One month later, one branch of the residential road 
> change from 2 ways to 1 way road. How you modify your segment model 
> without break that branch to another way?

Of course in that case it has to be modelled as another way. (Even 
though it is a very theoretical situation.)

Because of the relatively small amount of one-way residential 
streets, many roads are currently modelled as single ways with 
branches. Nobody says that *every* residential road can be modelled 
as one single way with branches. But just because you can demonstrate 
one example in which doesn't work does not mean that it is not done 
at all!

> Furthermore, if you allow using of segments to model ways, user can 
> model Y-shaped ways, T-shaped ways, H-shaped ways, K-shaped ways 
> and no routing application can calculate shortest way with Y-shaped 
> ways, T-shaped ways, H-shaped ways, K-shaped ways...

The routing application can of course just look at the underlying 
segments. This is what the existing routing applications do.

> Compare to Google map and Yahoo map, osm can only render the map in 
> the web browser while Google map and Yahoo map can let user key in 
> start point and end point then they calculate the route and show in 
> the web browser. If you try to apply A* algorithm (finding shortest 
> algorithm) to do the same for osm, you will know how difficult to 
> do that with current osm data structure (nodes/segments/ways).

You will have to simplify the graph anyway before you run the 
algorithm, it is really not so hard to include segments as well.

> If we want we can break polygon with hole into 2 simple polygon 
> without hole. for example: a polygon with hole "O" shaped can break 
> into 2 polygons: 1 polygon "(" shaped + 1 polygon ")" shaped.
>
> If you model an area as a complex polygon it will be difficult for 
> render program to fill complex polygon. Break that area into 
> serveral simple polygons and render program can render them faster 
> by using simple filling polygon algorithmn.

Yes, but this will still cause edges to be drawn where the polygons 
touch each other.

> We have to avoid complex polygons in our map data. It is to help 
> render program run faster.

Our map data is not primarily aimed at letting programs run faster. 
The most important thing about our map data is that it is easy to 
maintain. Any kind of conversion or optimisation for a specific 
purpose can be done *afterwards* - renderers can throw away the bits 
they don't need, route planners can throw away other bits.

A large forest area is, at least as fast as I am concerned, easiest 
to maintain if I can model it as what it is - one large forest area 
called so-and-so. Not 5 simple polygons making up one forest.

> No, your solution does not solve the space issue problem. The 
> planet.osm file still wastes a lot of space for string's id. The 
> data structure still has 3 components (nodes, strings, ways) which 
> is difficult for converting, clipping, routing, and finding 
> shorttest way.

The planet file is a raw data transport file. It is not intended to 
be completely read by some auto-routing algorithm and then worked on; 
it is inteded to be converted into whatever format the application 
needs. For rendering, we have mapnik which uses a converted version 
of the planet file (in a PostGIS database, with no segments at all!). 
Routing can be done using the existing application "gosmore", which 
reformats and indexes a planet file into its own data format, 
throwing away everything that is not needed (a whole planet file in 
gosmore format needs 256 MB or so).

I am repeatng myself when I say that I, too, would like to wave 
goodbye to segments but I view this as cosmetics rather than as the 
huge obstacle for automatic data processing that you seem to make out.

> Please do not to tag address to segment. You can tag address to 
> node. The xml format of the node will be:
> 
>  > is belong to
> 
> 
> 
> 

The reason why some people tag addresses to segments is that they can 
specify house number ranges with sub-way granularity (e.g. "smallest 
number=40, largest number=80, even numbers only"). I don't like 
segments being used for this but tagging *every* *single* house 
number with a node of its own is not feasible so we have to find a 
good way for this.

Bye
Frederik

-- 
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'




       
---------------------------------
Building a website is a piece of cake. 
Yahoo! Small Business gives you all the tools to get online.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070727/18c2a777/attachment.html>