<div dir="ltr"><div><br></div>Hmm still I understand that you may want to have one and only parameter, and not a tolerance parameter build upon a precision parameter<div>If it was to be used set, what would you suggest as a mechanism?</div>
<div>Cheers,</div><div><br></div><div>Rémi-C</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/29 Rémi Cura <span dir="ltr"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Sandro ,<div>thanks for taking the time to answer =)</div><div><br></div><div><div>I feel we are talking about 2 different things :</div>
<div>you want a global tolerance policy for Postgis, so do I, <b>but this is not the purpose of this proposed change. (it would be very difficult anyway)</b><br>
<div>Here we just try to fix a broken numerical computation to cop with a double computing errors.</div><div><br></div><div>1. about tolerance : </div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>
with the precision change, the line won't move, it will "seem" wider to the ST_Split function, that's all (and it already has an implicit "width" anyway )</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>In perticular, the beginning and end of the segment won't change. (no translation! )</div></blockquote><div>2. about workaround dirty trick : </div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>I totally disagree. To cop with the split(line,line) precision issue, one would have to create a "big" cutting line out of the point, useless and not safe ( up to 9 digits??).</div></blockquote><div>3. about this broken split function : </div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>I don't see the point of keeping as is a function which has been proven to be broken. Either we fix it or we replace it ?</div></blockquote><div>
4. about example of precision : </div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>I give this example to give a feel of what 12 digits precision is. Everybody doesn't use meter, but everybody uses geographical information from real world. This examples are just examples to show that having such a precision is already precise enough for real world data (else, use CGAL, because there is no way to get better result with double computation).<br>
Also, the proposed change doesn't make the precision to 10^-12, but instead to 12 digits (thus totally independent of unity used).</div><div><br></div></blockquote>5. about a precision parameter :</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>(Sadly people don't seem much interested by this problem.)</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><br>For me the user could have a <b>tolerance</b> parameter , this is not what we are talking about.<br>
<br>Here this precision parameter would be much more low level, and not exposed to the user ! <br>The big difference is that when changing the precision of computing, it could create errors in further computing (example : in the beginning of split function, the point is supposed to be on the line, but then when the geos function tries to cut the line, the point is not on the line for geos, and it crashes).<br>
<br>It should be a constant, like the number of bits in an int or whatever.<br><br>What would you think of setting it at compilation time?<br>(something like "NUMERICFLAGS" )<br><br></blockquote>Cheers,<br>Rémi-C<br>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><br><br></blockquote></div><div><br></div><div><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/11/29 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Fri, Nov 29, 2013 at 10:48:54AM +0100, Rémi Cura wrote:<br>
> ST_Split(line,point) is currently broken.<br>
> This is quite a neutral statement, because given a random point on a random<br>
> line, split won't do anything (p_correct_answer<1/10k )!<br>
><br>
> The only work around I can think about are<br>
> _ snap the line to the point : it implies moving the line, which is not an<br>
> option if you do it several times with different points, and is more<br>
> abstractly a very bad idea<br>
<br>
</div>This is what you'd be doing anyway by implementing a tolerance.<br>
That is, the line would be moved anyway.<br>
<div><br>
> _ change the point to a very small line in the perpendicular direction of<br>
> the line we want to split, then use split(line,line). Again not a very good<br>
> option because you would possibiliy split the line in more than one point<br>
> (and anyway split(line,line) has also precision issues).<br>
<br>
</div>Still this is a legit options.<br>
<div><br>
> I understand PostGIS is a big project and we have to be conservative,<br>
> that is "we don't break a fine function with changes bringing unknown<br>
> consequences for unproven benefits",<br>
> but this function is broken, and we could change it to a function working<br>
> most of the time !<br>
<br>
</div>Yes, we could change it by accepting a tolerance value.<br>
What's wrong with that ?<br>
<br>
> *Pros of this change :*<br>
<div>><br>
> _a line will be split by a point correctly (p_error < 10^6)<br>
> _no heavy changes in code or methods<br>
><br>
</div>> *Cons of this change :*<br>
<div>><br>
> _the line would be split by any points close enough (lengthofline/10^12).<br>
> (that is all points less than 10 micro meters away from a line 1000 km long<br>
> !).<br>
<br>
</div>PostGIS doesn't deal with unit, so you don't know if those are<br>
micro meters or micro peta meters.<br>
You might be splitting a milli meter line by a point...<br>
<br>
All I'm saying is I'd like precision/tolerance to be _EXPLICIT_.<br>
Particularely important when you're about to run a _set_ of operations<br>
and you want them to be _consistent_ as per precision.<br>
<br>
> *I would also like adding ST_Split(geom,geom,tolerance).*<br>
<div>> In fact it could be an easy wrapper around ST_Split(geom,geom) if this<br>
> function was working. (something like: if the point is DWithin, split the<br>
> closest part of the line)<br>
<br>
</div>Please go ahead. Such a function would be accepted.<br>
<br>
NOTE: TopoGeo_addPoint does take a tolerane, and does use ST_Split after<br>
snapping the line to a DWithin point to implement it.<br>
Haing it available natively in C would speed that up.<br>
<br>
--strk;<br>
<br>
() ASCII ribbon campaign - against html e-mail<br>
/\ <a href="http://www.asciiribbon.org" target="_blank">http://www.asciiribbon.org</a> - against proprietary attachments<br>
<div><div>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>