Subject: [ggl] Point/Box in Box Test (Border Cases - 3D)
From: Frank Glinka (glinkaf)
Date: 2011-07-07 10:03:05
Amendment to my previous mail:
It seems the 'within_code' function returns a different result than
intersects or my custom implementation of coveredBy although I wouldn't
have expected this.
Probably even worse: 'within' now has a different behavior compared to
the previous version (before you moved the within_code code).
This happens with the micro benchmark and a batch_size of 100000000 with
10 iterations. Strange - I have no ad hoc idea yet.
Am 07.07.2011 11:48, schrieb Frank Glinka:
> Hi Barend!
> Am 03.07.2011 16:36, schrieb Barend Gehrels:
>> Hi Frank,
>> I updated the trunk, and moved the within_code from within_util to
> Thank you Barend! I used it and it works as described/expected. A thing
> I should notice is that the performance of the original 'within'
> implementation is negatively impacted by this change.
> I attached my basic ad-hoc micro-benchmark if you are interested in
> doing your own shot. Results with VS2010 in x86 Release and /O2 (run on
> Core 2 Duo 2.4 GHz):
> Run with old within: 5.72521s
> Run with updated within: 23.2128s
> Run with within_code: 25.2096s
> Run with intersects: 6.86401s
> Run with custom coveredBy: 4.29001s (based on outside (>) check solely)
> As the difference is quite significant, it might be a thought to
> consider providing specialized implementations of 'within' and
> 'coveredBy' instead of using the 'outside, onBorder, inside' predicate
> as an abstraction in both versions.
>> It stays in namespace detail until there is complete agreement on the
>> interface (parameter, strategy, function name), so maybe you will have
>> to rename something in the future, but the functionality is there. I now
>> believe that it is the best to adapt to PostGIS and Oracle here, they
>> call it "coveredBy". See
>> defining it as "Returns 1 (TRUE) if no point in Geometry A is outside
>> GeometryB", which is what I described. So covered_by would be a
>> convenient and (I think) intuitive name.
> I like that name and staying compliant to established terms is always
> good. I guess you noticed that this specification would allow for a
> simpler implementation than currently provided by within_code!? (Which
> is able to distinguish between 'inside' and 'on border' while the
> specification only requires 'on border' - which probably causes the
> previously mentioned performance overhead.)
> Best regards,
> ggl mailing list
Geometry list run by mateusz at loskot.net