[gdal-dev] Interpolation when using the WMS format

2014-09-18 Thread Peter Hopfgartner 

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

2014-09-18 Thread Peter Hopfgartner 
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

2014-09-19 Thread 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.
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

2014-09-19 Thread Peter Hopfgartner 

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

2014-09-19 Thread Peter Hopfgartner 

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

2014-09-19 Thread Peter Hopfgartner 

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

2014-09-26 Thread Peter Hopfgartner 

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

2014-09-26 Thread Peter Hopfgartner 

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

2010-03-10 Thread Peter Hopfgartner 
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

2010-03-10 Thread Peter Hopfgartner 

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

2010-03-13 Thread Peter Hopfgartner 

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

2010-04-21 Thread Peter Hopfgartner 

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

2010-04-21 Thread Peter Hopfgartner 

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

2010-05-07 Thread Peter Hopfgartner 
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

2010-05-10 Thread Peter Hopfgartner 
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

2010-07-05 Thread Peter Hopfgartner 
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

2010-11-09 Thread Peter Hopfgartner 
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

2010-11-09 Thread Peter Hopfgartner 
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

2010-11-09 Thread Peter Hopfgartner 
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

2010-11-09 Thread Peter Hopfgartner 
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

2010-12-21 Thread Peter Hopfgartner 
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

2010-12-21 Thread Peter Hopfgartner 
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

2011-04-14 Thread Peter Hopfgartner 
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

2011-08-09 Thread Peter Hopfgartner 

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

2012-02-03 Thread Peter Hopfgartner 

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

2012-02-03 Thread Peter Hopfgartner 

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