Re: [gdal-dev] Coding for appending to a database in OGR
Hi Peter, Do you mean that just after issuing a CreateFeature(), the feature ID isn't set to the correct value (the one that you'll find after dataset reopening) ? You have to be more specific about which OGR driver you are talking about because the mechanisms for setting/retrieving FID is driver specific. Perhaps a small snippet of code would help to understand what you do / would like to do. If you're interested in the PG driver, here's a relevant ticket : http://trac.osgeo.org/gdal/ticket/3744 Best regards, Even > Dear Team, > > I've reviewed the change log for release 8 so far and do not think that > this question is version specific. > > I'm coding to support an incremental process for loading a large spatial > database from a set of distribution objects. I have noted that my present > approach results in the OGR_FID column values restarting at 1 for each > append. > This is clearly an error! However, there does not appear to be a method for > initialising the 'nextfidtowrite' value in the API. What is the best > strategy > to adopt? > > So far as I can see, there appear to be two options. One is to read > every > feature until there are no more to read: I'd rather not do that. The other > would involve opening the layer, reading the featurecount and then requesting > the featurecount'th feature - featurecount'th + 1 should give an error. Both > methods should leave the current feature being the last existing feature, but > is > this sufficient to effectively initialise the value at which the next FID > will > start? > > Thanks and best wishes, > > Peter > > > Peter J Halls, GIS Advisor, University of York > Telephone: 01904 323806 Fax: 01904 323740 > Snail mail: IT Services, University of York, Heslington, York YO10 5DD > This message has the status of a private and personal communication > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Even, thank you for your response. I had missed feat.SetFID, mentioned in the PG ticket, so will have a go with that. For the record, I'm currently working against the OCI driver but wish to be reasonably independent of the underlying database implementation - hence use of OGR. Thanks and best wishes, Peter Even Rouault wrote: Hi Peter, Do you mean that just after issuing a CreateFeature(), the feature ID isn't set to the correct value (the one that you'll find after dataset reopening) ? You have to be more specific about which OGR driver you are talking about because the mechanisms for setting/retrieving FID is driver specific. Perhaps a small snippet of code would help to understand what you do / would like to do. If you're interested in the PG driver, here's a relevant ticket : http://trac.osgeo.org/gdal/ticket/3744 Best regards, Even Dear Team, I've reviewed the change log for release 8 so far and do not think that this question is version specific. I'm coding to support an incremental process for loading a large spatial database from a set of distribution objects. I have noted that my present approach results in the OGR_FID column values restarting at 1 for each append. This is clearly an error! However, there does not appear to be a method for initialising the 'nextfidtowrite' value in the API. What is the best strategy to adopt? So far as I can see, there appear to be two options. One is to read every feature until there are no more to read: I'd rather not do that. The other would involve opening the layer, reading the featurecount and then requesting the featurecount'th feature - featurecount'th + 1 should give an error. Both methods should leave the current feature being the last existing feature, but is this sufficient to effectively initialise the value at which the next FID will start? Thanks and best wishes, Peter Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Even and team, following the hint from Even's post below, I have been experimenting with OGR_F_SetFID to get the FID for appends to increment beyond the existing value, rather than always to start at 1. I'm testing against the OCI driver and am not (yet) using 1.8. I've found that there appears to be no way to 'reset' the starting FID value used by the driver for output. I can certainly set the FID to an arbitrary value for a specific record, but the internal counter does not appear to be reset-able. This means that I must manage the FID values externally to OGR when appending to an existing dataset in order to avoid new records being added with OGR_FID values restarting from 1. Is this what is expected / intended? The observed behaviour does not quite seem to be as one might expect - especially for the database drivers where the FID is to become the primary key and so must have unique values. At present it would appear that this condition is broken when OGR is used to append. Indeed, were I to create a table with a unique constraint on OGR_FID, appends would fail once there are records in the table. I've also tried reading the last record in the table and reading the table until there are no more records to read, but neither seem to have any impact on the initial FID value when writing. Is this a peculiarity of the OCI driver? Thanks and best wishes, Peter Even Rouault wrote: Hi Peter, Do you mean that just after issuing a CreateFeature(), the feature ID isn't set to the correct value (the one that you'll find after dataset reopening) ? You have to be more specific about which OGR driver you are talking about because the mechanisms for setting/retrieving FID is driver specific. Perhaps a small snippet of code would help to understand what you do / would like to do. If you're interested in the PG driver, here's a relevant ticket : http://trac.osgeo.org/gdal/ticket/3744 Best regards, Even Dear Team, I've reviewed the change log for release 8 so far and do not think that this question is version specific. I'm coding to support an incremental process for loading a large spatial database from a set of distribution objects. I have noted that my present approach results in the OGR_FID column values restarting at 1 for each append. This is clearly an error! However, there does not appear to be a method for initialising the 'nextfidtowrite' value in the API. What is the best strategy to adopt? So far as I can see, there appear to be two options. One is to read every feature until there are no more to read: I'd rather not do that. The other would involve opening the layer, reading the featurecount and then requesting the featurecount'th feature - featurecount'th + 1 should give an error. Both methods should leave the current feature being the last existing feature, but is this sufficient to effectively initialise the value at which the next FID will start? Thanks and best wishes, Peter Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Peter J Halls wrote: Even and team, following the hint from Even's post below, I have been experimenting with OGR_F_SetFID to get the FID for appends to increment beyond the existing value, rather than always to start at 1. I'm testing against the OCI driver and am not (yet) using 1.8. I've found that there appears to be no way to 'reset' the starting FID value used by the driver for output. I can certainly set the FID to an arbitrary value for a specific record, but the internal counter does not appear to be reset-able. This means that I must manage the FID values externally to OGR when appending to an existing dataset in order to avoid new records being added with OGR_FID values restarting from 1. Is this what is expected / intended? Peter, This is a flaw in the OCI driver. FIDs are supposed to be unique, and if the CreateFeature() method is assigning one, it should ensure it is unique. I have reviewed the trunk code, and this seems to be a problem with it too. My feeling is that the first time iNextShapeId is used in the lifetime of an OGROCITableLayer we ought to do a query on the corresponding column to find it's max, and use that +1 as iNextShapeId. This would generally avoid conflicts, and would not be as expensive as querying for each create feature. The downside to this approach is that it assumes no one else is adding features to the table during the lifetime of the OGROCITableLayer object. This is usually safe, but not always. This is one example of how the OGR RDBMS drivers are often not *really* prepared to live cleanly in a multi-user / multi-application environment. It could be "done right" but the cost for bulk loads might be quite painful. Fast bulk loads was the original reason for existence of the OCI driver. If you would like to prepare code for that it would be great. If not, please create a ticket for the issue and hopefully I'll have a chance to do it. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
An interesting discussion, but shouldn't the layer table have been cread with a UNIQUE contraint in the ID column in the first place ? Anders On Thu, Oct 28, 2010 at 5:02 PM, Frank Warmerdam wrote: > Peter J Halls wrote: > >> Even and team, >> >> following the hint from Even's post below, I have been experimenting >> with OGR_F_SetFID to get the FID for appends to increment beyond the >> existing value, rather than always to start at 1. I'm testing against the >> OCI driver and am not (yet) using 1.8. >> >> I've found that there appears to be no way to 'reset' the starting FID >> value used by the driver for output. I can certainly set the FID to an >> arbitrary value for a specific record, but the internal counter does not >> appear to be reset-able. This means that I must manage the FID values >> externally to OGR when appending to an existing dataset in order to avoid >> new records being added with OGR_FID values restarting from 1. >> >> Is this what is expected / intended? >> > > Peter, > > This is a flaw in the OCI driver. FIDs are supposed to be unique, and > if the CreateFeature() method is assigning one, it should ensure it is > unique. > > I have reviewed the trunk code, and this seems to be a problem with it too. > > My feeling is that the first time iNextShapeId is used in the lifetime of > an OGROCITableLayer we ought to do a query on the corresponding column > to find it's max, and use that +1 as iNextShapeId. This would generally > avoid conflicts, and would not be as expensive as querying for each > create feature. > > The downside to this approach is that it assumes no one else is adding > features to the table during the lifetime of the OGROCITableLayer object. > This is usually safe, but not always. This is one example of how the > OGR RDBMS drivers are often not *really* prepared to live cleanly in > a multi-user / multi-application environment. It could be "done right" > but the cost for bulk loads might be quite painful. Fast bulk loads > was the original reason for existence of the OCI driver. > > If you would like to prepare code for that it would be great. If not, > please create a ticket for the issue and hopefully I'll have a chance to > do it. > > Best regards, > -- > > ---+-- > I set the clouds in motion - turn up | Frank Warmerdam, > warmer...@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush| Geospatial Programmer for Rent > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Anders Moe Managing Director Geocap w: +47 22 95 56 63 anders@geocap.no ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Selon Peter J Halls : Not using it, it's hard for me to comment on OCI peculiarities. I've looked quickly at the code of ogroctitablelayer.cpp and it seems to be consistant with the behaviour you describe : if you set a FID before using CreateFeature() it will use it, otherwise it will use a serial number incremented on OGR side, that is initially set at 1 at datasource opening. I have no clue if it is wanted/expected for some reason... That seems to be related with the way the FID column is discovered. I see this : /* */ /* What is the name of the column to use as FID? This defaults*/ /* to OGR_FID but we allow it to be overridden by a config */ /* variable. Ideally we would identify a column that is a */ /* primary key and use that, but I'm not yet sure how to */ /* accomplish that.*/ /* */ const char *pszExpectedFIDName = CPLGetConfigOption( "OCI_FID", "OGR_FID" ); So there's no real guarantee on the characteristics of the FID column. It could even have no uniqueness constraint. Generally/ideally, the driver should be able to set automatically the FID of the feature that is passed to CreateFeature() with a unique value, especially when the FID is a RDBMS auto-increment column. This is for example done in the SQLite driver. The patch I mentionned in my previous post about the PG driver also aims at doing that. The Shape driver also seems to do it that way. So there's perhaps place for improvements in OCI driver. > Even and team, > > following the hint from Even's post below, I have been experimenting with > OGR_F_SetFID to get the FID for appends to increment beyond the existing > value, > rather than always to start at 1. I'm testing against the OCI driver and am > not > (yet) using 1.8. > > I've found that there appears to be no way to 'reset' the starting FID > value > used by the driver for output. I can certainly set the FID to an arbitrary > value for a specific record, but the internal counter does not appear to be > reset-able. This means that I must manage the FID values externally to OGR > when > appending to an existing dataset in order to avoid new records being added > with > OGR_FID values restarting from 1. > > Is this what is expected / intended? > > The observed behaviour does not quite seem to be as one might expect - > especially for the database drivers where the FID is to become the primary > key > and so must have unique values. At present it would appear that this > condition > is broken when OGR is used to append. Indeed, were I to create a table with > a > unique constraint on OGR_FID, appends would fail once there are records in > the > table. > > I've also tried reading the last record in the table and reading the > table > until there are no more records to read, but neither seem to have any impact > on > the initial FID value when writing. > > Is this a peculiarity of the OCI driver? > > Thanks and best wishes, > > Peter > > Even Rouault wrote: > > Hi Peter, > > > > Do you mean that just after issuing a CreateFeature(), the feature ID isn't > set > > to the correct value (the one that you'll find after dataset reopening) ? > > > > You have to be more specific about which OGR driver you are talking about > > because the mechanisms for setting/retrieving FID is driver specific. > > > > Perhaps a small snippet of code would help to understand what you do / > would > > like to do. > > > > If you're interested in the PG driver, here's a relevant ticket : > > http://trac.osgeo.org/gdal/ticket/3744 > > > > Best regards, > > > > Even > > > >> Dear Team, > >> > >> I've reviewed the change log for release 8 so far and do not think > that > >> this question is version specific. > >> > >> I'm coding to support an incremental process for loading a large > spatial > >> database from a set of distribution objects. I have noted that my present > >> approach results in the OGR_FID column values restarting at 1 for each > >> append. > >> This is clearly an error! However, there does not appear to be a method > for > >> initialising the 'nextfidtowrite' value in the API. What is the best > >> strategy > >> to adopt? > >> > >> So far as I can see, there appear to be two options. One is to read > >> every > >> feature until there are no more to read: I'd rather not do that. The > other > >> would involve opening the layer, reading the featurecount and then > requesting > >> the featurecount'th feature - featurecount'th + 1 should give an error. > Both > >> methods should leave the current feature being the last existing feature, > but > >> is > >> this sufficient to effectively initialise the value at which the next FID > >> will > >> start? > >> > >> Thanks and best wishes, > >> > >> Peter
Re: [gdal-dev] Coding for appending to a database in OGR
Frank and team, having reviewed the code again and the comments made by others, for which thanks, it seems to me that there is a possible solution that might resolve all the concerns. I've asked my DBA for performance expectation comments, but have not yet heard back from him. Instead of trying to track the current FID and where the caller has not specified a value 'SELECT max(OGR_FID) + 1 FROM ' could be used instead. This will always return the maximum value plus one and consigns the work to Oracle. This will be 'safe' for multiple updaters and saves the overhead / risk of enquiring the value and updating it in the code. However, one side effect of this is that the value is not readily known to OGR. As this is only when writing a new feature to the database, does this matter? Is there any reliance on the FID within a newly created / written feature having the destination FID value on return - I suspect that, in the majority of instances, the next call is to destroy the feature handle? As this would be a change in behaviour, at least it will be if I am correct that only the BoundCreateFeature method is actually used, then this may be significant. How do others regard this? Is it a big issue or a non-issue? Best wishes, Peter Frank Warmerdam wrote: Peter J Halls wrote: Even and team, following the hint from Even's post below, I have been experimenting with OGR_F_SetFID to get the FID for appends to increment beyond the existing value, rather than always to start at 1. I'm testing against the OCI driver and am not (yet) using 1.8. I've found that there appears to be no way to 'reset' the starting FID value used by the driver for output. I can certainly set the FID to an arbitrary value for a specific record, but the internal counter does not appear to be reset-able. This means that I must manage the FID values externally to OGR when appending to an existing dataset in order to avoid new records being added with OGR_FID values restarting from 1. Is this what is expected / intended? Peter, This is a flaw in the OCI driver. FIDs are supposed to be unique, and if the CreateFeature() method is assigning one, it should ensure it is unique. I have reviewed the trunk code, and this seems to be a problem with it too. My feeling is that the first time iNextShapeId is used in the lifetime of an OGROCITableLayer we ought to do a query on the corresponding column to find it's max, and use that +1 as iNextShapeId. This would generally avoid conflicts, and would not be as expensive as querying for each create feature. The downside to this approach is that it assumes no one else is adding features to the table during the lifetime of the OGROCITableLayer object. This is usually safe, but not always. This is one example of how the OGR RDBMS drivers are often not *really* prepared to live cleanly in a multi-user / multi-application environment. It could be "done right" but the cost for bulk loads might be quite painful. Fast bulk loads was the original reason for existence of the OCI driver. If you would like to prepare code for that it would be great. If not, please create a ticket for the issue and hopefully I'll have a chance to do it. Best regards, -- Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Peter J Halls wrote: Frank and team, having reviewed the code again and the comments made by others, for which thanks, it seems to me that there is a possible solution that might resolve all the concerns. I've asked my DBA for performance expectation comments, but have not yet heard back from him. Instead of trying to track the current FID and where the caller has not specified a value 'SELECT max(OGR_FID) + 1 FROM ' could be used instead. This will always return the maximum value plus one and consigns the work to Oracle. This will be 'safe' for multiple updaters and saves the overhead / risk of enquiring the value and updating it in the code. However, one side effect of this is that the value is not readily known to OGR. As this is only when writing a new feature to the database, does this matter? Is there any reliance on the FID within a newly created / written feature having the destination FID value on return - I suspect that, in the majority of instances, the next call is to destroy the feature handle? As this would be a change in behaviour, at least it will be if I am correct that only the BoundCreateFeature method is actually used, then this may be significant. How do others regard this? Is it a big issue or a non-issue? Peter, I am quite concerned about the performance impact of doing the MAX() operation for every feature insert. I also would consider it a major disadvantage to not return the FID properly set on the feature. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
Thanks, Frank ... Frank Warmerdam wrote: Peter J Halls wrote: Frank and team, having reviewed the code again and the comments made by others, for which thanks, it seems to me that there is a possible solution that might resolve all the concerns. I've asked my DBA for performance expectation comments, but have not yet heard back from him. Instead of trying to track the current FID and where the caller has not specified a value 'SELECT max(OGR_FID) + 1 FROM ' could be used instead. This will always return the maximum value plus one and consigns the work to Oracle. This will be 'safe' for multiple updaters and saves the overhead / risk of enquiring the value and updating it in the code. However, one side effect of this is that the value is not readily known to OGR. As this is only when writing a new feature to the database, does this matter? Is there any reliance on the FID within a newly created / written feature having the destination FID value on return - I suspect that, in the majority of instances, the next call is to destroy the feature handle? As this would be a change in behaviour, at least it will be if I am correct that only the BoundCreateFeature method is actually used, then this may be significant. How do others regard this? Is it a big issue or a non-issue? Peter, I am quite concerned about the performance impact of doing the MAX() operation for every feature insert. I also would consider it a major disadvantage to not return the FID properly set on the feature. Now I've talked it over with my DBA, my view is that a Sequence would give better performance. Use of NextVal from the Sequence will return a unique value for the FID, which can then be written back to the feature as well as to the dbms and maintain the unique values - provided all updaters use the same Sequence. We worked out that setting the Primary Key or Unique constraint on the column would prevent multiple updaters using the same FID value: the lack of this constraint is probably a separate issue. The constraint would also be essential to prevent multiple updaters using different methods of obtaining a value for the FID as even the Sequence could then get out of step. However, to support multiple updaters using different methods would require that the OGR insert code be defensive and expect to fail (through violation of the constraint) and be prepared to try new values until success is achieved. We think that this overhead might exceed the use of SELECT max(OGR_FID) + 1. This then comes back to the question of providing support for multiple updaters. Best wishes, Peter Peter J Halls, GIS Advisor, University of York Telephone: 01904 323806 Fax: 01904 323740 Snail mail: IT Services, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coding for appending to a database in OGR
> > From: Peter J Halls > Subject: Re: [gdal-dev] Coding for appending to a database in OGR > To: Frank Warmerdam > Cc: gdal-dev@lists.osgeo.org > Message-ID: <4ccad1df.60...@york.ac.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks, Frank ... > > Frank Warmerdam wrote: > > Peter J Halls wrote: > >> Frank and team, > >> > >>having reviewed the code again and the comments made by others, for > >> which thanks, it seems to me that there is a possible solution that > >> might resolve all the concerns. I've asked my DBA for performance > >> expectation comments, but have not yet heard back from him. > >> > >>Instead of trying to track the current FID and where the caller has > >> not specified a value 'SELECT max(OGR_FID) + 1 FROM ' > >> could be used instead. This will always return the maximum value plus > >> one and consigns the work to Oracle. This will be 'safe' for multiple > >> updaters and saves the overhead / risk of enquiring the value and > >> updating it in the code. > >> > >>However, one side effect of this is that the value is not readily > >> known to OGR. As this is only when writing a new feature to the > >> database, does this matter? Is there any reliance on the FID within a > >> newly created / written feature having the destination FID value on > >> return - I suspect that, in the majority of instances, the next call > >> is to destroy the feature handle? As this would be a change in > >> behaviour, at least it will be if I am correct that only the > >> BoundCreateFeature method is actually used, then this may be > significant. > >> > >> How do others regard this? Is it a big issue or a non-issue? > > > > Peter, > > > > I am quite concerned about the performance impact of doing the MAX() > > operation for every feature insert. I also would consider it a major > > disadvantage to not return the FID properly set on the feature. > > Now I've talked it over with my DBA, my view is that a Sequence would give > better performance. Use of NextVal from the Sequence will return a unique > value > for the FID, which can then be written back to the feature as well as to > the > dbms and maintain the unique values - provided all updaters use the same > Sequence. > > We worked out that setting the Primary Key or Unique constraint on the > column > would prevent multiple updaters using the same FID value: the lack of this > constraint is probably a separate issue. The constraint would also be > essential > to prevent multiple updaters using different methods of obtaining a value > for > the FID as even the Sequence could then get out of step. > > However, to support multiple updaters using different methods would require > that > the OGR insert code be defensive and expect to fail (through violation of > the > constraint) and be prepared to try new values until success is achieved. > We > think that this overhead might exceed the use of SELECT max(OGR_FID) + 1. > > This then comes back to the question of providing support for multiple > updaters. > > Best wishes, > > Peter > Hello Peter, Actually, unless I am missing something very obvious, the select max()+1 approach would not work since there are race-condition-like situations where one of the statements from one of the connections would fail. Why not just used the underlying database's AUTOINCREMENT features? Most dbs support that and I think in Oracle it is done with a sequence combined with a trigger or specifying the sequence.nextval() in the insert statement itself. Just to point out, ArcObjects has the concept of a RowBuffer - a row that is used for insertion that behaves just like regular row except that it doesn't have identity (the ID hasn't been assigned yet) until after it has been inserted (after db insertion, the id is looked up and assigned to the client object). my two cents, - Ragi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
