[OSM-dev] Additions to Osmosis
siliconfiend at gmail.com
Tue Nov 6 01:18:30 GMT 2007
On 11/5/07, Brett Henderson <brett at bretth.com> wrote:
> Karl Newman wrote:
> > Brett, Dev:
> > I'm considering a few additions to Osmosis but I wanted to propose
> > them here first before I started working on them in case anyone had
> > any objections and/or guidance.
> No objections here, go for it.
> > 1. Add support for propagating the "bounds" element through the
> > pipeline. Most tasks would ignore it and pass it on, but certain tasks
> > (area filter, merge, etc.) would modify it. Probably the only consumer
> > for it (at this point) would be the write-xml task. The "bounds"
> > element is a sibling of node, way and relation in the osm XML. The
> > easy way to do it would be to include it as another entity type and
> > expand the EntityContainer/EntityProcessor framework, but that's
> > probably not strictly correct because "bounds" is not really an
> > entity. Alternative suggestions welcome (or if there's a good reason
> > not to do this at all, I'd like to know, too).
> I think you're planned approach of treating bounds elements as just
> another entity makes sense, I can't think of a better way to do it. Of
> your three osmosis additions, this is likely to be the messiest though.
> I'm not sure that the bounds element in its current form will be easy to
> support, polygons in particular will be tricky. It depends how precise
> you want the bounds elements to be.
Well, the way I have it planned it's behavior will be pretty
unsophisticated--if the input data has a bounds element, use it as the
starting point (for databases, maybe assume entire planet?) For
bounding boxes, just take the intersection of the existing bounds and
the bounding box. For polygons, I'd just use the enclosing rectangular
extents of the resultant Area. For merge operations, use the union of
the two bboxes.
> > 2. Add support for area filters which cross the 180th meridian
> > (Opposite of prime meridian; is that the subprime meridian?) Bounding
> > box is easy--just see if left > right, create 2 boxes which join at
> > +/- 180 degrees, and test both for node inclusion. Polygon is
> > substantially more complex--could be any number of sub-polygons which
> > join at +/- 180, depending how complex and "snaky" the polygon is
> > (i.e., how many times it crosses the 180th). One implicit assumption
> > here is that OSM coordinates will be in unprojected decimal degrees
> > (presumably WGS84). I don't know if that's a problem, but it does
> > impose a restriction that wasn't (strictly) present before.
> I didn't worry about any of this in the initial implementation because I
> didn't see the need for it. But if it's something you can use, then by
> all means implement it. One minor thing to be aware of is that the
> current implementation of bounding box is fairly lenient in its command
> line arguments, if left > right it automatically switches the arguments,
> this is something Marcus added fairly recently. If this breaks your
> implementation then it sounds reasonable to make them more strict again.
I don't strictly have a need for it, but I thought it would be good to
make the feature complete.
> It may be a good time to rename some of the command line arguments as
> well, currently it uses left, right, top and bottom, perhaps minLat,
> minLon, etc would be more appropriate. Whatever we choose should
> attempt to align with any defacto standards used elsewhere in OSM.
> Marcus was keen to see these arguments renamed because it's not very
> clear what type of arguments left, right, etc are.
> In summary, my initial implementation was very simple so any
> improvements are welcome.
Maybe east, west, north, south? I'm hesitant about "min" and "max" for
the very reason that the bounding box may span the 180th meridian,
where the coordinates of the "west" boundary would be greater than the
coordinates for the "east" boundary. It confuses the idea of min and
> > 3. This is a big one: Add a filter to match against a rules file
> > similar to the Osmarender rules (with probably a slight extension to
> > the syntax). Entities which match are passed on, otherwise dropped. I
> > want to have something like this for developing my Garmin GPSr
> > auto-routing map creator, and I thought it would be generally useful
> > as a library. In theory, you could use the same file for Osmosis (to
> > create a trimmed data set) and then for Osmarender or other target
> > app. Osmosis would just match against the "rule" elements and ignore
> > the "actions" (line, area, text, etc.) which Osmarender uses. I'm not
> > aware of anything written in Java to do this, but if anyone knows of
> > anything, please let me know. This one will take me a while, and I'll
> > probably need help from some expert Java architects to get it right.
> This could be quite useful.
I don't think I'll be able to get started on this one right away; I
just wanted to put it out there for comment.
> One final comment. If you do find yourself changing the behaviour of
> existing tasks, it may be worth creating new tasks instead.
How much change is tolerable before new tasks are required? The bounds
element should be a pretty simple change that most tasks will ignore
(defer to the base class). The 180th meridian addition would affect
the two area filter subclasses, and in the degenerate case would
collapse to the current behavior (maybe a strategy pattern would be
appropriate?). I'm not sure it would make sense to create new tasks in
that case, but if you think otherwise, that's fine. The rules filter
would certainly be a task of its own.
More information about the dev