Re: [geos-devel] [GEOS] #896: Many (all?) GEOS operations do not preserve SRID

[GEOS]

#896: Many (all?) GEOS operations do not preserve SRID
+---
 Reporter:  dbaston |   Owner:  geos-devel@…
 Type:  defect  |  Status:  new
 Priority:  major   |   Milestone:  3.7.0
Component:  Default | Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:  |
+---
Changes (by robe):

 * milestone:  3.6.3 => 3.7.0


Comment:

 I would agree, but I think this would constitute a policy change so can't
 go in 3.6.3.

 Could go in 3.7.0 even though we've called beta since it's not really an
 api change.

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] [GEOS] #896: Many (all?) GEOS operations do not preserve SRID

[GEOS]

#896: Many (all?) GEOS operations do not preserve SRID
+--
 Reporter:  dbaston |  Owner:  geos-devel@…
 Type:  defect  | Status:  new
 Priority:  major   |  Milestone:  3.6.3
Component:  Default |Version:  3.6.2
 Severity:  Unassigned  |   Keywords:
+--
 For example, the following test fails:

 {{{
 void object::test<11>()
 {
 geom1_ = GEOSGeomFromWKT("LINESTRING(0 0, 10 0)");
 GEOSSetSRID(geom1_, 32145);

 geom2_ = GEOSOffsetCurve(geom1_, 2, 0, GEOSBUF_JOIN_ROUND, 2);

 ensure_equals( GEOSGetSRID(geom1_), GEOSGetSRID(geom2_) );
 }

 }}}

 It's obvious that SRID could be preserved here. For binary operations, I'd
 say that it's not the job of GEOS to check SRID consistency, and that the
 result could have the SRID of the first argument.

 Any thoughts about this?

-- 
Ticket URL: 
GEOS 
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite 
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel