Some so called SDI experts feel that FOSS SDI cannot perform at-par with Proprietary SDI. Please provide examples to fight a case from an Indian state which swears by Free and Open Source Software. We can never expect a better level playing field. Kerala - India Here are some excerpts from a document that has false claims supporting Proprietary Software. However, it is worthwhile to mention here that the OSS (Open Source Software) does not match the advanced functionalities of many of the commercial (proprietory) software that is in the market. Image processing and analysis capabilities of the open source software is not comparable to the commercial software when one require to carry out advanced data manipulations, image fusion, 3D modeling, ortho-correction, auto-georeferencing, stereo-image/air photo interpretation (PROBABLY REFERRING TO GRASS), advanced geospatial analysis etc., In such cases, certain proprietary software become an integral part of the Spatial Data Infrastructures, which can not be avoided. At a later stage the some of the proprietary software need to be purchased. It is a well known fact that web portal that run with OSS are neither OGC-compliant nor interoperable(PostGIS and Webservers to react). At the present juncture it is only possible to establish the KSDI Geoportal with the available COTS enterprise software. The detailed PDF document will be emailed on demand. This is a case that has the potential to set trends in India. Hope to have a good discussion such that we can sum it up and present at a meeting being conducted on August 11th 2010, to settle the issue. Ravi Kumar

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

Please feel free to provide your management with the technical design document for the SDI in the Netherlands.

http://www.geonovum.nl/sites/default/files/MOT_20100618_TechnicalDesign_v1.01.pdf

The document is in English, so you don't have to brush off your Dutch language skills. Also read Paul Ramsey's take on the document:

http://blog.opengeo.org/2010/07/08/tulips-pancakes-and-open-source-mapping/

Kind regards,

Edward


Date: Sun, 1 Aug 2010 15:31:10 -0700
From: ravivundavalli <at> yahoo.com
To: grassuser <at> grass.itc.it; grass-user <at> lists.osgeo.org; postgis-users <at> postgis.refractions.net
Subject: [postgis-users] Help in Defending FOSS SDI

Some so called SDI experts feel that FOSS SDI cannot perform at-par with Proprietary SDI. Please provide examples to fight a case from an Indian state which swears by Free and Open Source Software. We can never expect a better level playing field. Kerala - India Here are some excerpts from a document that has false claims supporting Proprietary Software. However, it is worthwhile to mention here that the OSS (Open Source Software) does not match the advanced functionalities of many of the commercial (proprietory) software that is in the market. Image processing and analysis capabilities of the open source software is not comparable to the commercial software when one require to carry out advanced data manipulations, image fusion, 3D modeling, ortho-correction, auto-georeferencing, stereo-image/air photo interpretation (PROBABLY REFERRING TO GRASS), advanced geospatial analysis etc., In such cases, certain proprietary software become an integral part of the Spatial Data Infrastructures, which can not be avoided. At a later stage the some of the proprietary software need to be purchased. It is a well known fact that web portal that run with OSS are neither OGC-compliant nor interoperable(PostGIS and Webservers to react). At the present juncture it is only possible to establish the KSDI Geoportal with the available COTS enterprise software. The detailed PDF document will be emailed on demand. This is a case that has the potential to set trends in India. Hope to have a good discussion such that we can sum it up and present at a meeting being conducted on August 11th 2010, to settle the issue. Ravi Kumar

_______________________________________________ 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

For what it's worth: I cannot speak about FOSS in general, but for raster servers I dare to take position.
Open-source rasdaman repeatedly has been reported to have a performance way superior to ArcSDE.
Some more voices (look at the Oracle one!):
“world leading technology." -- Aerovista France (market survey, 2004)
“I am not easy to impress, but this is unique." -- Eng. Hans Jacoby, Infrastructure Management, German Railways
“Most favourable tool for Data Mgmnt Services" -- NIMA (USA) Pathfinder evaluation 2003; >700 vendors invited
“Impressive software - Oracle will never do anything that elaborate in functionality and architecture." -- Jeffrey Xie, Senior Tech. Staff, GeoRaster, Oracle USA
"Your performance continues to amaze me." -- David Adler, Senior Database Engineer, IBM USA
"most comprehensive implementation" -- Rona Machlin, ACM SIGMOD, 2007

