Opened 15 years ago
Closed 6 years ago
#2643 closed defect (fixed)
Type 50 geometries in Personal Geodatabase not supported
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | 1.5.2 |
Severity: | normal | Keywords: | PGEO |
Cc: | MarkHirschi |
Description (last modified by )
Personal geodatabases such as CirTest.zip (http://trac.osgeo.org/gdal/attachment/ticket/1484/CirTest.zip) contain some type 50 geometries that are not supported by GDAL 1.5.3. This was originall reported in #1484 but this ticket attempts to focus on just the type 50 problems.
The CirTest.zip database has been exported to arcxml as http://trac.osgeo.org/gdal/attachment/ticket/1484/arcmap-export.tar.gz.
The first feature of the cirtest23 layer has a geometry looking like this in arc xml. Note that there is are circular segments. From this I deduce type 50 is a mixed linear/circular arc feature.
<Record xsi:type="esri:Record"> <Values xsi:type="esri:ArrayOfValue"> <Value xsi:type="xs:int">1</Value> <Value xsi:type="esri:PolylineN"> <HasID>false</HasID> <HasZ>false</HasZ> <HasM>false</HasM> <Extent xsi:type="esri:EnvelopeN"> <XMin>414020.298232866</XMin> <YMin>4818278.3328</YMin> <XMax>414080.9566</XMax> <YMax>4818351.5671</YMax> </Extent> <PathArray xsi:type="esri:ArrayOfPath"> <Path xsi:type="esri:Path"> <SegmentArray xsi:type="esri:ArrayOfSegment"> <Segment xsi:type="esri:Line"> <FromPoint xsi:type="esri:PointN"> <X>414080.9566</X> <Y>4818351.5671</Y> </FromPoint> <ToPoint xsi:type="esri:PointN"> <X>414080.7413</X> <Y>4818345.8198</Y> </ToPoint> </Segment> <Segment xsi:type="esri:Line"> <FromPoint xsi:type="esri:PointN"> <X>414080.7413</X> <Y>4818345.8198</Y> </FromPoint> <ToPoint xsi:type="esri:PointN"> <X>414079.5631</X> <Y>4818301.6407</Y> </ToPoint> </Segment> <Segment xsi:type="esri:Line"> <FromPoint xsi:type="esri:PointN"> <X>414079.5631</X> <Y>4818301.6407</Y> </FromPoint> <ToPoint xsi:type="esri:PointN"> <X>414023.1878</X> <Y>4818302.4311</Y> </ToPoint> </Segment> <Segment xsi:type="esri:CircularArc"> <FromPoint xsi:type="esri:PointN"> <X>414023.1878</X> <Y>4818302.4311</Y> </FromPoint> <ToPoint xsi:type="esri:PointN"> <X>414020.5711</X> <Y>4818282.6644</Y> </ToPoint> <CenterPoint xsi:type="esri:PointN"> <X>413932.82370523</X> <Y>4818304.33687855</Y> </CenterPoint> <IsCounterClockwise>false</IsCounterClockwise> <IsMinor>false</IsMinor> <IsLine>false</IsLine> </Segment> <Segment xsi:type="esri:CircularArc"> <FromPoint xsi:type="esri:PointN"> <X>414020.5711</X> <Y>4818282.6644</Y> </FromPoint> <ToPoint xsi:type="esri:PointN"> <X>414020.3014</X> <Y>4818278.3328</Y> </ToPoint> <CenterPoint xsi:type="esri:PointN"> <X>414048.439980051</X> <Y>4818278.75499348</Y> </CenterPoint> <IsCounterClockwise>true</IsCounterClockwise> <IsMinor>true</IsMinor> <IsLine>false</IsLine> </Segment> </SegmentArray> </Path> </PathArray> </Value> <Value xsi:type="xs:string">4B4-4</Value> <Value xsi:type="xs:short">0</Value> <Value xsi:type="xs:string">2</Value> <Value xsi:type="xs:float">12.5</Value> <Value xsi:type="xs:string">1/0A</Value> <Value xsi:type="xs:string">No</Value> <Value xsi:type="xs:string">UNKNOWN</Value> <Value xsi:type="xs:dateTime">2005-07-06T00:00:00</Value> <Value xsi:nil="true"/> <Value xsi:type="xs:short">1</Value> <Value xsi:nil="true"/> <Value xsi:nil="true"/> <Value xsi:type="xs:double">130.651080982852</Value> </Values> </Record>
Change History (7)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 by , 15 years ago
The above feature is represented like this in hex encoded binary.
32000020DDF463311145194160984C955961524150F38ED303461941CC5D4BE46B61524101000000 060000000000000050F38ED303461941CC5D4BE46B615241E05817F7024619416C9A77746A615241 50499D40FE451941923A01695F615241B0A44EC01C4519417424979B5F6152414070CE4812451941 948785AA5A615241A033A2341145194160984C9559615241020000000300000001000000821E6DB4 194519418DBB6C1E5D615241960000000400000001000000B10216691145194139313E205A615241 9E000000
The "treat as linestring" result from this is:
LINESTRING (414080.95660000015 4818351.5670999996,414080.74129999988 4818345.8198000006, 414079.56309999991 4818301.6406999994,414023.18780000042 4818302.4310999997, 414020.57110000029 4818282.6644000001,414020.30140000023 4818278.3328000009)
It is interesting to note that the binary data has 320 bytes of data from the start of the first vertex, but only 6*2*16=192 bytes of that is needed for the six vertexes of the linestring treatment. Presumably the remaining 128 bytes includes the centers of rotation for the two arcs (64 bytes) and the other information about direction of rotation and such.
comment:3 by , 15 years ago
I'm leaving off dealing with the circular arcs (which would presumably need to be stroked to linestrings) for the time being. The applied changes to treat as simple linestrings will at least get something going.
comment:4 by , 15 years ago
Cc: | added |
---|
follow-up: 6 comment:5 by , 9 years ago
I wonder if this issue got fixed by the work with curved geometries http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries
comment:6 by , 9 years ago
Replying to jratike80:
I wonder if this issue got fixed by the work with curved geometries http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries
No, although we would have now a way of addressing the curve parts
A preliminary simplistic interpretation of these geometries appears to be to treat them as simple 2D linestrings. I have incorporated the logic into trunk (r15662) and 1.5 branch (r15663). This at least gets something out but does not properly address the circular arc nature.