Re: [gdal-dev] Losing access to dataset variables. Am I doing something really dumb?
Hi Jorge,
I don't see anything obviously wrong. Looking at the places where the variables
might be nullified and running Valgrind would be my best advice.
Just wanted to mention that in the likely simplified below snippet, you would
leak memory.
Even
Hello,
I have a stupid mistake in my code. This is the problem (very simplified):
postgisrasterdataset.cpp
PostGISRasterDataset::IRasterIO()
{
// Two attributes of my class, that inherits from GDALDataset
pszAttribute = CPLStrdup(foo);
pszAttribute2 = CPLStrdup(bar);
// Just delegates in default implementation
return GDALDataset::IRasterIO(...);
}
postgisrasterrasterband.cpp
PostGISRasterRasterBand::IRasterIO()
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Do some stuff with poRDS-pszAttribute and poRDS-pszAttribute2
// They're private vars, but PostGISRasterRasterBand and
// PostGISRasterDataset are friends. No problem here.
// Delegates in default implementation. So, this will result, at the
end, in calls
// to my implementation of IReadBlock / IWriteBlock
return GDALRasterBand::IRasterIO(...);
}
PostGISRasterRasterBand::IWriteBlock(...)
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Try to work with poRDS-pszAttribute and poRDS-pszAttribute2, but
// fails because they are NULL. Why??
}
Weirdest thing is the rest of cuestom attributes of my PostGISRasterDataset
class are accessible. And, of course, the poRDS pointer is always the same
(same mem address). Only problem is with those char * attributes. Looks
like they're freed at some point (or I'm doing something really wrong from
the point of view of C++, and I deserve a severe punishment for that).
Any clues?
Best regards,
--
Jorge Arevalo
http://about.me/jorgeas80
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Losing access to dataset variables. Am I doing something really dumb?
Hi Even,
Thanks for your hints. About the memory leaking, apart from the obvious
fact that CPLStrdup vars need to be freed, are you seeing something more?
On Tue, Aug 12, 2014 at 9:48 AM, Even Rouault even.roua...@mines-paris.org
wrote:
Hi Jorge,
I don't see anything obviously wrong. Looking at the places where the
variables
might be nullified and running Valgrind would be my best advice.
Just wanted to mention that in the likely simplified below snippet, you
would
leak memory.
Even
Hello,
I have a stupid mistake in my code. This is the problem (very
simplified):
postgisrasterdataset.cpp
PostGISRasterDataset::IRasterIO()
{
// Two attributes of my class, that inherits from GDALDataset
pszAttribute = CPLStrdup(foo);
pszAttribute2 = CPLStrdup(bar);
// Just delegates in default implementation
return GDALDataset::IRasterIO(...);
}
postgisrasterrasterband.cpp
PostGISRasterRasterBand::IRasterIO()
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Do some stuff with poRDS-pszAttribute and poRDS-pszAttribute2
// They're private vars, but PostGISRasterRasterBand and
// PostGISRasterDataset are friends. No problem here.
// Delegates in default implementation. So, this will result, at the
end, in calls
// to my implementation of IReadBlock / IWriteBlock
return GDALRasterBand::IRasterIO(...);
}
PostGISRasterRasterBand::IWriteBlock(...)
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Try to work with poRDS-pszAttribute and poRDS-pszAttribute2, but
// fails because they are NULL. Why??
}
Weirdest thing is the rest of cuestom attributes of my
PostGISRasterDataset
class are accessible. And, of course, the poRDS pointer is always the
same
(same mem address). Only problem is with those char * attributes. Looks
like they're freed at some point (or I'm doing something really wrong
from
the point of view of C++, and I deserve a severe punishment for that).
Any clues?
Best regards,
--
Jorge Arevalo
http://about.me/jorgeas80
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Losing access to dataset variables. Am I doing something really dumb?
Selon Jorge Arevalo jorgearev...@libregis.org:
Hi Even,
Thanks for your hints. About the memory leaking, apart from the obvious
fact that CPLStrdup vars need to be freed, are you seeing something more?
No, that was indeed what I meant. Not much more that could leak in the snippet
;-)
On Tue, Aug 12, 2014 at 9:48 AM, Even Rouault even.roua...@mines-paris.org
wrote:
Hi Jorge,
I don't see anything obviously wrong. Looking at the places where the
variables
might be nullified and running Valgrind would be my best advice.
Just wanted to mention that in the likely simplified below snippet, you
would
leak memory.
Even
Hello,
I have a stupid mistake in my code. This is the problem (very
simplified):
postgisrasterdataset.cpp
PostGISRasterDataset::IRasterIO()
{
// Two attributes of my class, that inherits from GDALDataset
pszAttribute = CPLStrdup(foo);
pszAttribute2 = CPLStrdup(bar);
// Just delegates in default implementation
return GDALDataset::IRasterIO(...);
}
postgisrasterrasterband.cpp
PostGISRasterRasterBand::IRasterIO()
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Do some stuff with poRDS-pszAttribute and poRDS-pszAttribute2
// They're private vars, but PostGISRasterRasterBand and
// PostGISRasterDataset are friends. No problem here.
// Delegates in default implementation. So, this will result, at the
end, in calls
// to my implementation of IReadBlock / IWriteBlock
return GDALRasterBand::IRasterIO(...);
}
PostGISRasterRasterBand::IWriteBlock(...)
{
// Get pointer to dataset this rasterband belongs to
PostGISRasterDataset * poRDS = (PostGISRasterDataset *)poDS;
// Try to work with poRDS-pszAttribute and poRDS-pszAttribute2, but
// fails because they are NULL. Why??
}
Weirdest thing is the rest of cuestom attributes of my
PostGISRasterDataset
class are accessible. And, of course, the poRDS pointer is always the
same
(same mem address). Only problem is with those char * attributes. Looks
like they're freed at some point (or I'm doing something really wrong
from
the point of view of C++, and I deserve a severe punishment for that).
Any clues?
Best regards,
--
Jorge Arevalo
http://about.me/jorgeas80
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GPKG application_id
Even Rouault even.rouault at spatialys.com writes: Hi Paul, ... Others are less likely. I’ve learned that GeoServer is emitted GPKG files without the application_id set. Hum, do they plan fixing that at some point ? Couldn't they do the same trick we do (direct editing) ? According to Geotools jira http://jira.codehaus.org/browse/GEOT-4816 this issue is fixed two days ago. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR support for POINT ZM
Dear GDAL/OGR team, I just realized that there is no support for the OGC POINT ZM geometry in GDAL/OGR. It is well possible to read in a 3D point with an additional attribute from the following OGC compliant WKT string... POINT ZM(1. 2. 3. 4.) ... but the attribute value (i.e. 4.) is silently ignored and not reflected in the OGRPoint data structure. Especially exporting the above contents back to WKT, results in... POINT(1. 2. 3.) Any plans to add POINT ZM support in GDAL in the near future? Kind regards, Gottfried -- Dr. Gottfried Mandlburger Tel.: +43 1 58801 12235 Fax.: +43 1 58801 12299 http://www.ipf.tuwien.ac.at _ _ _ /// ___/// Vienna University of Technology // __ / /__ / // / Department of Geodesy and Geoinformation //__/// /__ / // / Research Groups Photogrammetry and Remote Sensing ////// Gusshausstrasse 27-29, A-1040 Vienna ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR support for POINT ZM
On 12 August 2014 17:54, Gottfried Mandlburger gottfried.mandlbur...@geo.tuwien.ac.at wrote: Any plans to add POINT ZM support in GDAL in the near future? It was proposed to Google Summer of Code [1] this year, but not selected. I'm not sure if there is any ongoing initiative. [1] http://trac.osgeo.org/gdal/wiki/SummerOfCode Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR support for POINT ZM
Selon Gottfried Mandlburger gottfried.mandlbur...@geo.tuwien.ac.at: Dear GDAL/OGR team, I just realized that there is no support for the OGC POINT ZM geometry in GDAL/OGR. It is well possible to read in a 3D point with an additional attribute from the following OGC compliant WKT string... POINT ZM(1. 2. 3. 4.) ... but the attribute value (i.e. 4.) is silently ignored and not reflected in the OGRPoint data structure. Especially exporting the above contents back to WKT, results in... POINT(1. 2. 3.) Any plans to add POINT ZM support in GDAL in the near future? Gottfried, indeed a long standing wish that is listed in the nice-to-have features for GDAL 2.0 : http://trac.osgeo.org/gdal/wiki/GDAL20Changes. Something looking for contributors or funding. Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
