[postgis-users] Raster2pgsql.py Possible No Data Problem

Paragon Corporation lr at pcorp.us
Thu Mar 3 03:56:04 PST 2011


Andreas,
How much memory do you have on your 64-bit desktop?  I wonder if it would
have made a difference using 32-bit python.
 
I think the way 64-bit works, its actually worse if you don't have as much
memory because the address space of each is larger.  Then again I might not
know what I am talking about, but that is what I've heard.  So I generally
try to avoid 64-bit unless I have more than 4GB ram since there doesn't seem
to be much point in it and there are so many stupid drivers I have that I'm
forced to use that don't work on 64-bit.
 
Since we don't have a 64-bit build of PostGIS yet for windows, there is even
less of a reason if you are running Windows for PostGIS.
 
As a side note: Be careful when running PostGIS 2.0 raster bits in PostGIS
1.5.  If you are just using the loader, you might need to rebuild the index
(I think the default when nodata value is not present might have changed to
from 0 to NULL and PostGIS 1.5 raster can't handle that). I don't think the
load structure has changed aside from those, but Jorge and Pierre can
confirm.
 
I'm not quite sure at which point the index operator changed from using
ST_Envelop to ST_ConvexHull whether it was before or after PostGIS 2.0
merge, but you may find the indexes built with the loader ineffective, if
you are running a version before.
 
Good way to confirm is do an explain of your query and verify its still
using the spatial index.
 
Hope that helps,
Regina
http://www.postgis.us
 

  _____  

From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Andreas
Forø Tollefsen
Sent: Thursday, March 03, 2011 4:26 AM
To: Jorge Arévalo
Cc: PostGIS Users Discussion
Subject: Re: [postgis-users] Raster2pgsql.py Possible No Data Problem


Very strange. The out of memory error i posted in my last post i got on my
64 bit desktop. I tried the excact same thing on my 32 bit laptop, and there
i did not get a out of memory when importing to the postgis1.5 database. 

Andreas


2011/3/3 Andreas Forø Tollefsen <andreasft at gmail.com>


It seems I had some problems with my gdal python bindings. I downloaded the
64 bit Python 2.6 GDAL 1.7 bindings from here
http://www.lfd.uci.edu/~gohlke/pythonlibs/. 
Now i can create the sql file. However. I have some new problems when
importing.
It works when i try to write the sql file to my PostGIS 2.0 database, but
not to my PostGIS 1.5 database.
See errors below (first is 1.5, second is 2.0 and working):

C:\prio_grid\source\mountain>psql -h localhost -U postgres -d newpg -f
mountain.
sql
BEGIN
psql:mountain.sql:2: NOTICE:  CREATE TABLE will create implicit sequence
"mounta
in_rid_seq" for serial column "mountain.rid"
psql:mountain.sql:2: NOTICE:  CREATE TABLE / PRIMARY KEY will create
implicit in
dex "mountain_pkey" for table "mountain"
CREATE TABLE

                       addrastercolumn

----------------------------------------------------------------------------
----
----------------------------------------------------------------------------
----
--------------------------------------------------------------
 public.mountain.rast srid:4326 pixel_types:{32BF} out_db:false
regular_blocking
:false nodata_values:'{-3.40282346639e+038}' pixelsize_x:'0.08333334'
pixelsize_
y:'-0.08333334' blocksize_x:NULL blocksize_y:NULL extent:NULL
(1 row)


psql:mountain.sql:4: ERROR:  out of memory
DETAIL:  Failed on request of size 134217728.
psql:mountain.sql:5: ERROR:  current transaction is aborted, commands
ignored un
til end of transaction block
ROLLBACK

C:\prio_grid\source\mountain>psql -h localhost -U postgres -d
template_postgis20
 -f mountain.sql
BEGIN
psql:mountain.sql:2: NOTICE:  CREATE TABLE will create implicit sequence
"mounta
in_rid_seq" for serial column "mountain.rid"
psql:mountain.sql:2: NOTICE:  CREATE TABLE / PRIMARY KEY will create
implicit in
dex "mountain_pkey" for table "mountain"
CREATE TABLE

                   addrastercolumn

----------------------------------------------------------------------------
----
----------------------------------------------------------------------------
----
------------------------------------------------------
 public.mountain.rast srid:4326 pixel_types:{32BF} out_db:false
regular_blocking
:false nodata_values:'{-3.40282346639e+038}' scale_x:'0.08333334'
scale_y:'-0.08
333334' blocksize_x:NULL blocksize_y:NULL extent:NULL
(1 row)


INSERT 0 1
CREATE INDEX
COMMIT

C:\prio_grid\source\mountain>

2011/3/2 Andreas Forø Tollefsen <andreasft at gmail.com> 


Hi. Sorry. I was confused and used the Python 2.5. 

Now i get some other errors when using python 2.6. Could it be my setup
which is not correct?

C:\Python26>python raster2pgsql.py -r
c:\prio_grid\source\mountain\mean_mnt_bin.
tif -t mountain -s 4326 -I -o mountain.sql
Traceback (most recent call last):
  File "raster2pgsql.py", line 1036, in <module>
    main()
  File "raster2pgsql.py", line 999, in main
    gt = wkblify_raster(opts, filename.replace( '\\', '/') , i, gt)
  File "raster2pgsql.py", line 941, in wkblify_raster
    summary = wkblify_raster_level(options, ds, options.overview_level,
band_ran
ge, infile, i)
  File "raster2pgsql.py", line 901, in wkblify_raster_level
    hexwkb += wkblify_band(options, band, level, xoff, yoff,
read_block_size, bl
ock_size, infile, b)
  File "raster2pgsql.py", line 790, in wkblify_band
    target_block_size[0], target_block_size[1])
  File "C:\Python26\Lib\site-packages\osgeo\gdal.py", line 978, in