Starting this fall rasdaman will be integrated with GDAL (works already), MapServer, PostGIS. Rasdaman can exploit multiple processors and can be distributed (free version) and supports transparent tape silo access (commercial version). Installations grow by just adding the new compute nodes and editing a configuration script. Multi-Petabyte scalability is not an issue.

As for FOSS standards support, your folks may want to have a look at www.earthlook.org which gives demos of 1-D to 4-D earth science use cases, all based on OGC standards.

I myself am leading the raster-relevant working groups within OGC, plus editor of currently 9 specification documents. In this capacity I know that FOSS is of high importance to OGC and receives high attention there. The forthcoming WCS 2.0 standard (adoption vote ends by August 17) will have open-source rasdaman as its reference implementation. We already have done first steps on the way to make sure the specification is implementable and scalable. BTW, WCS 2.0 will rely on a unified coverage model which allows coverages to float between services relying on different OGC standards, such as WPS, WCS, SWE Common, GML.

HTH - best of luck,
Peter



On 08/02/2010 12:31 AM, Ravi wrote:

Some so called SDI experts feel that FOSS SDI cannot perform at-par with Proprietary SDI. Please provide examples to fight a case from an Indian state which swears by Free and Open Source Software. We can never expect a better level playing field. Kerala - India Here are some excerpts from a document that has false claims supporting Proprietary Software. However, it is worthwhile to mention here that the OSS (Open Source Software) does not match the advanced functionalities of many of the commercial (proprietory) software that is in the market. Image processing and analysis capabilities of the open source software is not comparable to the commercial software when one require to carry out advanced data manipulations, image fusion, 3D modeling, ortho-correction, auto-georeferencing, stereo-image/air photo interpretation (PROBABLY REFERRING TO GRASS), advanced geospatial analysis etc., In such cases, certain proprietary software become an integral part of the Spatial Data Infrastructures, which can not be avoided. At a later stage the some of the proprietary software need to be purchased. It is a well known fact that web portal that run with OSS are neither OGC-compliant nor interoperable(PostGIS and Webservers to react). At the present juncture it is only possible to establish the KSDI Geoportal with the available COTS enterprise software. The detailed PDF document will be emailed on demand. This is a case that has the potential to set trends in India. Hope to have a good discussion such that we can sum it up and present at a meeting being conducted on August 11th 2010, to settle the issue. Ravi Kumar

-- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann <at> jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 147737) www.rasdaman.com, mail: baumann <at> rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

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

There are cases where this leads to sub-exact results. And it poses extra load on the client which needs to do all the tile-to-coverage handling itself, it is aka raster assembler. Systems like rasdaman can do quite effective optimizations as they know how a coverage is composed from tiles.

-Peter


On 07/28/2010 03:14 PM, Pierre Racine wrote:

A table of tiles form a large coverage as one. Every process might be done one tile at a time but SQL GROUP BY statements help regrouping things together if needed.

 

Pierre

 

From: Peter Baumann [mailto:p.baumann <at> jacobs-university.de]
Sent: 28 juillet 2010 04:27
To: Pierre Racine
Cc: PostGIS Users Discussion
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

Pierre,

admittedly this was a little inexact, and I certainly will correct it. A more accurate phrasing I guess is "does not support retrieval on a raster array consisting of a set of tiles, rather tiles have to be treated individually."
From what I understand WKT Raster can tile an incoming image, but cannot treat a set of tiles making up a larger coverage as one.

Would you agree to that?

-Peter



On 07/27/2010 05:52 PM, Pierre Racine wrote:

BTW Peter,

 

