Opened 17 years ago
Closed 15 years ago
#287 closed defect (wontfix)
wrong type of the buffer of more than one geometries
Reported by: | carlshe | Owned by: | |
---|---|---|---|
Priority: | medium | Milestone: | |
Component: | Feature Service | Version: | 1.2.0 |
Severity: | major | Keywords: | Buffer MgPolygon MgMultiPolygon |
Cc: | External ID: |
Description
I selected many geometries, including points, lines and polygons, from 3 layers. and then I make a MgMultiGeometry based on the MgGeometryCollection of these selected geometries, and then I make a buffer of this MgMultiGeometry.
Theorectically, if these selected geometries are very close, the buffer geometry should be a single polygon, or else, the buffer might be a MgMultiPolygon.
But what I got is always a geometry of MgPolygon even though it is visually shown as many disconnected polygons.
I found this problem is because I need a spatialfilter to select geometries on the map. When I create a buffer, composed of many polygon, of selected geometries as the spatialfilter, I found only those geometried intersected with some a polygon of the buffer can be selected out.
I stepped into the code and found the generated buffer is really of type 'MgPolygon' but with data of 'MgMultiPolygon'.
Follow is part of the code:
MgGeometryCollection mgc = GetGeometryCollectionFromSelectionXML(SelectionXML);
if (mgc.Count > 0) {
MgGeometryFactory geomFactory = new MgGeometryFactory(); MgGeometry geo = null; if (mgc.Count == 1)
geo = mgc.GetItem(0);
else
geo = geomFactory.CreateMultiGeometry(mgc);
MgGeometry Buffer = geo.Buffer(dist, null); ......
}
Change History (4)
comment:1 by , 17 years ago
Summary: | wrong type of the buffer of more than one geometried → wrong type of the buffer of more than one geometries |
---|
comment:2 by , 17 years ago
Keywords: | MgPolygon MgMultiPolygon added |
---|
comment:3 by , 16 years ago
comment:4 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Old ticket; closing. If still a concern, please retest at version 2.1 and re-open.
Can you test this against 2.1 to see if this is still a problem, so that we can bump the version number?
A complete code example against the Sheboygan dataset would allow developers to re-create the problem quickly and would make a resolution more likely.