ReadAsArray
    import gdalnumeric
  File "C:\Python26\Lib\site-packages\osgeo\gdalnumeric.py", line 1, in
<module>

    from gdal_array import *
  File "C:\Python26\Lib\site-packages\osgeo\gdal_array.py", line 24, in
<module>

    _gdal_array = swig_import_helper()
  File "C:\Python26\Lib\site-packages\osgeo\gdal_array.py", line 23, in
swig_imp
ort_helper
    return _mod
UnboundLocalError: local variable '_mod' referenced before assignment

C:\Python26>

2011/3/2 Jorge Arévalo <jorge.arevalo at deimos-space.com> 


On Wed, Mar 2, 2011 at 5:40 PM, Andreas Forø Tollefsen
<andreasft at gmail.com> wrote:
> Hi,
> Postgresql 8.4.7
> postgis-pg84-binaries-2.0.0svn.zip
> Tested with latest raster2pgsql.py rev 6860
> I have a raster which is giving me problems when creating the raster
table.
> The raster does not have any digits for no data but 'no data'.
> Could this be the cause of the below problem? I tried a different raster
> which normally have been working with the old gdal2wktraster.py script.
> Any suggestions?
> The error:
> C:\Python25>python raster2pgsql.py -r
> c:\prio_grid\source\mountain\mean_mnt_bin.
> tif -t mountain -o mountain.sql
> Traceback (most recent call last):
>   File "raster2pgsql.py", line 1036, in <module>
>     main()
>   File "raster2pgsql.py", line 999, in main
>     gt = wkblify_raster(opts, filename.replace( '\\', '/') , i, gt)
>   File "raster2pgsql.py", line 941, in wkblify_raster
>     summary = wkblify_raster_level(options, ds, options.overview_level,
> band_ran
> ge, infile, i)
>   File "raster2pgsql.py", line 853, in wkblify_raster_level
>     nodata_values = collect_nodata_values(ds, band_from, band_to)
>   File "raster2pgsql.py", line 532, in collect_nodata_values
>     if nodata is not None and not math.isnan(nodata):
> AttributeError: 'module' object has no attribute 'isnan'
> C:\Python25>
>

> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>

Hi,

The problem is with the 'isnan' function. I see it was included in
Python 2.6. We need a replacement in case of lower Python versions.
I'll fix it asap (hopefully, when I arrive home).

Best regards, and thanks for the feedback

--
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge.arevalo at deimos-space.com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110303/7a6186f3/attachment.html>


More information about the postgis-users mailing list