[rttopo-dev] Tolerance 0 support in master branch

[Andrea Peri]

(sorry my email was hard to understand due tomy poor english, and to smartphone)
So try to resend with some adjust:

Hi Alessandro.
You are reason.
But dont forget that rt-topology is an youger libraries and do some
change (without support previous version) to allow a robustness
beaviour now is reasonable.
Tolerance 0 is most clear associable to a no one kind of rounding
rather than to a dinamic tolerance (as is now).
I guess is no too heavy a change applied to test-suite moving from 0
to -1 actual settings.
Could do it myself ?

A.

2016-09-06 13:06 GMT+02:00 Andrea Peri <aperi2007 at gmail.com>:
> 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



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------