Some functions inject a bounding box to POINT geometries

[strk]

I've found that some functions result in points being equipped with a bounding box cache. I think this should be avoided by policy, shouldn't it ?

Example:

=# select st_summary(ST_FlipCoordinates('POINT(0 0)'));
Point[B]
=# select st_summary(ST_Reverse('POINT(0 0)'));
Point[B]
=# select st_summary(postgis_noop('POINT(0 0)'::geometry));
Point[B]

Actually I start thinking if _all_ the functions would be doing that…

Standard input functions, correctly, do not add a bbox cache:

=# select st_summary('POINT(0 0)'::geometry);
Point[]
=# select st_summary(st_geomfromtext('POINT(0 0)'));
Point[]

I've tested 1.5 and it is NOT affected. 2.0 branch is affected. I'm considering this high because grows the size of POINT layers by a big amount (48 bytes instead of 21 for a 2D point)

[strk]

2.1 and trunk (2.2) also affected

[pramsey]

Fix for this in trunk at r13302

[pramsey]

2.1 at r13304, 2.0 at r13305

[strk]

sfcgal version of tickets_expected also needs update (dunno why we have that duplication)

[strk]

 sfcgal/tickets .. failed (diff expected obtained: /tmp/pgis_reg/test_113_diff)
-----------------------------------------------------------------------------
--- sfcgal/tickets_expected     2015-03-04 18:28:21.195446506 +0100
+++ /tmp/pgis_reg/test_113_out  2015-03-05 19:01:49.646941614 +0100
@@ -201,9 +201,9 @@
 #1398a|POINT(-119.093153 45.632669)
 #1398b|POINT(-160.137654 77.091608)
 #1543|MULTILINESTRING((0 0,10 0,10 10,0 0),(0 0))|POLYGON((0 0,10 10,10 0,0 0))
-#1580.1|Point[BS]
+#1580.1|Point[S]
 ERROR:  transform: couldn't project point (180 90 0): tolerance condition error (-20)
-#1580.3|Point[BS]
+#1580.3|Point[S]
 #1596.1|public.road_pg.roads_geom SRID:3395 TYPE:POINT DIMS:2
 ERROR:  invalid SRID: 330000 not found in spatial_ref_sys
 #1596.3|3395
-----------------------------------------------------------------------------

[strk]

sfcgal tests fixed by r13317 in trunk (2.2.0) and r13318 in 2.1 branch (2.1.6)