Hi Igor, thanks for your detailed explanations. Great to hear you were able to reproduce it and that you plan to address this issue.
> 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? I think your line of thought here sounds good. I am not sure whether other tools like the tile splitter need a bounding box or whether they can recreate it themselves. So in that sense, I am not sure whether "throwing away any bounds" is safe. Computing the union if all to-be-merged maps have a bounding box is elegant (and would be very useful for my purpose). In other cases, when any problematic issues with the bounds are expected, there should be at least warnings issued to the log. It'd be good to have some of this configurable as options and an output written about which bounding box is put into the output. A command line option to throw away and recompute the bounds would be good in some cases, to be on the safe side. I have no idea how expensive it is to recalculate. If it's put to the documentation that this is an expensive process, it could still be useful in some cases. You will know better about any implications or complexity of implementation. You may consider this rather a wish list. Any quick fix would already be great, again, thanks for your help, Dominik _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
