[gdal-dev] MapInfo Datum lookup bug, CSV data for drivers

[Chaitanya kumar CH]

Qi-Shan,

As per point 3; the data is not going to be changed often. Reading a
data file may complicate things.

Just thinking out loud here...

Regards,
-- 
Chaitanya kumar CH.


On Fri, Mar 13, 2009 at 9:11 AM, Qi-Shan Lim
<qi-shan.lim at koordinates.com> wrote:
> Hi all,
>
> I'm new to GDAL/OGR development and have run up against an existing
> bug with the MapInfo driver, which I'm willing to help fix. Details
> are at http://trac.osgeo.org/gdal/ticket/481#comment:8 with a comment
> which I'll reproduce here for convenience:
>
> I'm hitting this problem as well and really need to get it resolved.
> Only just started working with gdal/ogr so comments would be
> appreciated on this proposal:
>
> ---
> 1. Change asDatumInfoList to include the EPSG code for the datum. I
> imagine this could be accomplished with a mixture of pattern-matching
> the names and some manual intervention.
>
> 2. Change SetSpatialRef? to look up the data based on the datum's EPSG
> code instead of name i.e. use poSpatialRef->GetAuthorityCode?("DATUM")
> instead of poSpatialRef->GetAttrValue?("DATUM")
>
> 3. (Optional) Move asDatumInfoList (and the other hard-coded data, I
> guess) into a csv file.
>
> Is this going to work or am I talking rubbish? If it sounds reasonable
> I'll go ahead and do up a patch.
> ---
>
> I'm posting to the list as point 3 seems to be a general question - is
> it acceptable for drivers that required this sort of data to stick it
> into a csv file to put into the data/ directory? Also, if this data is
> to be generated in some sort of semi-automated way using a script of
> some sort, should this script be committed to the source tree?
>
> Would appreciate any advice/help as I get familiar with the code base.
>
> Cheers,
>
> --Qi-Shan
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>