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

[Frederik Ramm]

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:
> <node id = "1234" lat="..." lon="..."/>
> <way id = "123'/> <-- point to the road id that this node's addres  
> is belong to
> <tag k="HouseNumber", v="430"/>
> <tag k="PostalCode", v="123456"/>
> <tag k="Phone", v="23453-4567"/>
> </node>

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'