in your site (http://kahlua.eecs.jacobs-university.de/trac/rasdaman/wiki/WhyRasdaman) you say: “First and foremost, it (PostGIS WKT Raster) does not support tiling (partitioning) of raster arrays.” This statement is false since WKT Raster actually does support tiling of large rasters. You can partition any raster coverage by importing it as separate tiles or by using the –k option of gdal2wktraster.py. Each tile become a separate row in the table and the whole table is the coverage. The table is spatially indexed using the PostgreSQL GiST index.

 

I think it would be just fair if you could rectify this statement.

 

Thanks,

 

Pierre

 

From: Peter Baumann [mailto:p.baumann <at> jacobs-university.de]
Sent: 21 juillet 2010 17:28
To: Pierre Racine
Cc: PostGIS Users Discussion
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

Pierre-

rasdaman per se is domain agnostic - you can just as well maintain human brain images (as we did). The petascope layer, which is part of the distro, adds geo semantics by providing OGC interfaces.
PostgreSQL integration is not yet done, we are working on this; same for GDAL / MapServer.

-Peter


On 07/21/2010 08:29 PM, Pierre Racine wrote:

Peter,

 

Are rasters in rasdaman georeferenced? How do I convert my vectorial PostGIS points coordinates into rasdaman coordinates? Do I have to do all the math myself?

 

Pierre

 

From: Peter Baumann [mailto:p.baumann <at> jacobs-university.de]
Sent: 21 juillet 2010 04:41
To: Pierre Racine
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

Pierre-

let's see. First, I would not store 100k raster points in the relational table as its terribly inefficient. We do have input data formats, though, which are similar to what a PG dump of such a table would deliver. We import this into an array and then can query it. Import via rasql or through an import tool which internally generates rasql calls.

Then, for corner points (x0,y0) and (x1,y1) we retrieve as

    select png( M[x0:y1,y0:y1] ) from MyMap as M

...in PNG format via the rasql cmd line utility or the C++ or Java API.

Alternatively, sending this this query over the API gets you the data into main memory ready for nested for loops = in the main memory format of your client:

    select M[x0:y1,y0:y1] from MyMap as M

-Peter



On 07/20/2010 10:03 PM, Pierre Racine wrote:

So if I already have a table of,  say 100 000 points, uploaded in PostGIS, how do I use rasdaman to get the raster values of the pixels located under the points?

 

Pierre

 

From: Peter Baumann [mailto:p.baumann <at> jacobs-university.de]
Sent: 20 juillet 2010 12:08
To: PostGIS Users Discussion
Cc: Pierre Racine
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

On 07/20/2010 05:47 PM, Pierre Racine wrote:

Since we have this bug with big rasters,

proven, any-size, ...

Who is proven? Well, running a dozen-TB seamless mosaic on PostgreSQL for many years, having online-demos available since years, etc... you decide, in comparison.

-Peter

I would suggest you split your raster with something like GDAL gdal_retile.py and then import your tiles into a single WKT Raster table following the instruction provided in our tutorial. Each tile will be stored in a column cell of type RASTER similar to the PostGIS GEOMETRY type.

 

As I said previously you can then query the raster in SQL like this:

 

SELECT ST_Value(rast, ST_Geomfromtext('Point(-78.1 58.1)', 4326))

FROM srtm_tiled_100x100

WHERE ST_Intersects(rast::geometry, ST_Geomfromtext('Point(-78.1 58.1)', 4326)) AND whatever you want.

 

Basically WKT Raster is the first true SQL interface with which is is simple to do such things… It's proven, any-size, cloud-scalable, and open source J Maybe not that prooven. But who is?

 

There is also rasdaman but I don’t think you can use SQL. It would be nice if you could compare both… I can’t find time for this. Jorge has started comparing PostGIS WKT Raster with Oracle Georaster though.

 

Pierre

 

 

From: postgis-users-bounces <at> postgis.refractions.net [mailto:postgis-users-bounces <at> postgis.refractions.net] On Behalf Of Sebastian E. Ovide
Sent: 20 juillet 2010 10:46
To: PostGIS Users Discussion
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

yes... with png worked... but it was a different png (a smaller one)...

so I've converted the ESRI into a png and tried to import it... and it didn't work neither...

so this is the situation:
A have huge rusters (from 150kx150k).. In Oracle I would just load it (the huge raster) in a single row of a GeoRaster table and then Oracle GeoRaster would split it in small tiles and store one tile per line of another table (Raster Data Table)... then I can run a query similar to this one: SELECT getcellvalue(t.rastercolumn,x,y) from GeoRasterTable t where t.id=1; and GeoRaster will query automatically the spatial indexes and the Raster Data Table and it will find the right tile etc...

I do not know how WKTRaster works.... If I cannot import a such big image, of course I can split it in smaller georeferenced tiles... (how?)... but.... My main question is: after that, how will the table look like ? how can I do the same query (where id=1 or where name="UK" etc...) ?

On Tue, Jul 20, 2010 at 2:31 PM, Pierre Racine <Pierre.Racine <at> sbf.ulaval.ca> wrote:

Wait. You first said the png was working. Now it’s not? Did you try gdal_translate with the ESRI grid? For sure I haven’t test yet with such big rasters. Is this the result of a merge or all your original raster are all this size? The point is that with WKT Raster you don’t have to merge your raster first into a gigantic raster in order to get it store in a unique table like with Oracle Spatial.

 

Pierre

 

From: postgis-users-bounces <at> postgis.refractions.net [mailto:postgis-users-bounces <at> postgis.refractions.net] On Behalf Of Sebastian E. Ovide
Sent: 20 juillet 2010 05:51
To: PostGIS Users Discussion
Subject: Re: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

Hi Pierre,

Does gdal2wktraster.py have any limitation on the maximum number of columnsxrows ?

in my case, my raster is  107759 x 168633...

gdal works well:

sebas <at> SeansPC:~/rasters$ gdal_translate -of PNG raster/ test.png
Input file size is 107759, 168633
0...10...20...30...40...50...60...70...80...90...100 - done.


sebas <at> SeansPC:~/rasters$ python gdal2wktraster.py -r raster/ -t sebastable -o ok.sql
gdal2wktraster.py:695: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  hexwkb += wkblify('H', xsize)
gdal2wktraster.py:696: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  hexwkb += wkblify('H', ysize)
gdal2wktraster.py:727: DeprecationWarning: integer argument expected, got float
  hexwkb += wkblify(pt2fmt(pixtype), nodata)
Traceback (most recent call last):
  File "gdal2wktraster.py", line 1013, in <module>
    main()
  File "gdal2wktraster.py", line 976, in main
    wkblify_raster(opts, filename, i)
  File "gdal2wktraster.py", line 921, in wkblify_raster
    summary = wkblify_raster_level(options, ds, options.overview_level, band_range, infile, i)
  File "gdal2wktraster.py", line 888, in wkblify_raster_level
    hexwkb += wkblify_band(options, band, level, xoff, yoff, read_block_size, block_size, infile, b)
  File "gdal2wktraster.py", line 777, in wkblify_band
    target_block_size[0], target_block_size[1])
  File "/usr/lib/python2.6/dist-packages/osgeo/gdal.py", line 895, in ReadAsArray
    buf_xsize, buf_ysize, buf_obj )
  File "/usr/lib/python2.6/dist-packages/osgeo/gdal_array.py", line 228, in BandReadAsArray
    ar = numpy.empty([buf_ysize,buf_xsize], dtype = typecode)
