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:  |
+---

Comment (by dbaston):

 Hi strk, I probably expressed myself poorly. I don't think the C API
 should modify the GeometryFactory.

 Because it is not possible to manipulate a GeometryFactory in the C API, I
 think that the C API should set the SRID of the output geometries (after
 they are created) to match the SRID of the inputs.

 I don't think we should try to retrofit GeometryFactories into the C API.

-- 
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

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:  |
+---

Comment (by strk):

 I don't think GeometryFactory should be affected by GEOSGeom_setSRID.
 JTS also doesn't set SRID of output geometry from operations, I wonder
 what Martin Davis thinks about this.

 I'm +0 with adding SRID propagation in C-API (as I guess as of now
 all clients are already doing this in their converters)

-- 
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

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:  |
+---

Comment (by robe):

 I've got no objections.  I don't even have objections if you want to back
 port to 3.6, 3.5 as it does sound like a bug.

-- 
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

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:  |
+---

Comment (by dbaston):

 It looks like the problem is unique to the C API, and affects all
 functions that produce a geometry as an output.

 When a GEOS Geometry is created, it is given the SRID of its
 GeometryFactory. However, the C API does not use the concept of a
 GeometryFactory and provides no access to it. When the C API function
 GEOSSetSRID is called, it sets the SRID of an individual geometry, but
 leaves the GeometryFactory untouched.

 Any objections to resolving this at the C API level, by setting the SRID
 of created geometries to match their inputs?

-- 
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

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:  |
+---

Comment (by dbaston):

 No, I didn't check intersection or union. I started writing unit tests for
 this, and then it occurred to me that maybe this wasn't considered a bug.
 If there's agreement that it's a bug, I can go ahead with tests and fixes
 for all functions.

-- 
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

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:  |
+---

Comment (by strk):

 Did you check what do Intersection/Union do ?
 I suspect OffsetCurve is just behind as being
 original  code (rather than direct JTS port)

-- 
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

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