[OSM-talk] Another point in support of ways as ordered lists

[Wollschaf]

On Wed, 20 Sep 2006 12:38:25 +0100, Nick Whitelegg wrote:
 
> - ways not being *ordered* lists of segments 
> - segments not all aligned in the same direction along a way

Wouldn't it be better to just postprocess the data to ensure certain
standards? I don't think it is a problem to distrubute a new type of
planet.osm that is processed, adding new information and reducing
hardware requirements on client applications.

A possibility to process the data:

- create "ways" of segments that are not included in a way, from
junction to junction, mark those with a tag
- split existing ways at junctions
- split existing ways where important properties of underlying segments
change (i.e. oneway, bridge, tunnel, ...)
- merge down oneway information from ways to segments - reorder segments
without oneway tag (in both existing and newly created ways) 
- compute length of all ways, include as tag
- filter and remove certain tags (created_by, for example)

Other useful processing might be:
- split planet.osm at degree boundaries (or even smaller areas); add new
nodes at the borders and split the segments and ways accordingly. 
- introduce layers to group ways into areas, roads, waterways... and
perhaps even make layers for each type of road to make map drawing at low
zoom levels faster.

The resulting dataset is then easier to use in both map rendering and
route planning applications...

A problem is to write a program that achieves this job fast and
without enormous ram requirements. If it takes longer than a day, it's too
slow ;)

Another problem is that certain tagging standards have to be met to
make use of advanced processing. 

The slippy map, on the other hand, could be based on this dataset to
reduce database load and to speed up tile rendering. IMO it's better to
have a fast map that is updated daily than a slower, but up-to-date
version.

Wollschaf