MemoryError


sebas <at> SeansPC:~/rasters$ python gdal2wktraster.py -r test.png  -t sebastable -o ok.sql
gdal2wktraster.py:695: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  hexwkb += wkblify('H', xsize)
gdal2wktraster.py:696: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  hexwkb += wkblify('H', ysize)
gdal2wktraster.py:727: DeprecationWarning: integer argument expected, got float
  hexwkb += wkblify(pt2fmt(pixtype), nodata)
Traceback (most recent call last):
  File "gdal2wktraster.py", line 1013, in <module>
    main()
  File "gdal2wktraster.py", line 976, in main
    wkblify_raster(opts, filename, i)
  File "gdal2wktraster.py", line 921, in wkblify_raster
    summary = wkblify_raster_level(options, ds, options.overview_level, band_range, infile, i)
  File "gdal2wktraster.py", line 888, in wkblify_raster_level
    hexwkb += wkblify_band(options, band, level, xoff, yoff, read_block_size, block_size, infile, b)
  File "gdal2wktraster.py", line 777, in wkblify_band
    target_block_size[0], target_block_size[1])
  File "/usr/lib/python2.6/dist-packages/osgeo/gdal.py", line 895, in ReadAsArray
    buf_xsize, buf_ysize, buf_obj )
  File "/usr/lib/python2.6/dist-packages/osgeo/gdal_array.py", line 228, in BandReadAsArray
    ar = numpy.empty([buf_ysize,buf_xsize], dtype = typecode)
