There were actually two bugs. One was when the line that intersects itself
the intersection point treated as it doesn't belong to the line.
Second when edges partly coincide, wrong result produced when we try to find their
intersection.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
test case added.
sql/gcalc_slicescan.cc
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
skip the intersection if it just line that intersects itself.
sql/gcalc_tools.cc
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
if edges coincide, just pick the first coinciding poing as an intersection.
That crash happened with the complicated topology of the result.
If we found a hole in a polygon whose outside border was already
found, we need to paste the hole right after it and respectively
shift polygons after it. Also we need to update poly_position fields
in these polygons. That last thing wasn't properly done that led to the
crash.
To fix that we keep the list of the found polygons and update the
poly_positions that are bigger or equal to where we placed the next hole.
per-file comments:
mysql-test/r/gis-precise.result
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
test result updated.
mysql-test/t/gis-precise.test
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
test result added.
sql/gcalc_tools.cc
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
keep the list of the found polygons and update their poly_position fields respectively.
sql/gcalc_tools.h
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
Gcalc_result_receiver::move_hole interface changed.
The ::val_str() method has to return NULL if it calculated
the null_value, not just set the related flag.
per-file comments:
mysql-test/r/gis-precise.result
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
test result updated.
mysql-test/t/gis-precise.test
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
test case added.
sql/item_geofunc.cc
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
return NULL from the val_str if we get the null_value.
Collections were treated mistakenly, so the counter for the final UNION operation
received the wrong value.
As a fix we implement Item_func_buffer::Transporter::start_collection() method,
where we set the proper operation and the operand counter.
start_poly() and start_line() were also modified to function correctly for the
polygon as a part of a collection.
per-file comments:
mysql-test/r/gis-precise.result
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
test result updated.
mysql-test/t/gis-precise.test
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
test case added.
sql/item_geofunc.cc
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
start_collection() implemented.
sql/item_geofunc.h
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
Item_func_buffer::Transporter::start_collection() defined.
Internal caclucations can't handle zero distance properly.
As the ST_BUFFER(geom, 0) is in fact NOOP, we'll just return the
'geom' as the result here.
per-file comments:
mysql-test/r/gis-precise.result
fix for bug #201189 ST_BUFFER asserts if radius = 0.
test result updated.
mysql-test/t/gis-precise.test
fix for bug #201189 ST_BUFFER asserts if radius = 0.
test case added.
sql/item_geofunc.cc
fix for bug #201189 ST_BUFFER asserts if radius = 0.
return the first argument as the result of the ST_BUFFER, if
the distance is 0 there.
If the result contains a polygon with a hole, consequitive shapes weren't calculated
properly, as the hole appeared as shape in the result, but actually it's a single shape
with the surrounding polygon. It's more natural to use the size of the result as
a border instead of the number of resulting shapes.
per-file comments:
mysql-test/r/gis-precise.result
fix for bug #801243 Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION
test result updated.
mysql-test/t/gis-precise.test
fix for bug #801243 Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION
test case added.
sql/spatial.cc
fix for bug #801243 Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION
check the data lenght instead of number of shapes.
sql/spatial.h
fix for bug #801243 Assertion `(0)' failed in Gis_geometry_collection::init_from_opresult on ST_UNION
check the data lenght instead of number of shapes.
