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

[Dave Stubbs]

> <<<
> 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?
>

Because no-one has written one? Because the resources to provide this
aren't necessarily trivial? Because nobody with enough knowledge to do
it actually cares enough to do it? Because routing requires there be
uninterupted data from point to point which really wasn't there till
recently, making routing with osm data not very useful?

There's a hundred reasons why there isn't one already -- you can't
suddenly claim it must be because the data model isn't optimised for
it...

> <<<
> > 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!

With crappy lines... imagine the situation where you wish to draw a
building as a solid yellow with a brown border. You limit us to
"simple" polygons, and now we have nasty lines drawn through the
building rather than a nice solid object.

>
> <<<
> 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.

If you are developing anything to do with mapping, you're gonna have
to get your geometry text book out at some point.

>
> <<<
> 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?

My answer to this is fairly simple: so far the effort involved in
removing segments has clearly outweighed any benefits to be gained. I
say clearly because so far people have only ever talked about it.

TBH planet isn't *that* big, and doesn't take *that* long to process
given how much information it contains. I'm sure this will become more
of a need as time passes.