[gdal-dev] error adding ecw on Ubuntu 10.4 (lucid)

2011-02-04 Thread Matt Wilkie
Hi Folks,

I'm trying to add ECW read support to gdal in Ubuntu 10.4 (Lucid)
amd64 and not having much luck. The end goal is simply to be able to
view ecw images in QGIS.

What I've tried to date follows.  Edited for space, things were not
actually installed all at the same time or in the order as written;
many false starts in the middle. I keep getting an error from
`gdal-ecw-build`: "checking for libNCSEcw.so or libecwj2... configure:
error: not found". The only reference I could find to this error was
on Mac OS-X from 3 years, with a note that a fix was committed to
source (http://trac.osgeo.org/gdal/ticket/2032). What am I doing
wrong/missing? thanks.

{{{
uname -a
#Linux ubuntu-desktop 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16
08:09:38 UTC 2010 x86_64 GNU/Linux

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
sudo apt-get update
sudo apt-get install qgis gdal-bin libgdal-ecw-src

# download libecwj2-3.3 and unpack to ~/src
cd ~/src
wget http://gentoo.cs.utah.edu/distfiles/libecwj2-3.3-2006-09-06.zip
unzip libecwj2-3.3-2006-09-06.zip

# build the SDK
cd libecwj2-3.3/Source
./configure
make
sudo make install

# build gdal with ecw plugin
sudo gdal-ecw-build ~/src/libecwj2-3.3/Source/

Extracting GDAL/ECW tarball
Building GDAL/ECW plugin
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for ranlib... ranlib
checking for g++ -shared ... yes
checking for gdal-config... /usr/local/bin/gdal-config
using /usr/lib/gdal17plugins as GDAL shared library autoload directory
checking for libNCSEcw.so or libecwj2... configure: error: not found
in /home/matt/src/libecwj2-3.3/Source//lib or
/home/matt/src/libecwj2-3.3/Source//bin.
}}}


-- 
-matt
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond


On Sat, 2011-02-05 at 00:06 +0100, Even Rouault wrote: 
> Le vendredi 04 février 2011 20:25:43, Marius Jigmond a écrit :
> > Hi Everyone,
> > 
> > Some of the options (I didn't test all) introduced with version 1.8.0
> > seem to behave strangely. Here's what I'm doing:
> > 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
> > works fine but I get the following warning:
> > Warning : the output raster dataset and the input vector layer do not
> > have the same SRS.
> > Results might be incorrect (no on-the-fly reprojection of input data).
> > even though both inputs use the same projection, EPSG:3844.
> 
> Unrelated with GDAL 1.8.0. The issue was that the transformation between OGC 
> WKT and ESRI WKT didn't handle well the Oblique Stereographic projection. 
> Fixed in trunk in http://trac.osgeo.org/gdal/changeset/21627

Thanks.

> 
> > 
> > 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
> > sample.tif
> > fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> > 
> > 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
> > fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> > 
> > >From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
> > or -a_nodata would require -tr or -ts. Am I doing something wrong?
> 
> When those 2 new options are used, they imply creating a new dataset. So they 
> actually need to be used with -tr or -ts option.

Thanks for the clarification as it's not apparent from the web page.
Would have loved the -a_nodata to be available for existing datasets.

> 
> > 
> > -marius
> > 
> > ___
> > 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] gdal_rasterize 1.8.0 options

2011-02-04 Thread Even Rouault
Le vendredi 04 février 2011 20:25:43, Marius Jigmond a écrit :
> Hi Everyone,
> 
> Some of the options (I didn't test all) introduced with version 1.8.0
> seem to behave strangely. Here's what I'm doing:
> 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
> works fine but I get the following warning:
> Warning : the output raster dataset and the input vector layer do not
> have the same SRS.
> Results might be incorrect (no on-the-fly reprojection of input data).
> even though both inputs use the same projection, EPSG:3844.

Unrelated with GDAL 1.8.0. The issue was that the transformation between OGC 
WKT and ESRI WKT didn't handle well the Oblique Stereographic projection. 
Fixed in trunk in http://trac.osgeo.org/gdal/changeset/21627

> 
> 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
> sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
> 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
> >From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
> or -a_nodata would require -tr or -ts. Am I doing something wrong?

When those 2 new options are used, they imply creating a new dataset. So they 
actually need to be used with -tr or -ts option.

> 
> -marius
> 
> ___
> 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


[gdal-dev] possible (probably) dumb question w.r.t to OpenGrADS and GDAL

2011-02-04 Thread Matt Funk
Hi,
i am fairly new to the earth science field and its implementation in
terms of programming.
I had a question that is probably fairly obvious to  most:
What is the difference/relationship between gdal and opengrads (or does
there even exist such a relationship?). Is one build on top of the
other. Are they competing products in some areas? Which has what place
where?

Grads description:
The Grid Analysis and Display System (GrADS)
 is an interactive desktop tool for easy
access, manipulation, and visualization of earth science dat

GDal:
GDal is a translator library for raster geospatial data formats that is
released under an X/MIT
 style 
Open
Source  license by the Open Source
Geospatial Foundation .

So it looks to me both deal with gridded data (gdal->raster, gdal->Grid
Analysis ...), earth data etc...
I see that Grads describes itself as interactive ...

Anyway, does anyone know and if so could they enlighten me?

thanks
matt
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Eli Adam
Marius,

I don't know about 1. but possibilities for 2. and 3 below.  

> Hi Everyone,
> 
> Some of the options (I didn't test all) introduced with version 1.8.0
> seem to behave strangely. Here's what I'm doing:
> 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
> works fine but I get the following warning:
> Warning : the output raster dataset and the input vector layer do not
> have the same SRS.
> Results might be incorrect (no on-the-fly reprojection of input data).
> even though both inputs use the same projection, EPSG:3844.
> 
> 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
> sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
> 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
> fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> 
>>From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
> or -a_nodata would require -tr or -ts. Am I doing something wrong?

Does sample.tif exist?  If not, the docs say you need to use -tr or -ts, "Since 
GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One of -tr 
or -ts option must be used in that case."  I don't know why that error would 
not also come from 1. 


Bests, Eli

> 
> -marius
> 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond
Eli,

Both input datasets (mask and raster) exist, which is why 1. works.
Option 1 doesn't use any of version 1.8.0 flags, which is why I thought
something else was introduced behind the scenes with the new flags.

-marius

On Fri, 2011-02-04 at 12:08 -0800, Eli Adam wrote: 
> Marius,
> 
> I don't know about 1. but possibilities for 2. and 3 below.  
> 
> > Hi Everyone,
> > 
> > Some of the options (I didn't test all) introduced with version 1.8.0
> > seem to behave strangely. Here's what I'm doing:
> > 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
> > works fine but I get the following warning:
> > Warning : the output raster dataset and the input vector layer do not
> > have the same SRS.
> > Results might be incorrect (no on-the-fly reprojection of input data).
> > even though both inputs use the same projection, EPSG:3844.
> > 
> > 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
> > sample.tif
> > fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> > 
> > 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
> > fails with: '-tr xres yes' or '-ts xsize ysize' is required.
> > 
> >>From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
> > or -a_nodata would require -tr or -ts. Am I doing something wrong?
> 
> Does sample.tif exist?  If not, the docs say you need to use -tr or -ts, 
> "Since GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One 
> of -tr or -ts option must be used in that case."  I don't know why that error 
> would not also come from 1. 
> 
> 
> Bests, Eli
> 
> > 
> > -marius
> > 
> 
> 
> 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


[gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond
Hi Everyone,

Some of the options (I didn't test all) introduced with version 1.8.0
seem to behave strangely. Here's what I'm doing:
1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif
works fine but I get the following warning:
Warning : the output raster dataset and the input vector layer do not
have the same SRS.
Results might be incorrect (no on-the-fly reprojection of input data).
even though both inputs use the same projection, EPSG:3844.

2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp
sample.tif
fails with: '-tr xres yes' or '-ts xsize ysize' is required.

3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif
fails with: '-tr xres yes' or '-ts xsize ysize' is required.

>From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs
or -a_nodata would require -tr or -ts. Am I doing something wrong?

-marius

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


[gdal-dev] Online Shapefile Viewer

2011-02-04 Thread Mohammed Rashad
Hi,
Sorry if my post doesnt belong this ML. I am posting because gis users may
find this application useful.
here is an online shapefile viewer which reads shapefile using OGR and
rendered on webpage.
http://lsi.iiit.ac.in/lsi/shpviewer/
Here the shapefile is directly rendered without mapserver, geoserver like
packages.The only library we used is GDAL


Please test it.

Looking forward your comments, BUGS && suggestions
--
Rashad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdalbuildvrt

2011-02-04 Thread Marius Jigmond
Aníbal,

Have you tried opening the .vrt file with a text editor? For each
source .tif there should be three entries in the .vrt file (one per
band). What does gdalinfo source.tif say?

-marius

On Fri, 2011-02-04 at 11:41 -0200, Aníbal Pacheco wrote: 
> On 02/03/2011 04:59 PM, Frank Warmerdam wrote:
> > On 11-02-03 01:30 PM, Aníbal Pacheco wrote:
> >> Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can
> >> then
> >> used in Mapnik and its ogcserver(WMS), everything works except that
> >> the result
> >> image is black & white and with a very poor resolution. The 2 source
> >> tif files
> >> used in this test were both colored with a good resolution. Any ideas?
> >
> >
> > Aníbal,
> >
> > I would suggest examining the resulting vrt to see if there is anything
> > odd about it. Start with gdalinfo to see if it's resolution seems
> > reasonable
> > and if in fact it is 3 bands. You might want to run "gdalinfo -stats
> > xx.vrt"
> > to get band statistics just to verify that the bands are radiometrically
> > distinct. Also, check that the band pixel type is reasonable - the same
> > as the source files.
> >
> > If that all looks ok, then perhaps visually examine the VRT with something
> > like QGIS.
> >
> > After that it comes down to talking to Mapnik people about why there are
> > problems.
> >
> > Best regards,
> 
> 
> I think there is something wrong with the vrt because QGis does not find 
> the 3rd band, here[0] is a screenshot to help. thanks
> 
> [0] http://imgur.com/OHnFg
> ___
> 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] Compiling only OGR

2011-02-04 Thread Frank Warmerdam

On 11-02-04 02:54 AM, Helm, P.W. (Pim) van den wrote:

Hi all,
I am using only vertex calculation (OGR part) of GDAL. Using the GDAL library
does the work perfectly, but I think this 6mb+ dll is rather large for my usage
only.


Pim,

If you really want to trim down GDAL/OGR you will likely have to do some
fiddling.  I'd start by going through gdal/frmts/makefile.vc and removing
most formats from the EXTRAFLAGS list (each -DFRMT_xxx relates to one of the
subdirectories).

Because of relations to stuff on the OGR side you may find you need
to keep the FRMT_pcidsk and FRMT_sdts items.  You may also find that
you need to keep FRMT_gtiff because the geotiff machinery is used
to lookup EPSG coordinate systems, and FRMT_zlib (added below) for
other things using compression.

You might be able to skip building in all the stuff in
gdal/alg by removing it from gdal/makefile.vc but you will also
likely need to remove some entry points from BASE_INCLUDE in
gdal/makefile.vc.



Further more, do I really need the link to proj4 if I only refer to EPSG
systems, since this also enlarges my project?


PROJ.4 is usually loaded at runtime so if you don't need it just
don't distribute PROJ.DLL. Note that if you use
OGRCoordinateTransformation then you will need PROJ.4 even if you
just use EPSG coordinate systems.

It would be nice if your and others findings with doing slimmed down
builds could find its way into the trac wiki - perhaps in the

  http://trac.osgeo.org/gdal/wiki/BuildingOnWindowsWithMinimizedDrivers

page or elsewhere as appopriate off:

  http://trac.osgeo.org/gdal/wiki/BuildHints

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] gdalbuildvrt

2011-02-04 Thread Aníbal Pacheco

On 02/03/2011 04:59 PM, Frank Warmerdam wrote:

On 11-02-03 01:30 PM, Aníbal Pacheco wrote:

Hi, I'm using gdalbuildvrt to produce a virtual raster layer which can
then
used in Mapnik and its ogcserver(WMS), everything works except that
the result
image is black & white and with a very poor resolution. The 2 source
tif files
used in this test were both colored with a good resolution. Any ideas?



Aníbal,

I would suggest examining the resulting vrt to see if there is anything
odd about it. Start with gdalinfo to see if it's resolution seems
reasonable
and if in fact it is 3 bands. You might want to run "gdalinfo -stats
xx.vrt"
to get band statistics just to verify that the bands are radiometrically
distinct. Also, check that the band pixel type is reasonable - the same
as the source files.

If that all looks ok, then perhaps visually examine the VRT with something
like QGIS.

After that it comes down to talking to Mapnik people about why there are
problems.

Best regards,



I think there is something wrong with the vrt because QGis does not find 
the 3rd band, here[0] is a screenshot to help. thanks


[0] http://imgur.com/OHnFg
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


[gdal-dev] SOS! Zero pixel values in the output! Please help!

2011-02-04 Thread user gdal
Dear all,
I am new to GDAL and I was at fault in being too hasty in asking for
an advanced topic in my previous post.

I am facing a fundamental difficulty. The problem is to retrieve
projection and pixel data etc. from a source ERDAS .img file and copy
'as it is' to another file. For this, I wrote a small program in C++
whose relevant sections I am pasting here for kind perusal:

template void CIOImg_Templ::AllocateMemory( )
{
 unsigned int b;

 buf=new T * [Band];
 if(!buf) HandleException("Memory Allocation Problem");

 for(b=0; b void CIOImg_Templ::CreateOutputImg(GDALDataset *
const* InDS) // output dataset (DS) is defined as a class member
{
 char **options=NULL; /* saw an example of this kind in GDAL site */
 double trans[6]; // the transformation coefficients

 GDALDriver *driver=(*InDS)->GetDriver( );

 GDALAllRegister( );
 if(!driver) HandleException("Sorry, couldn't load the driver for your format");

 outds=(GDALDataset *) GDALOpen(outfilename, GA_Update);
 outds=driver->Create(outfilename, Col, Row, Band, datatype, options);
 // is it correct

 (*InDS)->GetGeoTransform(trans);
 outds->SetGeoTransform(trans);

 outds->SetProjection((*InDS)->GetProjectionRef( ));

 /* Seems there is much more to all this, but how to do? */
}

template void CIOImg_Templ::Read(const unsigned int b,
GDALDataset* const *inds)
{
 ((*inds)->GetRasterBand(b+1))->RasterIO(GF_Read, 0, 0, Col, 1,
buf[b], Col, 1, datatype, 0, 0);   // able to read the pixel values
correctly into buffer (buf)
}

template void CIOImg_Templ::Write(const unsigned int b,
GDALDataset** opds)
{
 ((*opds)->GetRasterBand(b+1))->RasterIO(GF_Write, 0, 0, Col, 1,
buf[b], Col, 1, datatype, 0, 0);

 */ (*opds)->RasterIO(GF_Write, 0, 0, Col, 1, buf[b], Col, 1,
datatype, 1, NULL, 0, 0, 0); */ /* Neither of these is working */
}

template void CIOImg_Templ::ReadNWrite(GDALDataset * const *inds)
{
 unsigned int b, i=0;

 CreateOutputImg(inds);

 while(ihttp://lists.osgeo.org/mailman/listinfo/gdal-dev