[OSM-dev] Additions to Osmosis

[Karl Newman]

On 11/5/07, Brett Henderson <brett at bretth.com> wrote:
> Karl Newman wrote:
> > 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.
> >
> It all depends on who's consuming these bounds tags.  If they're purely
> informational then your approach is fine.  If they're being used by
> downstream applications then that may change things.  Given that osmosis
> doesn't currently support them at all, your approach sounds like a good
> start.  If anybody screams later, then we can look at how to improve it.

Yes, generally informational. I may use it for my auto-routing
project, but I dunno. Just seems good to have "something". The current
usage of "bounds" in the OSM XML seems pretty squishy anyway, so I
doubt we'll get much complaints. In the case where the "completeWays"
option is used, the resultant file should be similar to what the API
will return (i.e., the "bounds" represent the requested area even
though there are nodes outside of it).

> >> 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
> > max.
> >
> I don't have a strong opinion on this one.  It's not important so we can
> worry about it later.  These arguments are one of the less confusing
> aspects of osmosis usage.

"Later" seems good. :-)

> >> 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.
> >
> I generally try to avoid two things:
> * Large numbers of fragile conditional statements in task logic.
> Primarily so I can understand the code a month later, but also because
> it tends to improve performance.
> * Breaking existing osmosis users.
>
> Neither have been a major issue up to this point.  In most cases where
> I've changed behaviour, I've added parameters to make the new behaviour
> optional (as you already have with the completeWays and
> completeRelations arguments to the area tasks).  For new functionality
> such as polygon support I refactored most of the existing bounding box
> task into a common parent class so they could share most of their
> functionality.
>
> In your case it sounds like you're improving existing behaviour so it
> probably makes sense to enhance existing tasks.  A strategy pattern is
> the way I was leaning with your earlier enhancement of the area filter
> tasks to make the behaviour runtime selectable, something similar to the
> way the sort tasks allow different orderings to be specified.  In the
> area filter case it seemed like a bit of work for no return so I didn't
> bother.  If the tasks get more complicated we can revisit it.  Do
> whatever you wish for now, the hard bit is getting something working,
> restructuring is usually fairly straightforward.

That's sort of the conclusion I came to as well. Eclipse helps a lot
with refactoring, too. Okay, I'll work on a patch or two.

Karl