[OSM-dev] Additions to Osmosis

[Brett Henderson]

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.
> 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.

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.
> 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.

One final comment.  If you do find yourself changing the behaviour of 
existing tasks, it may be worth creating new tasks instead.

Cheers,
Brett