[rttopo-dev] Tolerance 0 support in master branch

[Andrea Peri]

Hi Alessandro.
You are reason.
But dont forget that rt-topology is an eatly libraries and some change to
allow a robustness beaviour now is reasonable.
Tolerance 0 is most clear associate to a now rounding rather than a dinamic
tolerance.
I guess is no heavy change move actually testsuite from 0 to -1 values.
Coul do it myself ?

Il 06 set 2016 12:55, <a.furieri at lqt.it> ha scritto:

> On Tue, 6 Sep 2016 11:48:30 +0200, Sandro Santilli wrote:
>
>> I've changed the semantic of tolerance parameter value 0
>> from "automatic" to "zero", and added support for value -1
>> to mean "automatic".
>>
>> This basically adds support for really specifying 0 as
>> the tolerance value, which would result in no snapping
>> ever occurring.
>>
>> With this change, I tried the spatialite testsuite (check_topology2d)
>> and got a failure:
>>
>>  rtt_AddIsoNode failed TopoGeo_AddLineString() #1 error:
>> rtt_AddIsoNode failed
>>
>> The failure isn't there if I revert the librttopo change.
>>
>> Alessandro: could you help reducing the testcase to figure out
>> what's going on ? Spatialite is the only existing testsuite
>> for librttopo...
>>
>>
> Hi strk,
>
> introducing sudden changes affecting the very basic interpretation
> of some API argument never is a good policy and could easily
> cause unexpected troubles.
>
> now we have two different implementations of rttopo (depending on
> version) returning incompatible results from a call with identical
> arguments, and this will easily cause some trouble to the testsuite
> that is expecting a consistent behavior from the library API
> independently from the specific version being currently linked.
>
> if possible it would be a better choice always leaving an already
> existing API unaffected by any subsequent radical change, then adding
> a new API with a different name implementing the new behavior as e.g.
> rtt_AddIsoNode2() or rtt_AddIsoNodeEx()
>
> this will greatly help to ensure a robust cross-version compatibility
> and will prevent many unexpected failures; and will obviously
> facilitate maintaining a testsuite safely supporting more than a
> single specific version of RTTOPO.
>
> bye Sandro
> _______________________________________________
> librttopo-dev mailing list
> librttopo-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/librttopo-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/librttopo-dev/attachments/20160906/c50e0de1/attachment.html>