Ok, I understand the strictness but what makes me confused if the mixed
policy about standards.
For example:
PostGIS 1.5 -> ST_StartPoint and ST_Endoints with Multi types are
working (against SQL/MM)
PostGIS 2.0 -> ST_StartPoint and ST_Endoints with Multi types return
null (folllow SQL/MM)
PostGIS 1.5 -> ST_GeometryN (geom, 1) with simple types returns null
(folllow SQL/MM)
PostGIS 2.0 -> ST_GeometryN (geom, 1) with simple types are working
(against SQL/MM)
In some cases it follows the standards but in other cases it follows the
usability.
There are more examples but I cant remember now... I think LRS functions
do not allow using Multi types with just one geometry either.
Of course we users can fix it using ST_Multi or ST_GeomeryN (geom, 1)
but I think its waste of time, code and performance. If we have to
sacrifice that because of the standards then its ok but in that case the
above example (mixed standards policy) does not make sense for me.
Regards,
On 24/11/2011 16:30, Paul Ramsey wrote:
It's strictness. Not sure how much I like it, but that's been the
behavior for quite a while.
P.
On Thu, Nov 24, 2011 at 5:39 AM, Jose Carlos Martinez
<[email protected]> wrote:
HI,
p2211=# select st_startpoint ('MULTILINESTRING ((0 0, 10 0))');
st_startpoint
---------------
(1 row)
returns null, according to SQL/MM ST_StartPoint is working with ST_Curve,
this is ok. But I do not think its practical, besides previous versions of
PostGIS returned the first point correctly.
Is this a bug or PostGIS is trying to follow standards in a more strict way?
same with st_endpoint.
Cheers,
PD:
p2211=# select postgis_lib_build_date(), postgis_full_Version();
postgis_lib_build_date |
postgis_full_version
------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------
2011-11-22 08:39:41 | POSTGIS="2.0.0SVN" GEOS="3.3.2dev-CAPI-1.7.2"
PROJ="Rel. 4.6.1, 21 August 2008" GDAL="GDAL 1.9dev, released 2011/01/18"
LIBXML="2.7.8" USE_STATS
(1 fila)
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
