[gdal-dev] support for Czech Exchange Format for Land Consolidation

[Even Rouault]

Le mercredi 03 février 2016 23:24:07, Martin Landa a écrit :
> Hi,
> 
> 2015-04-17 12:26 GMT+02:00 Martin Landa <landa.martin at gmail.com>:
> >>> to the user, we could have a generic XML driver that would try several
> >>> XSLT documents and then feed the transformed document to the GML
> >>> driver. I don't
> >> 
> >> Anybody here is interested to implement such driver or at least to
> >> collaborate on such project?
> >> 
> >>> If you go with a from-the-scratch driver, I would not recommand to go
> >>> from the GML one which has become very complicated. GeoRSS or GPX are
> >>> probably better starting points.
> > 
> > it's seems to me that I will go this way (from-the-scratch driver).
> > Unfortunately I do not have enough time to start working on generic
> > driver first.
> 
> I am back with this topic again, I was thinking to use xsd2cpp way,
> but it seems to be not possible (or hardly possible) [1]. I was also
> thinking to design VFP driver classes as descendant of GML driver
> classes (I could basically write gfs file for VFP format). The
> difference would be how to read geometry, example:
> 
>       <par>
>         <pa parid="2402887611" vymo="291" vzd="296" cir="0" vymg="280.568">
>           <gpar>
>             <area>
>               <reg>
>                 <solid>
>                   <polygon xmlns:v="http://www.hsi.cz/vfp"
> xsi:type="v:linpol"> <segment xsi:type="v:se">
>                       <c x="1074884.94" y="610475.72" />
>                       <c x="1074902.12" y="610470.6" />
>                       <c x="1074875.22" y="610462.44" />
>                       <c x="1074873.4" y="610461.76" />
>                       <c x="1074861.4" y="610470.26" />
>                       <c x="1074862.21" y="610470.45" />
>                       <c x="1074884.94" y="610475.72" />
>                     </segment>
>                   </polygon>
>                 </solid>
>               </reg>
>               <t hod="60" vys="4.5" sir="5.5" j="33">
>                 <c x="1074877.99" y="610469.04" />
>               </t>
>             </area>
>           </gpar>
>           ...
>           </pa>
>         </par>
> 
> 
> But it doesn't seems to be a reasonable way. So I end up again with
> plan to write a special driver from scratch. Or is there any other way
> which I overlooked?

If it can be handled by the GML driver except for the geometries, you could 
probably add a special processing like done for AIXM ElevatedPoint. Have a 
look in ogr/ogrsf_frmts/gml/gmlhandler.cpp at :
- ParseAIXMElevationPoint() : transform a custom geometry format into standard 
GML
- where it is called : line 1498
- GMLHandler::IsGeometryElement()

> 
> Thanks, Martin
> 
> [1] http://codesynthesis.com/pipermail/xsd-users/2016-January/004755.html

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com