[OSM-dev] Osmosis bug when using 'completeWays' option?

Karl Newman siliconfiend at gmail.com
Sun Dec 2 22:26:55 GMT 2007


On Dec 2, 2007 10:29 AM, Lambertus <osm at na1400.info> wrote:
> ----- Original Message -----
> From: "Karl Newman" <siliconfiend at gmail.com>
> To: "Lambertus" <osm at na1400.info>
> Cc: <dev at openstreetmap.org>
> Sent: Sunday, December 02, 2007 17:22
> Subject: Re: [OSM-dev] Osmosis bug when using 'completeWays' option?
> >
> > I wrote the completeWays patch. Yes, it does do some buffering--it has
> > to keep all the nodes in order to make the ways (which come later)
> > complete. It writes it to a compressed (gz) temp file. I'm sorry, I
> > never tested it on a complete planet file.
> I guess it would work, but I just ran out of disk space without knowing why
> (behavior was quite different then expected). So that made me think it was a
> bug.

Look in your temp directory for files named "afnd...", "afwy..." and
"afrl..." (for Area Filter node, way and relation, respectively). They
should be .gz files (not sure if it creates that extension or not) and
can be deleted.

>
> > If you're working on a
> > particular area area, you might want to start with a simple bounding
> > box first (no completeWays) to limit the data that is buffered.
> Currently I'm working on a small area, but it will target the entire world.
> Maybe I need to split the world into a few sub areas first (e.g. Europe,
> North America, South America, Afrika and Asia) before cutting them into
> small pieces.

I should talk to Brett about making some sort of shared entity
cache/buffer that could be re-used by multiple downstream tasks, so in
the case of a "tee" with "completeWays" bounding boxes there would be
only one copy of all the entities instead of one set per tee.
>
> >
> > By the way, one of my future projects is to create a "tiling" task for
> > Osmosis which will do exactly what you are wanting.
> >
> That sounds great. Will it be able to split ways at the edges by adding a
> node on the edge or somesuch feature? Looking forward to this.

Well, since you're using it for Garmin GPS maps (as am I), my current
plan is to try to do some intelligent splitting of ways between tiles
(e.g., keep one way node past the boundary on the top and left side,
and none outside the boundary on the bottom and right side) instead of
creating a synthetic node. This is mostly a concern for routable ways,
because Garmin has a restriction on creating routing nodes too close
together (I think 5 meters?), so synthetic nodes created at the tile
boundary would be much more likely to create that situation. I may
make that an option, though.

Karl




More information about the dev mailing list