MemoryError

On Mon, Jul 19, 2010 at 5:56 PM, Pierre Racine <Pierre.Racine <at> sbf.ulaval.ca> wrote:

Hi Sebastian,

 

I can convert ESRI Grid file to .sql without problem using gdal2wktraster.py and the same parameters as you. I can do both integer and floating point rasters.

 

Maybe this is a GDAL problem. Try to convert it using gdal_translate (to tiff for example). This would be a better test than just gdalinfo.

 

Could you provide us with a file sample?

 

Pierre

 

From: postgis-users-bounces <at> postgis.refractions.net [mailto:postgis-users-bounces <at> postgis.refractions.net] On Behalf Of Sebastian E. Ovide
Sent: 19 juillet 2010 12:28
To: PostGIS Users Discussion
Subject: [postgis-users] WKTRaster : gdal2wktraster.py cannot read AIG/Arc/Info Binary Grid

 

Hi All,

trying to create a SQL with gdal2wktraster.py. It works on PNG but it doesn't on AIG files...

Note: As Gdal works fine.

C:\Program Files\PostgreSQL\8.4\bin>gdalinfo c:\tmp\raster
Driver: AIG/Arc/Info Binary Grid
Files: c:\tmp\raster
       c:\tmp\raster\dblbnd.adf
       c:\tmp\raster\hdr.adf
       c:\tmp\raster\metadata.xml
       c:\tmp\raster\prj.adf
       c:\tmp\raster\sta.adf
       c:\tmp\raster\vat.adf
       c:\tmp\raster\w001000.adf
       c:\tmp\raster\w001000x.adf
       c:\tmp\raster\w001001.adf
       c:\tmp\raster\w001001x.adf
       c:\tmp\raster\z001001.adf
       c:\tmp\raster\z001001x.adf
       c:\tmp\raster\z001002.adf
       c:\tmp\raster\z001002x.adf
       c:\tmp\raster\z001003.adf
       c:\tmp\raster\z001003x.adf
       c:\tmp\raster\z001004.adf
       c:\tmp\raster\z001004x.adf
       c:\tmp\raster\z001005.adf
       c:\tmp\raster\z001005x.adf
       c:\tmp\raster\z001006.adf
       c:\tmp\raster\z001006x.adf
       c:\tmp\raster\z001007.adf
       c:\tmp\raster\z001007x.adf
       c:\tmp\raster\z001008.adf
       c:\tmp\raster\z001008x.adf
       c:\tmp\raster\z001009.adf
       c:\tmp\raster\z001009x.adf
       c:\tmp\raster\z001010.adf
       c:\tmp\raster\z001010x.adf
       c:\tmp\raster\z001011.adf
       c:\tmp\raster\z001011x.adf
       c:\tmp\raster\z001012.adf
       c:\tmp\raster\z001012x.adf
       c:\tmp\raster\z001013.adf
       c:\tmp\raster\z001013x.adf
       c:\tmp\raster\z001014.adf
       c:\tmp\raster\z001014x.adf
       c:\tmp\raster\z001015.adf
       c:\tmp\raster\z001015x.adf
