On Sun, Jan 10, 2010 at 9:41 PM, Brett Henderson <br...@bretth.com> wrote:
> On Sat, Jan 9, 2010 at 9:15 PM, Frederik Ramm <frede...@remote.org> wrote: > >> Hi, >> >> consider this test case (run with 0.31.3): >> >> <osm version="0.6"> >> <node id="1" version="1" timestamp="2007-10-31T23:48:54Z" uid="1" >> user="fred" changeset="1" lat="53" lon="10"/> >> <node id="2" version="1" timestamp="2008-09-28T17:44:53Z" uid="1" >> user="fred" changeset="1" lat="54" lon="10" /> >> <node id="3" version="1" timestamp="2008-09-28T17:44:53Z" uid="1" >> user="fred" changeset="1" lat="55" lon="10" /> >> <relation id="1" version="1" timestamp="2005-07-05T02:14:07Z" >> uid="1" user="fred" changeset="1"> >> <member type="node" role="" ref="1" /> >> <member type="node" role="" ref="2" /> >> </relation> >> <relation id="2" version="1" timestamp="2005-07-05T02:14:07Z" >> uid="1" user="fred" changeset="1"> >> <member type="node" role="" ref="3" /> >> </relation> >> </osm> >> >> Cutting out from this a bbox that only contains node #1, such as >> >> osmosis --rx test.osm --bb left=1 right=90 top=53.5 bottom=52.5 --wx - >> >> one would expect to find in the output: >> >> * without extra flags: node #1, relation #1 referring to nodes #1,#2 >> >> --> pass >> >> * with clipIncompleteEntities: node #1, relation #1 refering to node #1 >> >> --> pass >> >> * with completeRelations: nodes #1,#2, relation #1 referring to both >> >> --> fail; instead, you get node #1 only, but relations #1 and #2. >> >> It seems that completeRelations always acts as "copy all relations from >> input to output no matter what" and has no influence on handling nodes >> and ways. Re-writing the same example to use ways, and the trying it >> with completeWays=true, yields the expected result. >> >> The Wiki documentation on completeRelations says: >> >> "Include all available relations which are members of relations which >> have at least one member in the bounding polygon." >> >> This describes neither the behaviour I had expected, nor the behaviour I >> have observed. I believe the intended behaviour is really "Include all >> available *objects* ..."- no? >> > > My expectation is much the same as yours. I have no idea what's going on > there. I'll check it out when I get time. If you have the time to patch it > to give you the expected behaviour I'd appreciate it. > > Thanks for the detailed example, that should make it much easier to debug > :-) > > Brett > > It's taken me a couple of months to get back to this, but I've checked in some changes which I *think* have fixed the problem. It seems to work on your example anyway. It turned out to be a bigger change than I expected. I've pretty much re-written all of the completeWays and completeRelations functionality. One side effect is that completeRelations now switches on completeWays as well which isn't strictly necessary but made the implementation somewhat simpler. The completeRelations behaviour will be slower than before, but given that it never worked before this isn't necessarily a bad thing. One reason for extra slowness is that it now has to read through all of the ways after all of the relations have been selected in order to select all additional nodes. A second reason for extra slowness is that it makes multiple passes through all of the relations until all recursive relations are selected. If you're being evil, it is possible to craft deeply recursive relations in an order that requires a large number of passes (one per level of recursion). Beware careful when switching on completeRelations. Depending how crazy mappers have been with defining huge grouping relations, it is possible to end up selecting half of the map. Hopefully this isn't the case in practice. Let me know if you see any problems with the new implementation. Brett
_______________________________________________ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
