#4407 closed defect (fixed)
the GML HUGE resolver fails to identify <Egde> within <Face>
Reported by: | esseffe | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.9.0 |
Component: | OGR_SF | Version: | svn-trunk |
Severity: | normal | Keywords: | GML HUGE |
Cc: | a.furieri@… |
Description
I discovered that the current implementation of the GML HUGE resolver was unable to correctly recognize any <Edge> item declared internally to some <Face>
the attached patch resolves this issue: and BTW implements a simpler and most standard method to retrieve <Node> coordinates
Bye, Sandro Furieri
Attachments (3)
Change History (7)
by , 12 years ago
Attachment: | patch-edge-in-face.zip added |
---|
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Hi Even, thank a lot for your careful revision:
- I've added a test to ignore the result of GML2OGRGeometry_XMLNode() when NULL
- now poColl will be deleted when no longer required
- I've corrected the two typos related to Z coords settings for <Node>
anyway, your suggestion about not using <TopoCurve> doesn't seem to be valid; I've performed several tests, and the unique way to actually get the linestring geometry seems to be the one to wrap the <Edge> in a <TopoCurve><directedEdge>; passing directly an <Egde> or a <directedEdge> doesn't return any linestring geometry at all.
please see: patch-edge-in-face-2.diff
bye, Sandro
by , 12 years ago
Attachment: | patch-edge-in-face-2.diff added |
---|
comment:3 by , 12 years ago
Milestone: | → 1.9.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:4 by , 12 years ago
Attached simplified_gmlHugeFileNodeCoords.patch that avoids cloning the edge XML content and uses directly directedEdge as the wrapper level. The autotest still passes with it, but I haven't applied to avoid f*cking things at that point of the release process !
by , 12 years ago
Attachment: | simplified_gmlHugeFileNodeCoords.patch added |
---|
Several observations :