<div dir="ltr"><div>So, with the last two commits</div><div><br></div><span style="font-size:10pt;font-family:Arial;font-style:normal;text-align:center"><span style="font-size:10pt;font-family:Arial;font-style:normal;text-decoration:underline;color:rgb(17,85,204)"><a class="gmail-in-cell-link" href="https://github.com/libgeos/geos/commit/aaafcce2" target="_blank">https://github.com/libgeos/geos/commit/aaafcce2</a><br></span></span><div><span style="font-size:10pt;font-family:Arial;font-style:normal;text-decoration:underline;color:rgb(17,85,204)"><a class="gmail-in-cell-link" href="https://github.com/pramsey/geos/commit/8e340a77322445669bbffc5d6b9bf4d01b676a5a" target="_blank">https://github.com/pramsey/geos/commit/8e340a77322445669bbffc5d6b9bf4d01b676a5a</a></span></div><div><br></div><div>We (haha, mostly Martin) have restored the old Linstring.Union() behaviour (node-to-node lines extracted from graph) and the old Geometry.Intersection() behaviour (all dimensional components extracted from graph into GeometryCollection). <br></div><div><br></div><div>This should substantially reduce the number of regression issues when building with the NG overlay turned on. As before I haven't actually tested this myself yet, it's the end of the day, but I have high hopes.<br></div><div><br></div><div>We still have the known regression that Z values aren't going to be added/preserved in 2d/3d and 3d/3d overlays.<br></div><div><br></div><div>Thank you Andrew Bell for the fixes to master to pass MSVC builds now too.</div><div><br></div><div>Next week, continued testing on regressions from me. Martin is away.<br></div><div><br><span style="font-size:10pt;font-family:Arial;font-style:normal;text-decoration:underline;color:rgb(17,85,204)"></span><span style="font-size:10pt;font-family:Arial;font-style:normal;text-align:center"><span style="font-size:10pt;font-family:Arial;font-style:normal;text-decoration:underline;color:rgb(17,85,204)"></span></span></div><div>P.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 1:47 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here's a spreadsheet... <br>
<br>
<a href="https://docs.google.com/spreadsheets/d/15Jk5cNuYdxPPA9fXIxCreRJNlkQZjc2KdYaX-odW8So/edit#gid=936876052" rel="noreferrer" target="_blank">https://docs.google.com/spreadsheets/d/15Jk5cNuYdxPPA9fXIxCreRJNlkQZjc2KdYaX-odW8So/edit#gid=936876052</a><br>
<br>
It's probably not complete, but it's got the big entries... <br>
<br>
> On Aug 6, 2020, at 1:08 PM, Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>> wrote:<br>
> <br>
> On Thu, Jul 30, 2020 at 06:04:11PM -0700, Paul Ramsey wrote:<br>
> <br>
>> On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function. <br>
>> <br>
>> My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.<br>
> <br>
> Do you have an updated list of tasks to complete to get backward<br>
> compatibility in place ? I probably have the possibility to work<br>
> on some of them.<br>
> <br>
> --strk;<br>
> _______________________________________________<br>
> geos-devel mailing list<br>
> <a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
<br>
</blockquote></div>