<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hi Jorge,<br>Did you receive my email with the files requested? I used an other adresse to send you the files.<br><br>David<br><br><div><div id="SkyDrivePlaceholder"></div>> From: jorgearevalo@libregis.org<br>> Date: Mon, 28 May 2012 10:07:09 +0200<br>> To: postgis-users@postgis.refractions.net<br>> Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9<br>> <br>> Hi,<br>> <br>> David, could you please attach the original files? Seems to be a<br>> problem with the way the driver gets the origin of the raster<br>> coverage, yes.<br>> <br>> The code in GDAL trunk is under development. Slowness problem is one<br>> of the reasons.<br>> <br>> Best regards,<br>> Jorge<br>> <br>> On Tue, May 22, 2012 at 7:01 PM, David B�langer <belanger_david@live.ca> wrote:<br>> > Hi,<br>> > I did tests and all gave the result expected. It seem to be a problem with<br>> > the origin of the result file (see attached file). The application has taken<br>> > the origin of the file 056n05_0100_deme.tif instead of the origin of the<br>> > file 056n05_0100_demw.tif. What do you think ?<br>> ><br>> > For your information the files are in geographic coordinate system.<br>> ><br>> > David<br>> ><br>> >> From: Pierre.Racine@sbf.ulaval.ca<br>> >> To: postgis-users@postgis.refractions.net<br>> >> Date: Tue, 22 May 2012 11:37:03 -0400<br>> ><br>> >> Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9<br>> >><br>> >> I would maybe do some tests:<br>> >><br>> >> 1) Remove the -a_nodata "-32767" parameter. Why did you have to set it? Is<br>> >> the nodata set properly in PostGIS for all rows?<br>> >><br>> >> 2) Extract one file at a time with mode=2 and then with mode=1<br>> >><br>> >> Pierre<br>> >><br>> >> > -----Original Message-----<br>> >> > From: postgis-users-bounces@postgis.refractions.net<br>> >> > [mailto:postgis-users-<br>> >> > bounces@postgis.refractions.net] On Behalf Of David B?langer<br>> >> > Sent: Tuesday, May 22, 2012 10:25 AM<br>> >> > To: postgis-users@postgis.refractions.net<br>> >> > Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9<br>> >> ><br>> >> > Hi Pierre,<br>> >> > Yes I have a unique rid (Integer) with sequential number. I used the<br>> >> > tool<br>> >> > raster2pgsql.exe to upload the data in the database. I uploaded 2 files<br>> >> ><br>> >> > 056n05_0100_deme.tif<br>> >> > 056n05_0100_demw.tif<br>> >> ><br>> >> > "C:\Program Files\PostgreSQL\9.1\bin\raster2pgsql.exe" -I -e -Y -F -s<br>> >> > 4269<br>> >> > e:\dir\*.tif dbelange.elevationTest | "psql.exe" -U myuser -d myDB -h<br>> >> > myhost -p<br>> >> > 14070<br>> >> ><br>> >> > I used this command to extract data:<br>> >> > "C:\Program Files\GDAL\gdal_translate" -a_nodata "-32767" -of GTIFF<br>> >> > "PG:host=myhost port=14070 dbname='myDB' user='myuser'<br>> >> > password='mypassword' schema='dbelange' table='elevationTest' mode=2<br>> >> > where=\"filename LIKE \'%056n05%\'\" " 056N05_testGDAL1.9.tif<br>> >> ><br>> >> > Like I said it’s working very well with gdal 1.8<br>> >> ><br>> >> > I can send you the 2 files If you want to try on your side.<br>> >> ><br>> >> > Do you have another idea?<br>> >> ><br>> >> > David<br>> >> ><br>> >> ><br>> >> > > From: Pierre.Racine@sbf.ulaval.ca<br>> >> > > To: postgis-users@postgis.refractions.net<br>> >> > > Date: Sat, 19 May 2012 13:55:47 -0400<br>> >> > > Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9<br>> >> > ><br>> >> > > Hi David,<br>> >> > ><br>> >> > > Do you have a "rid" column in your table with unique values?<br>> >> > ><br>> >> > > Pierre<br>> >> > ><br>> >> > > > -----Original Message-----<br>> >> > > > From: postgis-users-bounces@postgis.refractions.net<br>> >> > > > [mailto:postgis-users-<br>> >> > > > bounces@postgis.refractions.net] On Behalf Of David B?langer<br>> >> > > > Sent: Thursday, May 17, 2012 8:13 PM<br>> >> > > > To: postgis-users@postgis.refractions.net<br>> >> > > > Subject: [postgis-users] PostGis Raster and GDAL 1.9<br>> >> > > ><br>> >> > > > Hi,<br>> >> > > > I stored DEM raster data in PostGIS 2.0 and I used gdal_translate<br>> >> > > > (with<br>> >> > mode=2)<br>> >> > > > to extract a mosaic of tiles. When I’m using GDAL 1.8 is working but<br>> >> > > > when<br>> >> > I’m<br>> >> > > > using GDAL 1.9 I can see the values of pixel for just one tile. For<br>> >> > > > example I<br>> >> > > > uploaded in the database a tile with an attribute filename=056n05_w<br>> >> > > > and an<br>> >> > > > other tile with an filename=056n05_e and I executed the command with<br>> >> > GDAL<br>> >> > > > 1.8 and GDAL 1.9:<br>> >> > > ><br>> >> > > > gdal_translate" -a_nodata "-32767" -of GTIFF "PG:host=myhost<br>> >> > > > port=14070<br>> >> > > > dbname='mybd' user='myuser' password='mypassword'<br>> >> > > > schema='myschema'table='Elevation' mode=2 where=\"filename LIKE<br>> >> > > > \'%056n05%\'\" " 056N05.tif<br>> >> > > ><br>> >> > > > With GDAL 1.8 I obtained a mosaic of 2 tiles (the result expected)<br>> >> > > > but with<br>> >> > GDAL<br>> >> > > > 1.9, I obtained a raster with the same extent but only the values of<br>> >> > > > the tile<br>> >> > > > 056n05_w are present. The pixels of the tile 056n05_w have a value<br>> >> > > > 0.<br>> >> > > ><br>> >> > > > I tried the stable version 1.9 MSVC2008 (Win32) and development<br>> >> > > > version<br>> >> > > > available today at http://www.gisinternals.com/sdk/<br>> >> > > ><br>> >> > <https://email.nrcan.gc.ca/owa/redir.aspx?C=OzXx4wlk90m3TV7W8fzG7_FxObj<br>> >> > > ><br>> >> > PB88I1bAwXOtZColSmDyhIvj_1yhbCVJUJ0vrnCWWTuivB9Y.&URL=http://www.g<br>> >> > > > isinternals.com/sdk/> and I have still the same problem. For your<br>> >> > information,<br>> >> > > > I'm running GDAL on windows7 and PostGIS 2.0 is installed on a Linux<br>> >> > > > server.<br>> >> > I<br>> >> > > > tried many version of GDAL 1.9 and I always have the same problem.<br>> >> > > > The<br>> >> > version<br>> >> > > > 1.8 is working very well but I would like to take advantage of the<br>> >> > improvements<br>> >> > > > in the last version because I'm working on a project where<br>> >> > > > processing time is<br>> >> > > > very important.<br>> >> > > ><br>> >> > > > Does anybody have any idea about this problem ?<br>> >> > > ><br>> >> > > > Thanks<br>> >> > > ><br>> >> > > > David Bélanger<br>> >> > ><br>> >> > > _______________________________________________<br>> >> > > postgis-users mailing list<br>> >> > > postgis-users@postgis.refractions.net<br>> >> > > http://postgis.refractions.net/mailman/listinfo/postgis-users<br>> >><br>> >> _______________________________________________<br>> >> postgis-users mailing list<br>> >> postgis-users@postgis.refractions.net<br>> >> http://postgis.refractions.net/mailman/listinfo/postgis-users<br>> ><br>> > _______________________________________________<br>> > postgis-users mailing list<br>> > postgis-users@postgis.refractions.net<br>> > http://postgis.refractions.net/mailman/listinfo/postgis-users<br>> ><br>> <br>> <br>> <br>> -- <br>> Jorge Arevalo<br>> http://www.libregis.org<br>> _______________________________________________<br>> postgis-users mailing list<br>> postgis-users@postgis.refractions.net<br>> http://postgis.refractions.net/mailman/listinfo/postgis-users<br></div> </div></body>
</html>