Hi Dominik, hi all,
> This bounding box only spans Finland. So the merged map takes the
bounding box of the first map in the merge command line? Would the
resulting map always get the bb of the first map in the merge command
line? Is that the intended behavior / documented somewhere?
I was able to reproduce this with the current Osmosis trunk. The root
cause is the handling of "bound" entities in --merge. Well, to be more
precise, it's _the complete abscence_ of any speical handling of bound
entities in --merge... ;)
So yes, the declared bounding box in the output of --merge (the <bound>
element in the resulting xml file) will be something from a single
upstream source. Which one it will be - well, that depends on the way
you write your command line (pipe connections) and on source streams
(whether they have an explicit declared bound set or not), so it will
not always be the first one.
In my understanding, this is a bug. I'll try to come up with a patch
over the next days. It's still worth discussing what would be the right
thing to do, though.
The simplest way would to just throw away the bound elements during a
merge. This is a "safe side" solution - we can't produce anything wrong
if we don't produce anything at all ;)
However, in some cases we could try to do better than that - if and only
if boths source streams have a bound set, the --merge could just make an
union of them and output it to the resulting stream.
In the "in between" (stream A has a bound declared but not stream B or
vice versa), the only sensible solution I can think of is to throw the
bounds away and not to output any. Otherwise, we would've had to compute
the missing bound, which is possibly slow and memory-hungry.
This shouldn't be that hard to be coded into EntityMerger.java, provided
this is the right thing to do in the first place. Am I missing something?
Greetings from Stuttgart,
Igor
_______________________________________________
osmosis-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/osmosis-dev
