[osmosis-dev] Merge command an resulting bounding box?

Igor Podolskiy igor.podolskiy at vwi-stuttgart.de
Mon May 2 12:53:56 BST 2011


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



More information about the osmosis-dev mailing list