[OSM-talk] Osmosis and large bounding polygons

[Jeremy Adams]

Thanks for taking the time to write this.  I tried running it on the 
united_states2pts.txt from maproom, which is 3.4MB and I'm getting 
suspiciously small files as the output.  I've tried some combinations of the 
three options you outlined and the largest file I've seen so far is 200KB as 
output.

I ran it with just the --percent=80, which as I understand your email will 
drop 20% of the nodes in the polygon and I ended up with only a 180KB file.

Also, I see lots of messages like the one below as it processes the file:

    "Use of uninitialized value in subtraction (-) at 
.usr.lib.perl5/Math/Polygon/Transform.pm line 220, <> line 59834."  These 
line numbers seem to correlate with the END statements in the polygon file. 
Is this expected?

-Jeremy

----- Original Message ----- 
From: "Frederik Ramm" <frederik at remote.org>
To: "Milenko" <milenko at king-nerd.com>
Cc: <talk at openstreetmap.org>
Sent: Tuesday, January 08, 2008 8:50 PM
Subject: Re: [OSM-talk] Osmosis and large bounding polygons


Hi,

> Is there any easy way to edit these polygon files?  They're basically just
> a list of lat and lon values I think, but it'll take forever to edit one
> of that size by hand.

I have just commited a simple utility that allows simplification of
polygon files, based on the perl module Math::Polygon:

/applications/utils/osm-extract/polygons/simplify-poly.pl

It takes a polygon file on stdin (or give name on cmdline) and writes
to stdout. There are three modes of simplification which may be
combined:

--percent=10

will simply drop 90% of nodes in the polygon, first those with the
biggest angles (i.e. those carrying least information).

--slope=0.01

will compute the partial polygon circumference between any three
consecutive nodes and drop the middle node if that reduces the
circumference by less than the given number.

--same=0.01

will drop any node that lies within 0.01 length units of a
neighbouring node.

Note that length units are just degrees, i.e. at the equator one unit
is 60 miles but that becomes distorted towards the poles. The angle
computation upon which the --percent operation is based doesn't take
the spherical earth into account either so it is all quite flawed but
it should be sufficient for boiling down the number of points in your
polygon a bit.

A better way to do this would be using the algorithms I nicked from
GPSBabel and implemented in the "simplify way" code for JOSM but I'm
not in a mood to perlify them atm.

Bye
Frederik

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


_______________________________________________
talk mailing list
talk at openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk