[gdal-dev] Interpolation when using the WMS format
Hi, everybody we are using the GDAL WMS driver for getting maps from a public WMTS service, http://www.basemap.at. Anyway, the resulting image does not look smooth. In particular, I would guess that the the image was scaled with something like a nearest neighbor algorithm. So my question is simply, if I can switch the interpolation method in some place. The XML file, taken from http://gisforge.wordpress.com/2012/11/06/basemap-at-wmts-layer-in-qgis/, is: http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/${z}/${y}/${x}.jpeg -20037508.34 20037508.34 20037508.34 -20037508.34 18 1 1 top EPSG:3857 256 256 3 The command is: gdal_translate -srcwin 3550 2350 10 10 -of JPEG -outsize 250 250 basemap_at.xml basemap_at.jpg As can be clearly seen, the labels are hard to read. Reagrds, Peter -- Peter Hopfgartner R3 GIS web : www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interpolation when using the WMS format
Salut Evan, thanks for you recipe. Unfortunately, what I am really interested in is to use this from MapServer. Could you give me a pointer in the source where the resampling takes place? Thanks, Peter Am 18.09.2014 um 22:11 schrieb Even Rouault : > Le jeudi 18 septembre 2014 17:40:11, Peter Hopfgartner a écrit : >> Hi, everybody >> >> we are using the GDAL WMS driver for getting maps from a public WMTS >> service, http://www.basemap.at. Anyway, the resulting image does not >> look smooth. In particular, I would guess that the the image was scaled >> with something like a nearest neighbor algorithm. >> So my question is simply, if I can switch the interpolation method in >> some place. >> >> The XML file, taken from >> http://gisforge.wordpress.com/2012/11/06/basemap-at-wmts-layer-in-qgis/, >> is: >> >> >> >> http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/ >> ${z}/${y}/${x}.jpeg >> >> -20037508.34 >> 20037508.34 >> 20037508.34 >> -20037508.34 >> 18 >> 1 >> 1 >> top >> >> EPSG:3857 >> 256 >> 256 >> 3 >> >> >> >> The command is: >> >> gdal_translate -srcwin 3550 2350 10 10 -of JPEG -outsize >> 250 250 basemap_at.xml basemap_at.jpg > > Peter, > > Resampling done by gdal_translate is nearest neighbour, so not always that > great. > > What you can do is select an outsize that is compatible with the source > overviews. In TMS, the ratio between sucessive overviews work with factor of > 2, so you should select an outsize of 1 / 2^N. The closest is 1 / 256 > = 390.625 -> 391 > > So > > gdal_translate -srcwin 3550 2350 10 10 -outsize > 391 391 basemap_at.xml tmp.tif > > and then: > > gdalwarp tmp.tif tmp2.tif -r lanczos -ts 250 250 (you can try different > resampling kernel) > gdal_translate tmp2.tif basemap_at.jpg -of JPEG > > 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
Re: [gdal-dev] Interpolation when using the WMS format
Hello Evan, I've tried this on your suggestion. What happens is, that all labels are now much smaller, even harder to read then before. Basically, it seems that tiles from a higher zoom levels are taken. This would be reasonably, if there would be no labels on the tiles. But in the case of the basemap.at tiles, labels are drawn on the tiles. When working with tiles, even more if the tiles are from a third party, the available options are much reduced, compared to WMS request. When the raster information is lost due to a lower quality interpolation, it's gone forever in the processing pipeline. I did not have the time to look at the code yet (and probably I do not have enough C++ experience either), I'll retry during the weekend. Regards, Peter On 09/18/2014 10:30 PM, Even Rouault wrote: Le jeudi 18 septembre 2014 22:23:06, Peter Hopfgartner a écrit : Salut Evan, thanks for you recipe. Unfortunately, what I am really interested in is to use this from MapServer. Could you give me a pointer in the source where the resampling takes place? In gcore/rasterio.cpp : GDALRasterBand::IRasterIO(). I must warn you : quite tricky code But perhaps you don't need code change. In MapServer did you try to define PROCESSING "RESAMPLE=BILINEAR" ? Thanks, Peter Am 18.09.2014 um 22:11 schrieb Even Rouault : Le jeudi 18 septembre 2014 17:40:11, Peter Hopfgartner a écrit : Hi, everybody we are using the GDAL WMS driver for getting maps from a public WMTS service, http://www.basemap.at. Anyway, the resulting image does not look smooth. In particular, I would guess that the the image was scaled with something like a nearest neighbor algorithm. So my question is simply, if I can switch the interpolation method in some place. The XML file, taken from http://gisforge.wordpress.com/2012/11/06/basemap-at-wmts-layer-in-qgis/, is: http://maps.wien.gv.at/basemap/geolandbasemap/normal/google38 57/ ${z}/${y}/${x}.jpeg -20037508.34 20037508.34 20037508.34 -20037508.34 18 1 1 top EPSG:3857 256 256 3 The command is: gdal_translate -srcwin 3550 2350 10 10 -of JPEG -outsize 250 250 basemap_at.xml basemap_at.jpg Peter, Resampling done by gdal_translate is nearest neighbour, so not always that great. What you can do is select an outsize that is compatible with the source overviews. In TMS, the ratio between sucessive overviews work with factor of 2, so you should select an outsize of 1 / 2^N. The closest is 1 / 256 = 390.625 -> 391 So gdal_translate -srcwin 3550 2350 10 10 -outsize 391 391 basemap_at.xml tmp.tif and then: gdalwarp tmp.tif tmp2.tif -r lanczos -ts 250 250 (you can try different resampling kernel) gdal_translate tmp2.tif basemap_at.jpg -of JPEG Best regards, Even -- Peter Hopfgartner R3 GIS web : www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interpolation when using the WMS format
On 09/18/2014 11:03 PM, Jukka Rahkonen wrote: Peter Hopfgartner r3-gis.com> writes: Salut Evan, thanks for you recipe. Unfortunately, what I am really interested in is to use this from MapServer. Could you give me a pointer in the source where the resampling takes place? Hi, Hi Jukka Why don't you test with Mapserver then before starting to code? You are certainly right that starting with MapServer is a more reasonable approach. Anyway, sometimes a look at the code might help to better understand the problem. (black box vs. white box) If you use Mapserver as WMS GDAL can request correct resolution directly and there should be no need at all for resampling. This is true for WMS layers. Unfortunately, with tiles this is different. I guess (and I think to have seen this in the code), that GDAL is looking for the best matching resolution for this particular tile server, fetches the necessary tiles and then resamples the tiles to the final pixmap, which, if not by incredible chance, has a lower resolution then the cpomplete set of fetched tiles. My guess is, that in this resampling the labels get unreadable to to nearest point interpolation, which is really fast but delivers a lower quality then e.g. bilinear interpolation. Most Mapservers are also configured to use png as one of the outputformats which should lead to better quality than the jpeg compressed tiles you have been playing with. Even here the, I have to follow the rules set by the service provider, as specified in http://www.basemap.at/wmts/1.0.0/WMTSCapabilities.xml , which limits me to JPEG. I have to take what I get. -Jukka Rahkonen- Regards, Peter -- Peter Hopfgartner R3 GIS web : www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interpolation when using the WMS format
On 09/18/2014 10:30 PM, Even Rouault wrote: Le jeudi 18 septembre 2014 22:23:06, Peter Hopfgartner a écrit : Salut Evan, thanks for you recipe. Unfortunately, what I am really interested in is to use this from MapServer. Could you give me a pointer in the source where the resampling takes place? In gcore/rasterio.cpp : GDALRasterBand::IRasterIO(). I must warn you : quite tricky code But perhaps you don't need code change. In MapServer did you try to define PROCESSING "RESAMPLE=BILINEAR" ? Thanks, Peter Am 18.09.2014 um 22:11 schrieb Even Rouault : Le jeudi 18 septembre 2014 17:40:11, Peter Hopfgartner a écrit : Hi, everybody we are using the GDAL WMS driver for getting maps from a public WMTS service, http://www.basemap.at. Anyway, the resulting image does not look smooth. In particular, I would guess that the the image was scaled with something like a nearest neighbor algorithm. So my question is simply, if I can switch the interpolation method in some place. The XML file, taken from http://gisforge.wordpress.com/2012/11/06/basemap-at-wmts-layer-in-qgis/, is: http://maps.wien.gv.at/basemap/geolandbasemap/normal/google38 57/ ${z}/${y}/${x}.jpeg -20037508.34 20037508.34 20037508.34 -20037508.34 18 1 1 top EPSG:3857 256 256 3 The command is: gdal_translate -srcwin 3550 2350 10 10 -of JPEG -outsize 250 250 basemap_at.xml basemap_at.jpg Peter, Resampling done by gdal_translate is nearest neighbour, so not always that great. What you can do is select an outsize that is compatible with the source overviews. In TMS, the ratio between sucessive overviews work with factor of 2, so you should select an outsize of 1 / 2^N. The closest is 1 / 256 = 390.625 -> 391 So gdal_translate -srcwin 3550 2350 10 10 -outsize 391 391 basemap_at.xml tmp.tif and then: gdalwarp tmp.tif tmp2.tif -r lanczos -ts 250 250 (you can try different resampling kernel) gdal_translate tmp2.tif basemap_at.jpg -of JPEG Best regards, Even I've tried to simulate the result of different algorithms to further investigate the idea of having a configurable resampling step. The original tile is 256 x 256 pixels and I've rescaled it to rescale it to 200x200 using Gimp. The original tile was taken from http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/8/89/137.jpg, a copy is stored at https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.jpg. Results no interpolation, (nearest neighbor?): https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-noint.png bilinear: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-linear.png bicubic: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-cubic.png lanczos: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-lanczos.png I'd say that the quality of the resampling respects the obove order, with lanczos being the best. Regards, Peter -- Peter Hopfgartner R3 GIS web : http://www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interpolation when using the WMS format
On 09/19/2014 12:51 PM, Even Rouault wrote: Selon Peter Hopfgartner : Hello Evan, I've tried this on your suggestion. What happens is, that all labels are now much smaller, even harder to read then before. Basically, it seems that tiles from a higher zoom levels are taken. This would be reasonably, if there would be no labels on the tiles. But in the case of the basemap.at tiles, labels are drawn on the tiles. Did you try tweaking OVERSAMPLE_RATIO ? See http://mapserver.org/input/raster.html. Note: the doc is out of sync. The default value is 2.0 (not 2.5). Hello Evan, we tried different values, but the result was rather unimpressive. Regards, Peter ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interpolation when using the WMS format
On 09/19/2014 01:50 PM, Peter Hopfgartner wrote: On 09/18/2014 10:30 PM, Even Rouault wrote: Le jeudi 18 septembre 2014 22:23:06, Peter Hopfgartner a écrit : Salut Evan, thanks for you recipe. Unfortunately, what I am really interested in is to use this from MapServer. Could you give me a pointer in the source where the resampling takes place? In gcore/rasterio.cpp : GDALRasterBand::IRasterIO(). I must warn you : quite tricky code But perhaps you don't need code change. In MapServer did you try to define PROCESSING "RESAMPLE=BILINEAR" ? Thanks, Peter Am 18.09.2014 um 22:11 schrieb Even Rouault : Le jeudi 18 septembre 2014 17:40:11, Peter Hopfgartner a écrit : Hi, everybody we are using the GDAL WMS driver for getting maps from a public WMTS service, http://www.basemap.at. Anyway, the resulting image does not look smooth. In particular, I would guess that the the image was scaled with something like a nearest neighbor algorithm. So my question is simply, if I can switch the interpolation method in some place. The XML file, taken from http://gisforge.wordpress.com/2012/11/06/basemap-at-wmts-layer-in-qgis/, is: http://maps.wien.gv.at/basemap/geolandbasemap/normal/google38 57/ ${z}/${y}/${x}.jpeg -20037508.34 20037508.34 20037508.34 -20037508.34 18 1 1 top EPSG:3857 256 256 3 The command is: gdal_translate -srcwin 3550 2350 10 10 -of JPEG -outsize 250 250 basemap_at.xml basemap_at.jpg Peter, Resampling done by gdal_translate is nearest neighbour, so not always that great. What you can do is select an outsize that is compatible with the source overviews. In TMS, the ratio between sucessive overviews work with factor of 2, so you should select an outsize of 1 / 2^N. The closest is 1 / 256 = 390.625 -> 391 So gdal_translate -srcwin 3550 2350 10 10 -outsize 391 391 basemap_at.xml tmp.tif and then: gdalwarp tmp.tif tmp2.tif -r lanczos -ts 250 250 (you can try different resampling kernel) gdal_translate tmp2.tif basemap_at.jpg -of JPEG Best regards, Even I've tried to simulate the result of different algorithms to further investigate the idea of having a configurable resampling step. The original tile is 256 x 256 pixels and I've rescaled it to rescale it to 200x200 using Gimp. The original tile was taken from http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/8/89/137.jpg, a copy is stored at https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.jpg. Results no interpolation, (nearest neighbor?): https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-noint.png bilinear: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-linear.png bicubic: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-cubic.png lanczos: https://dl.dropboxusercontent.com/u/4935329/resampling_tests/137.resampled_to_200.px-lanczos.png I'd say that the quality of the resampling respects the obove order, with lanczos being the best. Regards, Peter I finally took the time to have a better look at this. The attached patch is only for our special case, where data arrives in 8 bit bands and is certainly far from being decent (I've written my last C++ code approx. 15 years ago). Anyway, the image quality seems indeed to improve sensibly. I used the current SVN version as a base for the development. Applying the patch I get from https://dl.dropboxusercontent.com/u/4935329/resampling_tests/basemap.2000x2000-quasiorig.jpg to this https://dl.dropboxusercontent.com/u/4935329/resampling_tests/basemap.2000x2000.bilinear.jpg . Anyway, the execution time approximatly doubles (on my 2011 notebook it passes from ~ 1.8 s to ~ 3.4 s), which in our case is not really an issue, but probaly for almost everybody else. The command line is, starting from the compilation dir: apps/gdal_translate -srcwin 3000 23538000 2500 2500 -of JPEG -outsize 2000 2000 basemap.xml basemap.2000x2000.bilinear.jpg . Any comment is highly appreciated. Regards and a nice weekend, Peter -- Peter Hopfgartner R3 GIS web : http://www.r3-gis.com Index: gcore/rasterio.cpp === --- gcore/rasterio.cpp (revision 27739) +++ gcore/rasterio.cpp (working copy) @@ -70,7 +70,7 @@ GByte *pabySrcBlock = NULL; GDALRasterBlock *poBlock = NULL; int nLBlockX=-1, nLBlockY=-1, iBufYOff, iBufXOff, iSrcY; - + if( eRWFlag == GF_Write && eFlushBlockErr != CE_None ) { CPLError(eFlushBlockErr, CPLE_AppDefined, @@ -368,7 +368,7 @@ for( iDstX = nXOff; iDstX < nXOff + nXSize; iDstX ++) { -iBufXOff = (int)((iDstX - nXOff) / dfSrcXInc); +iBufXOff = (int)((iDstX - nXOff) / dfSrcXInc);
Re: [gdal-dev] Interpolation when using the WMS format
Am 26.09.2014 um 19:22 schrieb Even Rouault : > Peter, > Hi Even, > This is an interesting proof of concept. > > I have several notes : > - not sure about your naming conventions. For me your 'top' and 'bottom' must > be inverted. In imaging convention, the y of top is < to the y of bottom > - the formula is only appropriate for a resampling up to a factor of 2 > - you might have edge effects at block border since you clamp to the current > block. For example, this could be problematic when operating on blocks with a > 1-line height. > - something ready for upstreaming would probably involve adding a new > argument > to RasterIO to specify the resampling method, and as you noted, generalizing > to other data types. > - taking into nodata, alpha channel, etc.. would be necessary > > Would probably be interesting to think if we cannot share code with overview > computation. But not immediately trivial to do so. > I agree with all of the above points. Most choices were made to keep the change simple. > Best regards, > > Even > Regards, Peter >> >> I finally took the time to have a better look at this. >> >> The attached patch is only for our special case, where data arrives in 8 >> bit bands and is certainly far from being decent (I've written my last >> C++ code approx. 15 years ago). Anyway, the image quality seems indeed >> to improve sensibly. >> >> I used the current SVN version as a base for the development. >> >> Applying the patch I get from >> https://dl.dropboxusercontent.com/u/4935329/resampling_tests/basemap.2000x2 >> 000-quasiorig.jpg to this >> https://dl.dropboxusercontent.com/u/4935329/resampling_tests/basemap.2000x2 >> 000.bilinear.jpg . >> >> Anyway, the execution time approximatly doubles (on my 2011 notebook it >> passes from ~ 1.8 s to ~ 3.4 s), which in our case is not really an >> issue, but probaly for almost everybody else. >> >> The command line is, starting from the compilation dir: >> >> apps/gdal_translate -srcwin 3000 23538000 2500 2500 -of JPEG >> -outsize 2000 2000 basemap.xml basemap.2000x2000.bilinear.jpg . >> >> Any comment is highly appreciated. >> >> Regards and a nice weekend, >> >> Peter > > -- > 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
[gdal-dev] Issues when exporting from PostGIS to shape
This email contained a .zip file attachment. Raytheon does not allow email attachments that are considered likely to contain malicious code. For your protection this attachment has been removed. If this email is from an unknown source, please simply delete this email. If this email was expected, and it is from a known sender, you may follow the below suggested instructions to obtain these types of attachments. + Instruct the sender to enclose the file(s) in a ".zip" compressed file, and rename the ".zip" compressed file with a different extension, such as, ".rtnzip". Password protecting the renamed ".zip" compressed file adds an additional layer of protection. When you receive the file, please rename it with the extension ".zip". Additional instructions and options on how to receive these attachments can be found at: http://security.it.ray.com/antivirus/extensions.html http://security.it.ray.com/news/2007/zipfiles.html Should you have any questions or difficulty with these instructions, please contact the Help Desk at 877.844.4712 --- Dear GDAL devs Since I'm new to OGR, the following issues may be caused by my complete ignorance. Anyway, the story goes like this: I have a PostGIS tabel, like this: CREATE TABLE impexp_shp.points ( id serial, name varchar(80), CONSTRAINT points_pkey PRIMARY KEY (id) ); which contains the following: INSERT INTO impexp_shp.points (name, the_geom) VALUES ('così è, Straße, öäü ÖÄÜ è é ò ó ù ú ì í €', ST_GeomFromText('POINT(1 1)',-1)); I try to export this as a shape file: ogr2ogr -f 'ESRI Shapefile' '/tmp/ut_table_with_geom/points' PG:'host=postgis user=unittest dbname=unittest password=unittestx' 'impexpshp.points' And get the attached shape file. I have the following issues with the result: i) The .dbf in this shape file does not contain the column "id". ii) the resulting shape file has a language identifier set to 57 (ANSI), but it really is UTF-8 [1][2]. GDAL is version 1.6.3. PostGIS is version 1.4.1. platform is CentOS 5, 64 bit. Regards, Peter [1] http://support.esri.com/index.cfm?fa=knowledgebase.techArticles.articleShow&d=21106 [2] http://www.dbase.com/knowledgebase/int/db7_file_fmt.htm -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Issues when exporting from PostGIS to shape
Frank Warmerdam wrote: Peter Hopfgartner wrote: i) The .dbf in this shape file does not contain the column "id". Peter, I believe the "id" field is being treated as the feature id, and thus is not exposed as a regular column. This results in it being lost in the translation. I can see that in some circumstances it would be desirable to preserve this as a regular attribute but currently there is no mechanism within the postgres driver itself to accomplish this. One workaround is to do the translation as an explicit user sql command to avoid the automatic handling. eg. ogr2ogr /tmp/ut_table_with_geom/points PG:... \ -sql "select * from impexpshp.points" This works. Thank you. One minor issue: The resulting shape file is names sql_statement. Can I change this name? ii) the resulting shape file has a language identifier set to 57 (ANSI), but it really is UTF-8 [1][2]. That is correct. The Shapefile driver is currently unaware of encoding issues and always marks the generated dbf files with the default (ANSI) setting. Internally OGR attempts to manage text attributes in UTF-8, and the postgres driver does honour that. The Shapefile driver really needs to be upgraded to be encoding aware; however, there are manpower and technical issues around how to do that properly. Where could one start to work on this issue? Is this in the realm of shapelib? We did some analysis on this in our company and maybe we can help with this. Best regards, Thank you, Peter -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Issues when exporting from PostGIS to shape
Frank Warmerdam wrote: Peter Hopfgartner wrote: (...) ii) the resulting shape file has a language identifier set to 57 (ANSI), but it really is UTF-8 [1][2]. That is correct. The Shapefile driver is currently unaware of encoding issues and always marks the generated dbf files with the default (ANSI) setting. Internally OGR attempts to manage text attributes in UTF-8, and the postgres driver does honour that. The Shapefile driver really needs to be upgraded to be encoding aware; however, there are manpower and technical issues around how to do that properly. Where could one start to work on this issue? Is this in the realm of shapelib? We did some analysis on this in our company and maybe we can help with this. Some work would need to be done within shapelib's dbfopen.c code to read and write the encoding indicators. Some work would need to be done in the OGR shapefile driver to translate to UTF-8 when reading and to translate to the target encoding on output with a creation option to control encoding. I am very concerned about compatability issues, so some care would be necessary. There are tickets on the issue that may have some information. Best regards, Hello Frank, as far as I can tell (and resulting from some simple test programs, see attachment), shapelib seems to handle LDID and the cpg file perfectly well, both in reading and writing. I will try to have a look at the OGR code in the next days. Regards, Peter -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.7.2 Release Candidate
Frank Warmerdam wrote: Folks, Today I updated the news file and prepared a 1.7.2 release candidate. The NEWS is available at: http://svn.osgeo.org/gdal/branches/1.7/gdal/NEWS The source files are at: http://download.osgeo.org/gdal/gdal-1.7.2RC1.tar.gz http://download.osgeo.org/gdal/gdal172RC1.zip I regenerated configure with a newer version of autoconf so please keep an eye on possible negative effects that might have had. Testing is encouraged. I'll call for a vote to promote it to official release tomorrow I hope. Best regards, I seem to have problems in configures libdap version guess. On a current CentOS 5.4, x86_64, with some packages taken from EPEL (http://fedoraproject.org/wiki/EPEL) and the attachen spec file, I come until the following error message. g++ -O2 -g -pipe -Wall -fPIC -DPIC -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -I.. -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/port -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/gcore -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/alg -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/ogr -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/ogr/ogrsf_frmts -DOGR_ENABLED -I/usr/include/ogdi -I/usr/include/netcdf-3 -I/usr/include/netcdf -I/usr/include/hdf -I/usr/include/libgeotiff -I/usr/include/libdap -DH5_USE_16_API -I/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/port -Iexternal/include -I/usr/include/netcdf-3 -I/usr/include/cfitsio -I/usr/include/cfitsio/include -I/usr/lib64/include -I/usr/lib64/include/libdap -I/usr/lib64/include/dap -DLIBDAP_39 -c ogrdodsdatasource.cpp -fPIC -DPIC -o ../o/.libs/ogrdodsdatasource.o ogrdodsdatasource.cpp: In member function 'int OGRDODSDataSource::Open(const char*)': ogrdodsdatasource.cpp:197: error: 'class DAS' has no member named 'container' make[3]: *** [../o/ogrdodsdatasource.lo] Error 1 make[3]: Leaving directory `/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/ogr/ogrsf_frmts/dods' make[2]: *** [dods-target] Error 2 make[2]: Leaving directory `/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/ogr/ogrsf_frmts' make[1]: *** [sublibs] Error 2 make[1]: Leaving directory `/home/peter.hopfgartner/rpmbuild/BUILD/gdal-1.7.2-fedora/ogr' make: *** [ogr-target] Error 2 error: Bad exit status from /home/peter.hopfgartner/rpmbuild/tmp/rpm-tmp.81239 (%build) RPM build errors: Bad exit status from /home/peter.hopfgartner/rpmbuild/tmp/rpm-tmp.81239 (%build) The installed libdap is libdap-3.7.8-1.el5.1, whereas it seems that ./configure guesses 3.9 is installed, see attached config.log, where LIBDAP_39 gets defined. Regards, Peter -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 1.7.2 Release Candidate
Ari Jolma wrote: Frank Warmerdam wrote: Folks, Today I updated the news file and prepared a 1.7.2 release candidate. The NEWS is available at: http://svn.osgeo.org/gdal/branches/1.7/gdal/NEWS The source files are at: http://download.osgeo.org/gdal/gdal-1.7.2RC1.tar.gz http://download.osgeo.org/gdal/gdal172RC1.zip I regenerated configure with a newer version of autoconf so please keep an eye on possible negative effects that might have had. Testing is encouraged. I'll call for a vote to promote it to official release tomorrow I hope. On a RHEL x86_64 make dies very fast (after vanilla configure): /home/ajolma/gdal-1.7.2/libtool: line 152: CDPATH: command not found libtool: Version mismatch error. This is libtool 2.1a, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.1a libtool: and run autoconf again. then... sh autogen.sh ./configure make no problems I'm no autotools guru, so can't immediately say what's the problem. Same problem on a ubuntu i686, except that the sh autogen.sh does not fix the problem but reports issues (see below) Ari Best regards, ajo...@ubu:~/gdal-1.7.2$ sh autogen.sh + aclocal -I ./m4 configure.in:56: warning: AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, ), ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... m4/libtool.m4:1261: _LT_COMPILER_OPTION is expanded from... m4/libtool.m4:3377: _LT_COMPILER_PIC is expanded from... m4/libtool.m4:5077: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:122: _LT_SETUP is expanded from... m4/libtool.m4:56: LT_INIT is expanded from... m4/libtool.m4:86: AC_PROG_LIBTOOL is expanded from... configure.in:56: the top level configure.in:56: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached m4/libtool.m4:1313: _LT_LINKER_OPTION is expanded from... configure.in:56: warning: AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, CXX), ...): suspicious cache-id, must contain _cv_ to be cached m4/libtool.m4:5184: _LT_LANG_CXX_CONFIG is expanded from... m4/libtool.m4:771: _LT_LANG is expanded from... m4/libtool.m4:754: LT_LANG is expanded from... m4/libtool.m4:782: _LT_LANG_DEFAULT_CONFIG is expanded from... configure.in:56: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached + autoconf configure.in:56: warning: AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, ), ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2039: AC_CACHE_CHECK is expanded from... m4/libtool.m4:1261: _LT_COMPILER_OPTION is expanded from... m4/libtool.m4:3377: _LT_COMPILER_PIC is expanded from... m4/libtool.m4:5077: _LT_LANG_C_CONFIG is expanded from... m4/libtool.m4:122: _LT_SETUP is expanded from... m4/libtool.m4:56: LT_INIT is expanded from... m4/libtool.m4:86: AC_PROG_LIBTOOL is expanded from... configure.in:56: the top level configure.in:56: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached m4/libtool.m4:1313: _LT_LINKER_OPTION is expanded from... configure.in:56: warning: AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, CXX), ...): suspicious cache-id, must contain _cv_ to be cached m4/libtool.m4:5184: _LT_LANG_CXX_CONFIG is expanded from... m4/libtool.m4:771: _LT_LANG is expanded from... m4/libtool.m4:754: LT_LANG is expanded from... m4/libtool.m4:782: _LT_LANG_DEFAULT_CONFIG is expanded from... configure.in:56: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious cache-id, must contain _cv_ to be cached ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Could you try with ./configure --without-libtool ? Peter -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Compilation problems on CentOS 5
Hello I'm trying to compile GDAL 1.7.2 on my CentOS 5.4, 64 bit box. Configure is basically "enable Oracle, disable almost anything else": ./configure --without-php --without-python --without-perl --with-oci --with-ecw --with-libtiff=internal --with-geotiff=internal --with-netcdf=no --with-cfitsio=no Compilation stops with: libtool: link: g++ .libs/gdalinfo.o -o .libs/gdalinfo /home/rpmbuild/tmp/gdal-1.7.2/.libs/libgdal.so -Wl,-rpath -Wl,/usr/local/lib /home/rpmbuild/tmp/gdal-1.7.2/.libs/libgdal.so: undefined reference to `XML_StopParser' collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make[1]: Leaving directory `/home/rpmbuild/tmp/gdal-1.7.2/apps' make: *** [apps-target] Error 2 Where should the symbol "XML_StopParser" come from? The same configure works perfectly with 1.6.3 on the same box. Regards, peter -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: Re: [gdal-dev] Compilation problems on CentOS 5
Frank, compilation went smooth using the --without-expat option. On CentOS 5.4, expat cames as expat-1.95.8. Thank you for your halp Peter Frank Warmerdam wrote Subject: Re: [gdal-dev] Compilation problems on CentOS 5 Date: 07.05.2010 17:36 >Peter Hopfgartner wrote: >> Hello >> >> I'm trying to compile GDAL 1.7.2 on my CentOS 5.4, 64 bit box. >Configure >> is basically "enable Oracle, disable almost anything else": >> >> ./configure --without-php --without-python --without-perl --with-oci >> --with-ecw --with-libtiff=internal --with-geotiff=internal >> --with-netcdf=no --with-cfitsio=no >> >> Compilation stops with: >> >> libtool: link: g++ .libs/gdalinfo.o >> -o .libs/gdalinfo /home/rpmbuild/tmp/gdal-1.7.2/.libs/libgdal.so >> -Wl,-rpath -Wl,/usr/local/lib >> /home/rpmbuild/tmp/gdal-1.7.2/.libs/libgdal.so: undefined reference to >> `XML_StopParser' >> collect2: ld returned 1 exit status >> make[1]: *** [gdalinfo] Error 1 >> make[1]: Leaving directory `/home/rpmbuild/tmp/gdal-1.7.2/apps' >> make: *** [apps-target] Error 2 >> >> Where should the symbol "XML_StopParser" come from? > >Peter, > >This is part of the expat library. You could try configuring >--without-expat >to doing a clean build. I'm guessing you have a version of expat that is >too >old, or too new and lacks XML_StopParser. If you could provide version >information it might make it possible for us to dig further into the >issue. > >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] Re: Writing non-ASCII characters to shapefile
Hi Francis, what does not portable mean? ArcMap handles UTF-8 fine, if the correct encoding is written into the .cpg file. Recent shapelib should handle this fine, too. If there is any problem with a specific GIS program, a bug report for that GIS program might be the right thing to do. Regards, Peter On Mon, 2010-07-05 at 19:18 +1000, Francis Markham wrote: > At the bottom of this page, for one: > http://resources.arcgis.com/content/kbase?fa=articleShow&d=21106 > > But honestly I've found hard to find information about this. I'd be > very happy to be corrected if this is not the case! > > Cheers, > > Francis > > On 5 July 2010 19:09, Hermann Peifer wrote: > > Francis, you wrote: > > > >> > I have heard that the use of UTF-8 in shapefiles is not portable. > > > > Where did you hear this? > > > > Regards, Hermann > > > > > > On 03/07/2010 04:40, Francis Markham wrote: > >> > >> Hi there, > >> > >> I'm trying to write data from a Microsoft Excel .xls file into a > >> shapefile, using OGR's Python bindings in Python 2.6. This is going > >> well, but I am having some problems when I try to write values that > >> contain so-called "smart quotes". Smart quotes are special > >> characters, defined as characters 0x91 through 0x94 in Windows-1252 ( > >> see http://msdn.microsoft.com/en-au/goglobal/cc305145.aspx ). > >> > >> What is the best way to save this data to a shapefile using OGR? I > >> need the shapefile to be interoperable with other programs, including > >> but not limited to ESRI products. While I assume I could simply > >> translate these characters to standard ASCII, I would prefer not to if > >> possible. I also haven't tested the shapefiles with data from other > >> character encodings. > >> > >> I have heard that the use of UTF-8 in shapefiles is not portable. I > >> am also aware that shapefile.cpg can store a shapefile's codepage. I > >> don't know how to put these pieces together to create a portable > >> solution, however. > >> > >> Apologies if this is a newbie question, but I can't find answers on the > >> web. > >> > >> Thanks, > >> > >> Francis Markham > > > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Dott. Peter Hopfgartner R3 GIS Srl - GmbH Via Johann Kravogl-Str. 2 I-39012 Meran/Merano (BZ) Email: peter.hopfgart...@r3-gis.com Tel. : +39 0473 494949 Fax : +39 0473 069902 www : http://www.r3-gis.com XING : http://www.xing.com/go/invita/8917535 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] GDAL/OGR 1.7.3 Release Candidate
Since this one affected me, I would like to ask if the fix for http://trac.osgeo.org/gdal/ticket/3411 is included? Regards, Peter R3 GIS Srl - GmbH http://www.r3-gis.com Frank Warmerdam wrote Subject: [gdal-dev] GDAL/OGR 1.7.3 Release Candidate Date: 07.11.2010 03:49 >Folks, > >I have a GDAL/OGR 1.7.3 release candidate available at last. I had to >hold >off last week as the autotests were failing in hard to track down ways. > > http://download.osgeo.org/gdal/gdal-1.7.3RC1.tar.gz > http://download.osgeo.org/gdal/gdal173RC1.zip > >I have preliminary release notes at: > > http://trac.osgeo.org/gdal/wiki/Release/1.7.3-News > >I have also packaged up the current 1.7 version of the autotest at: > > http://download.osgeo.org/gdal/gdalautotest-1.7.3.tar.gz > >I would appreciate feedback on issues with the release candidate. I'll >call >for a vote early in the week if it looks ok. > >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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release
I wrapped a quick rpm package, installed the rpms and tried to run autotest. The tests comes to this point: Running tests from gcore/mask.py TEST: mask_1 ... success TEST: mask_2 ... success TEST: mask_3 ... success TEST: mask_4 ... success TEST: mask_5 ... ERROR 1: ZIPDecode:tmp/mask_4.pnm.msk: Decoding error at scanline 0, incorrect header check ERROR 1: TIFFReadEncodedTile() failed. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 Segmentation fault The platform id CentOS 5.5/x86_64, with some packages from EPEL and elgis. Regards, Peter Hopfgartner R3 GIS Srl - GmbH http://www.r3-gis.com Frank Warmerdam wrote Subject: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release Date: 08.11.2010 21:22 >Motion: Promote GDAL/OGR 1.7.3RC2 to final release > >--- > >PSC members, > >I've run the autotests in a few environments and things seems solid >to me. Please vote when you have had a chance to examine the release >candidate. Anyone else who finds problems should also speak up of >course. > >+1 Frank > >-- >---+-- >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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: Re: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release
Hi Frank, I had to disable mask_5 to mask_10 and ecw_6, which threw another Exception. Now the result looks like: Failures Script: ogr/ogr_s57.py TEST: ogr_s57_2 ... fail Expected 2 layer type in layer COALNE, but got 0. Script: gcore/tiff_write.py TEST: tiff_write_55 ... fail failed to preserve Equirectangular projection as expected, old libgeotiff? Script: gdrivers/pds.py TEST: pds_4 ... fail Checksum for band 1 in "pds_3177.lbl" is 3293, but expected 4028. Script: gdrivers/gxf.py TEST: gxf_1 ... fail Checksum for band 1 in "small.gxf" is 90, but expected 88. Script: gdrivers/ecw.py TEST: ecw_10 ... fail (blowup) -- Test Script: utilities/test_ogrtindex.py Succeeded: 1570 Failed:5 (1 blew exceptions) Skipped: 240 Expected fail:1 As GDAL_DOWNLOAD_TEST_DATA environment variable is not defined, 67 tests relying on data to downloaded from the Web have been skipped Talking about libtiff4 in elgis is concerned, there is really no hurry. Cheers, Peter R3 GIS Srl - GmbH http://www.r3-gis.com Frank Warmerdam wrote Subject: Re: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release Date: 09.11.2010 17:22 >Peter Hopfgartner wrote: >> Hi Frank, >> >> gdal was configured with: >> >> --with-geotiff=external \ >> --with-tiff=external \ >> --with-libtiff=external \ >> >> and libtiff is the one that comes with CentOS 5.5: >> >> [rpmbu...@rpm-devel gdalautotest-1.7.0]$ rpm -qa | grep tiff >> libgeotiff-1.2.4-3.el5 >> libtiff-devel-3.8.2-7.el5_5.5 >> libgeotiff-devel-1.2.4-3.el5 >> libtiff-3.8.2-7.el5_5.5 > >Peter, > >Well, that explains it. Passing the autotest suite will require a >substantially newer libtiff. I would suggest you just disregard tiff >related failures, and remove any tiff related scripts that cause a >crash. > >But this sensitivity of GDAL to libtiff bugs is the reason I advocate for >having libtiff4 available for GDAL, though hopefully in a way that does >not interfere with the system libtiff. > >I'm sorry I haven't been able to follow up on that on the EL mailing list >as I've backburnered my RPM work for a few days. > >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: Re: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release
Hi Frank, gdal was configured with: --with-geotiff=external \ --with-tiff=external \ --with-libtiff=external \ and libtiff is the one that comes with CentOS 5.5: [rpmbu...@rpm-devel gdalautotest-1.7.0]$ rpm -qa | grep tiff libgeotiff-1.2.4-3.el5 libtiff-devel-3.8.2-7.el5_5.5 libgeotiff-devel-1.2.4-3.el5 libtiff-3.8.2-7.el5_5.5 Regards, Peter R3 GIS Srl - GmbH http://www.r3-gis.com Frank Warmerdam wrote Subject: Re: [gdal-dev] Motion: Promote GDAL/OGR 1.7.3RC2 to final release Date: 09.11.2010 16:32 >Peter Hopfgartner wrote: >> I wrapped a quick rpm package, installed the rpms and tried to run >autotest. The tests comes to this point: >> >> Running tests from gcore/mask.py >> TEST: mask_1 ... success >> TEST: mask_2 ... success >> TEST: mask_3 ... success >> TEST: mask_4 ... success >> TEST: mask_5 ... ERROR 1: ZIPDecode:tmp/mask_4.pnm.msk: Decoding >error at scanline 0, incorrect header check >> ERROR 1: TIFFReadEncodedTile() failed. >> >> ERROR 1: IReadBlock failed at X offset 0, Y offset 0 >> ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 >> Segmentation fault >> >> The platform id CentOS 5.5/x86_64, with some packages from EPEL and >elgis. > >Peter, > >What libtiff is this using? Internal? External libtiff4? libtiff3.x? > >The test suite pushes many boundary cases that only work with the latest >libtiff4 code particularly because GDAL tends to be the client that >pushes the boundaries of libtiff. > >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
[gdal-dev] Can not run ogr2ogr from a web server running PHP
I'm trying to run ogr2ogr from a PHP script. This runs fine, if the script is run from the command line. It does not work if run through the web server. The scripts basically runs: /usr/local/bin/ogr2ogr -f 'ESRI Shapefile' '/tmp/tmp_plant_cfa4f818c6c5c1e7881b' 'OCI:plantmap/plantm...@plantmap' -sql 'SELECT * FROM tmp_plant_cfa4f818c6c5c1e7881b' -nln plant and returns the error: ERROR 1: ORA-12504: TNS:listener was not given the SERVICE_NAME in CONNECT_DATA in ORACLE_HOME, ORACLE_SID, ORACLE_HOME are set in the web server init script (the whole application runs with Oracle). I tried to enforce the variables in the virtual host fragment in httpd.conf: SetEnv ORACLE_HOME /u01/app/oracle/product/11.1.0/db_1 SetEnv ORACLE_SID plantmap SetEnv ORACLE_OWNER oracle If I run a little test script, like: #!/bin/sh echo $ORACLE_HOME echo $ORACLE_SID echo $LD_LIBRARY_PATH the environment variables are set correctly. So why can't ogr2ogr find the correct Oracle instance? Platform: RHEL 5, 64 bit, Oracle 11.1 Regards, Peter Hopfgartner R3 GIS Srl - GmbH http://www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: Re: [gdal-dev] Can not run ogr2ogr from a web server running PHP
Hi Pavel. Thanks for your quick response. Anyway, I did the following test: I have a PHP file (env.php): /u01/app/oracle/product/11.1.0/db_1 [1] => plantmap [2] => oracle [3] => :/u01/app/oracle/product/11.1.0/db_1/lib ) , so the environment variables are passed correctly to the called application. Are there any other env. variables relevant for ogr2ogr when reading an Oracle DB? Regards, Peter R3 GIS Srl - GmbH http://www.r3-gis.com Pavel Iacovlev wrote Subject: Re: [gdal-dev] Can not run ogr2ogr from a web server running PHP Date: 21.12.2010 16:11 >Your environment variables are set for your current user, apache usually >runs as www-data or nobody user. >Use http://md.php.net/putenv to set your environment variables this will >work both from apache and from CLI. > >On Tue, Dec 21, 2010 at 4:51 PM, Peter Hopfgartner < >peter.hopfgart...@r3-gis.com> wrote: > >> I'm trying to run ogr2ogr from a PHP script. This runs fine, if the >script >> is run from the command line. It does not work if run through the web >> server. >> >> The scripts basically runs: >> >> /usr/local/bin/ogr2ogr -f 'ESRI Shapefile' >> '/tmp/tmp_plant_cfa4f818c6c5c1e7881b' 'OCI:plantmap/plantm...@plantmap' >> -sql 'SELECT * FROM tmp_plant_cfa4f818c6c5c1e7881b' -nln plant >> >> and returns the error: >> ERROR 1: ORA-12504: TNS:listener was not given the SERVICE_NAME in >> CONNECT_DATA >> in >> >> ORACLE_HOME, ORACLE_SID, ORACLE_HOME are set in the web server init >script >> (the whole application runs with Oracle). >> I tried to enforce the variables in the virtual host fragment in >> httpd.conf: >>SetEnv ORACLE_HOME /u01/app/oracle/product/11.1.0/db_1 >>SetEnv ORACLE_SID plantmap >>SetEnv ORACLE_OWNER oracle >> >> If I run a little test script, like: >> #!/bin/sh >> echo $ORACLE_HOME >> echo $ORACLE_SID >> echo $LD_LIBRARY_PATH >> >> the environment variables are set correctly. >> So why can't ogr2ogr find the correct Oracle instance? >> >> Platform: RHEL 5, 64 bit, Oracle 11.1 >> >> Regards, >> >> Peter Hopfgartner >> >> R3 GIS Srl - GmbH >> http://www.r3-gis.com >> >> >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > >-- >http://iap.md, The future is open > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Copyright notices for SWIG/PHP
http://wiki.osgeo.org/wiki/GDAL_Provenance_Review lists the PHP bindings as lacking copyright headers. If I got it right, this prevents Fedora to build those bindings. Is there any chance to get those copyright into the headers? Has the original author been MIA? Thanks, Peter R3 GIS Srl - GmbH http://www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] New PHP bindings - php5-gdal
On 08/09/2011 12:32 AM, Jean-François Gigand wrote: Hi, I am writing a PHP 5 module providing bindings for GDAL and OGR. This would be a very usefull addition to GDAL. It is GPL3-licensed and available here: http://projects.geonef.fr/projects/php5-gdal/wiki I'm wondering if it would'nt be more apprioprato to use the same license as GDAL itself, see http://www.gdal.org. BTW: I'm not able to access to the above mentioned address. It is far from complete, bindings are available for about a third of the C++ interfaces. I have been working on/with it for 8 months yet, and recently using it on a production website as well. I actually wrote the bindings I needed so far, the rest will follow little by little, and any contribution is welcome. php5-gdal provides PHP classes for the equivalent C++ class, same for the methods. The C macro constants of GDAL/OGR are brought to PHP as global constants. I decided to write this library when I got limited at using OGR/PHP (segfault crash) and noticed the latter has not been maintained for years. After trying to compile the SWIG bindings with no success, I thought a good robust C++ code would be the best deal for providing OOP interfaces to PHP. As the GPL summary says, I hope that this library will be useful! There is a dedicated ML, info on http://ml.geonef.fr/mailman/listinfo/php5-gdal-dev Best regards, Jean-François Gigand - Geonef Paris, France - http://geonef.fr/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Peter ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Issue GDAL with JPEG-compressed TIFFS
I'm doing quite some experiments with GDAL and image compression these days I do have an issue with geotiff 1.3/gdal 1.8.1 on CentOS 6 with packages from ELGIS. The story goes like this: I create tiffs with gdal_translate -of GTiff -co COMPRESS=JPEG -co JPEG_QUALITY=90 -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" and then add overviews with (I do have to add the overlays in distinct steps, otherwise gdaladdo aborts with an error message). gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 3 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 9 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 27 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 81 (Trying with power-of-2-steps gives the same result. If I drop all options from gdaladdo: same result). I'll create a WMS service with MapServer 5.6.7 and do get a big red square in the image. The square is "fixed" to the geografical position, e.g. if I move the extend the square moves too. The square is situated in the corner of the tiff file. It appears only at some scales. If I change it very slightly, the square remqins, if I change for more then approx 1%, it disappears. I've put the two images at http://www.r3-gis.com/gdal_issues/tiff_with_jpegcompression_and_overviews.jpeg and http://www.r3-gis.com/gdal_issues/tiff_with_nocompression_and_overviews.jpeg . The problem disappears if I do not run gdaladdo on the images or when I do not use Jpeg compression: gdal_translate -of GTiff -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" There are some hits for http://www.google.com/search?client=ubuntu&channel=fs&q=mapserver+artefacts+in+raster+gdal&ie=utf-8&oe=utf-8, but mostly related to older versions of GDAL and without resolution. Thanks, Peter -- Peter Hopfgartner R3 GIS Srl - GmbH www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Issue GDAL with JPEG-compressed TIFFS
Hi Evan Indeed, the external libtiff is used and is version libtiff-3.9.4-1.el6_0.3.x86_64. In the mean time I did a quick compile of gdal-1.9.0 with internal libtiff and the square disappeared. Probably it would be a wise decision to switch to libtiff4 quickly, as far as ELGIS is concerned. Thanks, Peter On 02/03/2012 01:41 PM, Even Rouault wrote: Peter, Does ELGIS GDAL uses internal libtiff (4.0beta) or external libtiff (3.8 or 3.9) ? I guess it is external libtiff, and then it could explain the issues you have with overviews and JPEG compression. There have been fixes in libtiff 4 to better support that situation (multiple IFDs with compression). Altertantively, you could probably workaround that by generating external overviews (add -ro to the gdaladdo command line), but no guarantees. By the way, the --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 options only apply to external overviews, not internal ones. I'm doing quite some experiments with GDAL and image compression these days I do have an issue with geotiff 1.3/gdal 1.8.1 on CentOS 6 with packages from ELGIS. The story goes like this: I create tiffs with gdal_translate -of GTiff -co COMPRESS=JPEG -co JPEG_QUALITY=90 -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" and then add overviews with (I do have to add the overlays in distinct steps, otherwise gdaladdo aborts with an error message). gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 3 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 9 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 27 gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 90 -r average 81 (Trying with power-of-2-steps gives the same result. If I drop all options from gdaladdo: same result). I'll create a WMS service with MapServer 5.6.7 and do get a big red square in the image. The square is "fixed" to the geografical position, e.g. if I move the extend the square moves too. The square is situated in the corner of the tiff file. It appears only at some scales. If I change it very slightly, the square remqins, if I change for more then approx 1%, it disappears. I've put the two images at http://www.r3-gis.com/gdal_issues/tiff_with_jpegcompression_and_overviews.jpeg and http://www.r3-gis.com/gdal_issues/tiff_with_nocompression_and_overviews.jpeg . The problem disappears if I do not run gdaladdo on the images or when I do not use Jpeg compression: gdal_translate -of GTiff -co "TILED=YES" -co "BLOCKXSIZE=512" -co "BLOCKYSIZE=512" There are some hits for http://www.google.com/search?client=ubuntu&channel=fs&q=mapserver+artefacts+in+raster+gdal&ie=utf-8&oe=utf-8, but mostly related to older versions of GDAL and without resolution. Thanks, Peter -- Peter Hopfgartner R3 GIS Srl - GmbH www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter Hopfgartner R3 GIS Srl - GmbH web : www.r3-gis.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev