[osmosis-dev] question about --merge

Brett Henderson brett at bretth.com
Wed May 19 12:42:16 BST 2010


On Wed, May 19, 2010 at 4:29 AM, Christoph Wagner <
freemaps.osm at googlemail.com> wrote:

> Am 18.05.2010 15:18, schrieb Brett Henderson:
>
> > To summarise, if you can draw a graph of the data flows in Osmosis,
> ensure
> > that you never have data being split then recombined at a later point.
> >
> > In your case the only option is to split it into two steps using
> temporary
> > XML files as you already appear to be doing.
> >
> > It would be nice if Osmosis could detect this situation and throw an
> error,
> > but it would take a lot of effort and add a lot of complexity that I
> don't
> > really wish to attempt.
>
>
>
> Ok, thanks for your reply. I think now I understand the situation better.
>
> While reading your answer I got an idea to solve the problem without
> writing to disk.
>
> I use a very big buffer now:
>
> osmosis-0.35.1/bin/osmosis --rx input.osm --t outPipe.1=points \
> --wk keyList="addr:interpolation,addr:housenumber" --un --s --b 100000000 \
> --nk inPipe.0=points keyList="addr:housenumber" --s --b 100000000 \
> --m --wx addr.osm
>
> This works very well if you have enough RAM and set the bufferCapacity high
> enough.
>

Yes, that will also work if you're prepared to experiment a bit with buffer
sizes.


> Another possibility would be a better tagfilter that allows me to filter
> POIs and ways at once.
> The task would be for example: "Give me all ways that match this way-filter
> and all nodes that match this node-filter or are part of the way that
> matches the way-filter"
>

The --tag-filter task is about the most comprehensive task currently
available.  To add a full boolean expression language is certainly possible,
but not trivial.  If somebody wants to take on the challenge of creating a
complex yet generic tag analysis task then I'll do my best to help them
out.  I'll be honest though, it's not likely to be something I'll get around
to implementing myself.

Thinking about your case a bit more, you could avoid the temp file if you
simply read the input file twice so you avoid the --tee.  Although that
might be slower than creating a temp file and invoking Osmosis twice.  If it
was me I'd simply create a wrapper shell script to tie several osmosis
commands together and do some checking of the Osmosis return code to ensure
it hasn't failed at each step.  The --buffer approach might work, but the
memory consumption is likely to bite you at some point.

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20100519/144a0098/attachment.html>


More information about the osmosis-dev mailing list