[gdal-dev] GML / NAS code redundancy

Even Rouault even.rouault at mines-paris.org
Tue Mar 18 08:35:13 PDT 2014


Martin,

Yes I agree that there's code duplication, and some of it could have been
avoided. I guess this was to avoid to make the GML driver too dirty with NAS
stuff, or regress.
Personnaly  I've hacked a lot in the GML driver over the past few years to add
support for various application schemas and well, yes, it has gotten a bit
messy. But I've also added recently generic stuff which should make support for
some categories of application schemas easier. See the "Registry for GML
application schemas" paragraph of http://gdal.org/ogr/drv_gml.html. Perhaps your
use case could fit into that.

Even

> Hi all,
>
> recently I started to write a new OGR driver for specific national
> exchange format which based on GML. I started studying code of GML and
> NAS driver which are both based on IGMLDriver. I discovered that part
> of the code is duplicated in NASDriver compared to GMLDriver. The
> differencies are usually little and 99% of the code is identical, for
> example - SaveClass() - NAS [1] and GML [2]. There could be probably a
> middle class same for NAS and GML driver (and probably also for the
> driver I am currently writing) - at least when loading or saving
> classes into GFS file...
>
> What do you think?
>
> Martin
>
> [1]
>
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/gml/gmlreader.cpp#L1247
> [2]
>
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/nas/nasreader.cpp#L804
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>




More information about the gdal-dev mailing list