Re: PostGis Raster and GDAL 1.9
2012-06-01 00:54:37 GMT
Did you receive my email with the files requested? I used an other adresse to send you the files.
David
> Date: Mon, 28 May 2012 10:07:09 +0200
> To: postgis-users <at> postgis.refractions.net
> Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9
>
> Hi,
>
> David, could you please attach the original files? Seems to be a
> problem with the way the driver gets the origin of the raster
> coverage, yes.
>
> The code in GDAL trunk is under development. Slowness problem is one
> of the reasons.
>
> Best regards,
> Jorge
>
> On Tue, May 22, 2012 at 7:01 PM, David B�langer <belanger_david <at> live.ca> wrote:
> > Hi,
> > I did tests and all gave the result expected. It seem to be a problem with
> > the origin of the result file (see attached file). The application has taken
> > the origin of the file 056n05_0100_deme.tif instead of the origin of the
> > file 056n05_0100_demw.tif. What do you think ?
> >
> > For your information the files are in geographic coordinate system.
> >
> > David
> >
> >> From: Pierre.Racine <at> sbf.ulaval.ca
> >> To: postgis-users <at> postgis.refractions.net
> >> Date: Tue, 22 May 2012 11:37:03 -0400
> >
> >> Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9
> >>
> >> I would maybe do some tests:
> >>
> >> 1) Remove the -a_nodata "-32767" parameter. Why did you have to set it? Is
> >> the nodata set properly in PostGIS for all rows?
> >>
> >> 2) Extract one file at a time with mode=2 and then with mode=1
> >>
> >> Pierre
> >>
> >> > -----Original Message-----
> >> > From: postgis-users-bounces <at> postgis.refractions.net
> >> > [mailto:postgis-users-
> >> > bounces <at> postgis.refractions.net] On Behalf Of David B?langer
> >> > Sent: Tuesday, May 22, 2012 10:25 AM
> >> > To: postgis-users <at> postgis.refractions.net
> >> > Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9
> >> >
> >> > Hi Pierre,
> >> > Yes I have a unique rid (Integer) with sequential number. I used the
> >> > tool
> >> > raster2pgsql.exe to upload the data in the database. I uploaded 2 files
> >> >
> >> > 056n05_0100_deme.tif
> >> > 056n05_0100_demw.tif
> >> >
> >> > "C:\Program Files\PostgreSQL\9.1\bin\raster2pgsql.exe" -I -e -Y -F -s
> >> > 4269
> >> > e:\dir\*.tif dbelange.elevationTest | "psql.exe" -U myuser -d myDB -h
> >> > myhost -p
> >> > 14070
> >> >
> >> > I used this command to extract data:
> >> > "C:\Program Files\GDAL\gdal_translate" -a_nodata "-32767" -of GTIFF
> >> > "PG:host=myhost port=14070 dbname='myDB' user='myuser'
> >> > password='mypassword' schema='dbelange' table='elevationTest' mode=2
> >> > where=\"filename LIKE \'%056n05%\'\" " 056N05_testGDAL1.9.tif
> >> >
> >> > Like I said it’s working very well with gdal 1.8
> >> >
> >> > I can send you the 2 files If you want to try on your side.
> >> >
> >> > Do you have another idea?
> >> >
> >> > David
> >> >
> >> >
> >> > > From: Pierre.Racine <at> sbf.ulaval.ca
> >> > > To: postgis-users <at> postgis.refractions.net
> >> > > Date: Sat, 19 May 2012 13:55:47 -0400
> >> > > Subject: Re: [postgis-users] PostGis Raster and GDAL 1.9
> >> > >
> >> > > Hi David,
> >> > >
> >> > > Do you have a "rid" column in your table with unique values?
> >> > >
> >> > > Pierre
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: postgis-users-bounces <at> postgis.refractions.net
> >> > > > [mailto:postgis-users-
> >> > > > bounces <at> postgis.refractions.net] On Behalf Of David B?langer
> >> > > > Sent: Thursday, May 17, 2012 8:13 PM
> >> > > > To: postgis-users <at> postgis.refractions.net
> >> > > > Subject: [postgis-users] PostGis Raster and GDAL 1.9
> >> > > >
> >> > > > Hi,
> >> > > > I stored DEM raster data in PostGIS 2.0 and I used gdal_translate
> >> > > > (with
> >> > mode=2)
> >> > > > to extract a mosaic of tiles. When I’m using GDAL 1.8 is working but
> >> > > > when
> >> > I’m
> >> > > > using GDAL 1.9 I can see the values of pixel for just one tile. For
> >> > > > example I
> >> > > > uploaded in the database a tile with an attribute filename=056n05_w
> >> > > > and an
> >> > > > other tile with an filename=056n05_e and I executed the command with
> >> > GDAL
> >> > > > 1.8 and GDAL 1.9:
> >> > > >
> >> > > > gdal_translate" -a_nodata "-32767" -of GTIFF "PG:host=myhost
> >> > > > port=14070
> >> > > > dbname='mybd' user='myuser' password='mypassword'
> >> > > > schema='myschema'table='Elevation' mode=2 where=\"filename LIKE
> >> > > > \'%056n05%\'\" " 056N05.tif
> >> > > >
> >> > > > With GDAL 1.8 I obtained a mosaic of 2 tiles (the result expected)
> >> > > > but with
> >> > GDAL
> >> > > > 1.9, I obtained a raster with the same extent but only the values of
> >> > > > the tile
> >> > > > 056n05_w are present. The pixels of the tile 056n05_w have a value
> >> > > > 0.
> >> > > >
> >> > > > I tried the stable version 1.9 MSVC2008 (Win32) and development
> >> > > > version
> >> > > > available today at http://www.gisinternals.com/sdk/
> >> > > >
> >> > <https://email.nrcan.gc.ca/owa/redir.aspx?C=OzXx4wlk90m3TV7W8fzG7_FxObj
> >> > > >
> >> > PB88I1bAwXOtZColSmDyhIvj_1yhbCVJUJ0vrnCWWTuivB9Y.&URL=http://www.g
> >> > > > isinternals.com/sdk/> and I have still the same problem. For your
> >> > information,
> >> > > > I'm running GDAL on windows7 and PostGIS 2.0 is installed on a Linux
> >> > > > server.
> >> > I
> >> > > > tried many version of GDAL 1.9 and I always have the same problem.
> >> > > > The
> >> > version
> >> > > > 1.8 is working very well but I would like to take advantage of the
> >> > improvements
> >> > > > in the last version because I'm working on a project where
> >> > > > processing time is
> >> > > > very important.
> >> > > >
> >> > > > Does anybody have any idea about this problem ?
> >> > > >
> >> > > > Thanks
> >> > > >
> >> > > > David Bélanger
> >> > >
> >> > > _______________________________________________
> >> > > postgis-users mailing list
> >> > > postgis-users <at> postgis.refractions.net
> >> > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >>
> >> _______________________________________________
> >> postgis-users mailing list
> >> postgis-users <at> postgis.refractions.net
> >> http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users <at> postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> >
>
>
>
> --
> Jorge Arevalo
> http://www.libregis.org
> _______________________________________________
> postgis-users mailing list
> postgis-users <at> postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list postgis-users <at> postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
!! I did some digging for info regarding pgadmin3 as kindly
suggested by Regina (see below) - hope it is useful.
Rather predictably, answering that single first question brings me to
my next two questions (I suppose this is progress after a fashion):
(1) Performance (or lack thereof): I am attempting to create topology
out of a rather large (36MPixel) SRTM elevation raster. I am
currently using a very small tile as the processing times I am seeing
suggest using a calendar rather than a stopwatch to profile my code.
Is there some obvious thing I should be doing to speed things up?
Perhaps something analogous to how raster2pgsql emits an SQL file
rather than doing a pixel-at-a-time update? Or perhaps I am going
about this entirely the wrong way? (I had similar performance
problems in simply reading the raster out of PostGIS, but that was
more straightforward to work around...)
(2) Are there any "gotchas" of which I should be aware due to "no
proper 3D topology support?" False co-planarity issues? Limitations
to modeling road overpasses, etc?
As for pgadmin3 (which I had been using to try and figure this out
myself), I did some digging as Regina kindly suggested. FYI I am
using revision 1.14.0. When I select the node table's geom column,
the "Data type" as displayed in the properties window is
"geometry(1107458)." The context menu's "properties" display shows a
data type of simply "geometry."
However, if the SQL pane is open, it shows a fragment of SQL ("ALTER
TABLE"...), including "ADD COLUMN geom geometry(PointZ, 4326)."
So it WAS visible, presuming I knew where to look (and I didn't).
Sorry, and thanks again for the help!
-jm
On Wednesday 30 May 2012, Sandro Santilli wrote:
> On Tue, May 29, 2012 at 10:01:35PM -0400, John Morrison wrote:
> > Hi;
> >
> > Sorry if this is a dumb newbie question regarding support for 3D
> > topology (as I am relatively new to both SQL and PostGIS).
> >
> > I am running PostGIS 2.0.1SVN r9732 on FC16/x86_64.
> >
> > When I try to add a 3D point to a topology via either ST_AddIsoNode or
> > AddNode, I get an error of the form "Geometry has Z dimension, but
> > column does not." Adding 2D points seems to work fine.
>
> There's no proper 3D topology support, but you do can equip your
> primitives with a per-vertex Z value (2.5D) if you account for it
> at topology creation time. See manual page entry for CreateTopology
> on how to do that.
>
> > pgadminIII gives a rather cryptic type of "geometry(1107456)" as the
> > data type of the "geom" column of the "node" table of my topology.
>
> That is annoying, I would expect something like "geometry(point)"
> or "geometry(pointZ)" instead. Do types of other spatial tables
> look fine in pgadminIII or is it a general issue with any geometry
> column ?
>
> --strk;
>
> ,------
RSS Feed