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 <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
