[OSM-dev] [Talk-GB] Motorway and Railway progress (simplifying OSM data)

Jon Burgess jburgess at uklinux.net
Sun Nov 5 23:54:45 GMT 2006


On Sun, 2006-11-05 at 12:43 +0100, Andreas Brauchli wrote:
> hey jon,
> 
> On Sat, 2006-11-04 at 23:42 +0000, Jon Burgess wrote:
> > Here is my initial attempt at a script to simplify an OSM file by
> > removing data which is invisible at high zoom levels. 
> [..]
> > is lost and corrupted during the simplification process (nodes are
> > aligned to the grid, segment endpoints are moved to the grid aligned
> > nodes etc).
> 
> in my osm2mp.php script (see OSM_Map_On_Garmin), the next step (once i
> get time to code again) is to add an abstraction function for higher
> zoom levels (garmin devices have several layers with different precision
> to reduce CPU-usage). this is where this comes in handy:
> 
> i like the implementation as it's adaptable to any grid-spacing-size..
> first step is going to find sane values for the different zoom-levels
> (layers).. have you done any tests on this?
> andreas
> 

Performing abstraction sounds like a separate feature although maybe
we'll end up with a whole library of different filtering tools (area,
simplify, abstraction, ...) which can be chained together. 

I haven't worked out a good simplification level for a given zoom level.
My intention was that the person running the script would figure out an
approximate level of detail which would be the order of 1 pixel in the
final rendered output. Should be easy to calculate if you can work out
the size in degrees divided by the size in pixels.

Another use though is just to shrink the data down to some manageable
quantity to process within a reasonable amount of time & memory. In this
case the level of detail can be tuned.

I processed an input file of 285MB which was planet.osm with the UK area
filter applied.

 Simplify(degrees)  File size 
 0.001              104MB
 0.01               15MB
 0.1                1.2MB

Perhaps an automated system could be produced to process a given area at
one zome level, then split he area into 4 files and process again at
half the feature size & then repeat several times. This should result in
all the output files being very roughly the same size to give more or
less constant rendering time at all zooms.


> what i had in mind was a different approach, but this is probably
> simpler..maybe i'll take a round function instead of (int) for
> roundings..
> 

I think int() generally shifts the output by half a grid square compared
to a proper rounding function (and the offset inverts over the +-0).
When I wrote the code I assumed that half a grid square would be too
small to care about, but maybe it would be worth the effort of doing it
properly since it seems the quantisation takes an insignificant part of
the overall processing.

	Jon





More information about the dev mailing list