Size is 107759, 168633
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the Airy 1830 ellipsoid",
        DATUM["Not_specified_based_on_Airy_1830_ellipsoid",
            SPHEROID["Airy 1830",6377563.396,299.3249646,
                AUTHORITY["EPSG","7001"]],
            AUTHORITY["EPSG","6001"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4001"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["METERS",1]]
Origin = (128110.000000000000000,813270.000000000000000)
Pixel Size = (5.000000000000000,-5.000000000000000)
Corner Coordinates:
Upper Left  (  128110.000,  813270.000) (  6d29'37.32"W, 57d 7'47.53"N)
Lower Left  (  128110.000,  -29895.000) (  5d45'40.00"W, 49d34'10.24"N)
Upper Right (  666905.000,  813270.000) (  2d24'41.72"E, 57d 7'58.04"N)
Lower Right (  666905.000,  -29895.000) (  1d41'32.29"E, 49d34'18.23"N)
Center      (  397507.500,  391687.500) (  2d 2'15.04"W, 53d25'18.19"N)
Band 1 Block=256x4 Type=Byte, ColorInterp=Undefined
  Min=1.000 Max=4.000
  NoData Value=255


C:\Program Files\PostgreSQL\8.4\bin>python gdal2wktraster.py -r c:\tmp\raster -t sebastable -o c:\tmp\sebas.sql
gdal2wktraster.py:644: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  hexstr = binascii.hexlify(struct.pack(fmt_little, data)).upper()
gdal2wktraster.py:644: DeprecationWarning: integer argument expected, got float
  hexstr = binascii.hexlify(struct.pack(fmt_little, data)).upper()
ERROR 2: Multiplication overflow : 107759 * 168633 * 1
Traceback (most recent call last):
  File "gdal2wktraster.py", line 1013, in <module>
    main()
  File "gdal2wktraster.py", line 976, in main
    wkblify_raster(opts, filename, i)
  File "gdal2wktraster.py", line 921, in wkblify_raster
    summary = wkblify_raster_level(options, ds, options.overview_level, band_range, infile, i)
  File "gdal2wktraster.py", line 888, in wkblify_raster_level
    hexwkb += wkblify_band(options, band, level, xoff, yoff, read_block_size, block_size, infile, b)
  File "gdal2wktraster.py", line 777, in wkblify_band
    target_block_size[0], target_block_size[1])
  File "C:\OSGeo4W\apps\gdal-16\pymod\osgeo\gdal.py", line 835, in ReadAsArray
    buf_xsize, buf_ysize, buf_obj )
  File "C:\OSGeo4W\apps\gdal-16\pymod\osgeo\gdal_array.py", line 140, in BandReadAsArray
    ar = numpy.reshape(ar, [buf_ysize,buf_xsize])
  File "C:\OSGeo4W\apps\Python25\lib\site-packages\numpy\core\fromnumeric.py", line 116, in reshape
    return reshape(newshape, order=order)
ValueError: total size of new array must be unchanged

Any ideas ?
--
Sebastian E. Ovide

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

--
Sebastian E. Ovide

skype: sebastian.ovide

+353 (0) 87 6340149

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

--
Sebastian E. Ovide

--

Dr. Peter Baumann

- Professor of Computer Science, Jacobs University Bremen

   www.faculty.jacobs-university.de/pbaumann

   mail: p.baumann <at> jacobs-university.de

   tel: +49-421-200-3178, fax: +49-421-200-493178

- Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com, mail: baumann <at> rasdaman.com

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

 

 

--

Dr. Peter Baumann

- Professor of Computer Science, Jacobs University Bremen

   www.faculty.jacobs-university.de/pbaumann

   mail: p.baumann <at> jacobs-university.de

   tel: +49-421-200-3178, fax: +49-421-200-493178

- Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com, mail: baumann <at> rasdaman.com

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

 

 

--

Dr. Peter Baumann

- Professor of Computer Science, Jacobs University Bremen

   www.faculty.jacobs-university.de/pbaumann

   mail: p.baumann <at> jacobs-university.de

   tel: +49-421-200-3178, fax: +49-421-200-493178

- Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com, mail: baumann <at> rasdaman.com

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

 

 

--

Dr. Peter Baumann

- Professor of Computer Science, Jacobs University Bremen

   www.faculty.jacobs-university.de/pbaumann

   mail: p.baumann <at> jacobs-university.de

   tel: +49-421-200-3178, fax: +49-421-200-493178

- Executive Director, rasdaman GmbH Bremen (HRB 147737)

   www.rasdaman.com, mail: baumann <at> rasdaman.com

   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882

"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

 

 

-- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann <at> jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 147737) www.rasdaman.com, mail: baumann <at> rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 10xx)

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