<p dir="ltr">Hi Alessandro.<br>
You are reason.<br>
But dont forget that rt-topology is an eatly libraries and some change to allow a robustness beaviour now is reasonable.<br>
Tolerance 0 is most clear associate to a now rounding rather than a dinamic tolerance.<br>
I guess is no heavy change move actually testsuite from 0 to -1 values.<br>
Coul do it myself ?<br>
</p>
<div class="gmail_extra"><br><div class="gmail_quote">Il 06 set 2016 12:55,  <<a href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 6 Sep 2016 11:48:30 +0200, Sandro Santilli wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've changed the semantic of tolerance parameter value 0<br>
from "automatic" to "zero", and added support for value -1<br>
to mean "automatic".<br>
<br>
This basically adds support for really specifying 0 as<br>
the tolerance value, which would result in no snapping<br>
ever occurring.<br>
<br>
With this change, I tried the spatialite testsuite (check_topology2d)<br>
and got a failure:<br>
<br>
 rtt_AddIsoNode failed TopoGeo_AddLineString() #1 error:<br>
rtt_AddIsoNode failed<br>
<br>
The failure isn't there if I revert the librttopo change.<br>
<br>
Alessandro: could you help reducing the testcase to figure out<br>
what's going on ? Spatialite is the only existing testsuite<br>
for librttopo...<br>
<br>
</blockquote>
<br>
Hi strk,<br>
<br>
introducing sudden changes affecting the very basic interpretation<br>
of some API argument never is a good policy and could easily<br>
cause unexpected troubles.<br>
<br>
now we have two different implementations of rttopo (depending on<br>
version) returning incompatible results from a call with identical<br>
arguments, and this will easily cause some trouble to the testsuite<br>
that is expecting a consistent behavior from the library API<br>
independently from the specific version being currently linked.<br>
<br>
if possible it would be a better choice always leaving an already<br>
existing API unaffected by any subsequent radical change, then adding<br>
a new API with a different name implementing the new behavior as e.g.<br>
rtt_AddIsoNode2() or rtt_AddIsoNodeEx()<br>
<br>
this will greatly help to ensure a robust cross-version compatibility<br>
and will prevent many unexpected failures; and will obviously<br>
facilitate maintaining a testsuite safely supporting more than a<br>
single specific version of RTTOPO.<br>
<br>
bye Sandro<br>
______________________________<wbr>_________________<br>
librttopo-dev mailing list<br>
<a href="mailto:librttopo-dev@lists.osgeo.org" target="_blank">librttopo-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/librttopo-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/librttopo-dev</a><br>
</blockquote></div></div>