[OSM-dev] Osmosis --ac changed?

Karl Newman siliconfiend at gmail.com
Mon Dec 22 03:58:24 GMT 2008

On Sun, Dec 21, 2008 at 4:32 PM, Brett Henderson <brett at bretth.com> wrote:

> Jochen Topf wrote:
> > On Mon, Dec 22, 2008 at 10:03:58AM +1100, Brett Henderson wrote:
> >
> >> So the stack based approach is more flexible, but takes a few more
> >> mental gymnastics to get it right.  To be honest I haven't found it too
> >> bad one I got used to it.
> >>
> >
> > One problem seems to be that the command line is inherently linear and
> > its getting longer and longer with more and more options. Maybe we have
> > to get away from it and have some kind of command file. At least
> > optionally.
> >
> It shouldn't be difficult to load tasks from a file.  I could create a
> new single hyphen option that specifies the name of a file to load the
> configuration from.
> The only thing I'm wary of doing is creating another programming
> language.  So far the command line implementation has been easy to
> maintain and bug free.
> > The command file can use a different syntax that somehow shows better
> > what it will do. I don't know how this should look, but in a file there
> > are "two dimensions" instead of only one, so that could help there.
> >
> Most of my osmosis usage is fairly simple so I'm not well placed to come
> up with a good solution here.  If you have some ideas I'm happy to take
> a look.
> Brett

I like the stack-based options. It reminds me of Reverse Polish Notation on
my HP 48G (which was sadly lost). I don't think the problem is with the
stack notation itself, but just with how the change affected the semantics
of the apply-change task (and maybe other tasks that take streams of
different types). That was what I was referring to when I suggested it may
be too disruptive to change (by change I meant reverse the order of the
arguments to the apply-change task, not change back to a queue system).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081221/540e29e5/attachment.html>

More information about the dev mailing list