headers
Frank Warmerdam | 17 May 05:38
Picon
Favicon
Gravatar

GDAL/OGR 1.9.1RC2 Available to Test

Folks,

I have corrected two issues Even identified in RC1 and produced a new
release candidate for the 1.9.1 release.  They were:

 * Perl bindings version info now updated for 1.9.1
 * tiff_srs.py - EPSG:2066 test failed.

Get the code at:

  http://download.osgeo.org/gdal/gdal-1.9.1RC2.tar.gz
  http://download.osgeo.org/gdal/gdal191RC2.zip

I'll make a motion to adopt this as 1.9.1 fairly soon if it looks
promising.

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
Permalink | Reply | 0 comments |
headers
Yingqi Tang | 16 May 23:58
Picon

Can OGR WFS driver take advantage of WFS Server streaming?

Hi all,


I am communicating against a WFS server which supports data (GML) streaming, which means that once I send a GetFeature quest for a big GML (2.0GB+), server will take only seconds to start streaming GML back to client while at the same time it's still preparing the rest of the big GML. 

Now I wonder if GDAL/OGR WFS client can take advantage of that? Will I be able to access the first few features while the streaming is still going on? It seems to me that it doesn't because it always waiting the whole big GML response is loaded in memory.

Thanks
_______________________________________________
gdal-dev mailing list
gdal-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Permalink | Reply | 2 comments |
headers
David B�langer | 16 May 20:49
Picon

RE: GDAL 1.9 and PostGis raster

Hi,
I have tried the version MSVC2008 (Win32) -development available today  at  http://www.gisinternals.com/sdk/ and I have still the same problem. For your information, I'm running GDAL on windows with a PostGIS 2.0 connection on 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 an important project in Canada where processing time is very important.

Does any developper has an idea for this problem ?
 
Thanks
 
David Bélanger
 
 
 
> Date: Wed, 16 May 2012 07:38:30 -0700
> Subject: Re: [gdal-dev] GDAL 1.9 and PostGis raster
> From: bkpark <at> ucdavis.edu
> To: belanger_david <at> live.ca
>
> David,
>
> The PostGIS Raster driver in GDAL was and still is in a state of flux.
> GDAL 1.9 should be better than 1.8 as there were significant changes
> to PostGIS Raster before 2.0 and 2.0. You may want to try GDAL trunk.
>
> -bborie
>
> On Tue, May 15, 2012 at 6:37 PM, David B�langer <belanger_david <at> live.ca> wrote:
> > 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.
> >
> >
> >
> > Does anyone know this problem and can you help me?
> >
> >
> >
> > Thanks
> >
> > David
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev <at> lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> Bborie Park
> Programmer
> Center for Vectorborne Diseases
> UC Davis
> 530-752-8380
> bkpark <at> ucdavis.edu
_______________________________________________
gdal-dev mailing list
gdal-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Permalink | Reply | 0 comments |
headers
Billy Newman | 16 May 16:52
Picon

EPSG PCS/GCS code 5171 not found

When I run gdalinfo or gdalwarp on a tiff that is a one band image
with elevation data I get the following warning:

EPSG PCS/GCS code 5171 not found in EPSG support files.

I have GDAL_DATA set to /usr/local/share/gdal which I verified has the
data.  However looking at the supporting data files in that directory
it looks like 5171 is probably a VCS.

I would like to use gdalwarp to warp to EPSG:4326 but I am not sure
what gdalwarp is going to do with that, i.e. am I going to lose
information.  Note: gdalwarp also throws the same warning message.

Has anyone had any experience with this?

Thanks,
Billy
Permalink | Reply | 0 comments |
headers
Billy Newman | 16 May 16:13
Picon

gdalwarp question

If I do not provide a source spatial reference to gdalwarp will the information in the geotiff be used instead?  ie. gdalwarp -t_srs 'EPSG:4326' input.tif output.tif?

I do not have a real example because I do not have the file I am working with on this computer.  But an example gdalinfo would be:

PROJCS["NAD27 / UTM zone 11N", GEOGCS["NAD27", DATUM["North_American_Datum_1927", SPHEROID["Clarke 1866",6378206.4,294.978698213901]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-117], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1]]So would my above example work when trying to convert this projection to EPSG:4326, or do I need to specify the source spatial reference and/or other parameters.

Thanks
Billy
_______________________________________________
gdal-dev mailing list
gdal-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Permalink | Reply | 1 comment |
headers
William Kyngesburye | 16 May 15:50
Favicon

Re: troubles building trunk on OSX + Xcode 4.3

On May 16, 2012, at 6:03 AM, J Luis wrote:

> 
> From it's placement in the above and a vague memory of the old ecw builds, I suspect the carbon part comes
from ECW.  those separate libNCEcw* libraries are an old way of building ECW, the newer method builds as a
single libecwj2.  ECW is a PITA to compile on OSX (my notes still leave some unsolved problems).
> 
> Yes, you are right. I built --with-ecw=no and that part disappeared. I use this old one because (if I
remember well) its license terms are much liberal, and because it works as I have it.
> 
The same version also has the single libecwj2 build option.  See my build instructions on my site.

>  But for the error, it maybe because it's using the wrong command to link - this is C++, and that's where the
new() op is from.  Normally, the easy way to link is use g++, which automatically links the necessary C++
library.  But your link command is using gcc, which would need the C++ library linked in manually.  This is
odd because libtool is passed g++, but ends up using gcc.  Did you update libtool in your GDAL source?
> 
>  
> I didn't mentioned explicitly but I did a svn update so the code should be very close to what's in 1.9.1rc
> Anyone building the release candidate on OSX with XCode 4.3.2 successfully?
> 
> Joaquim

1.9.1rc compiles with no problems (quick-n-dirty, no extras).

I just noticed something else, but I don't know if it's a problem - your libtool command has a "--tag=LD" flag
in it, mine doesn't not.  You also get that message about ignoring unknown tag, and I wonder if it somehow
confuses libtool so that it drops the g++.  What is your configure command?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account
for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe
Permalink | Reply | 3 comments |
headers
Oyvind Idland | 16 May 10:10
Picon

WFS client - missing namespace in filter

Hello,

there is a minor bug in the filter submitted by WFS GET requests:

The wfs namespace is missing. The current implementation sends

<Filter xmlns:gml="http://www.opengis.net/gml">

but should be

<Filter xmlns="http://www.opengis.net/wfs" xmlns:gml="http://www.opengis.net/gml">


regards,


Oyvind Idland

_______________________________________________
gdal-dev mailing list
gdal-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Permalink | Reply | 3 comments |
headers
David B�langer | 16 May 03:37
Picon

GDAL 1.9 and PostGis raster

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.

 

Does anyone know this problem and can you help me?

 

Thanks

David

_______________________________________________
gdal-dev mailing list
gdal-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Permalink | Reply | 0 comments |
headers
jluis | 16 May 01:49
Picon
Favicon

troubles building trunk on OSX + Xcode 4.3


Hi,

Sorry to come again with a building problem. Now on OSX 10.7.4
For forced updating reasons I was obliged to up start a chain of up  
updates that ended up on upgrading to Xcode 4.3.2 and now I get these  
errors linking (well, a lot more)

/System/Library/Frameworks/Carbon.framework/Carbon

is a symlink to

/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon

but than what?

Any idea how to solve this?

Thanks

Joaquim

ld: warning: path '/System/Library/Frameworks/Carbon.framework/Carbon'  
following -L not a directory
Undefined symbols for architecture x86_64:
   "operator new(unsigned long)", referenced from:
       IdrisiDataset::IdrisiDataset()in IdrisiDataset.o
       _GDALRegister_IDRISI in IdrisiDataset.o
       IdrisiDataset::Open(GDALOpenInfo*)       in IdrisiDataset.o
       IdrisiRasterBand::GetDefaultRAT()       in IdrisiDataset.o
       IdrisiRasterBand::SetDefaultRAT(GDALRasterAttributeTable  
const*)   in IdrisiDataset.o
       IntergraphRasterBand::IntergraphRasterBand(IntergraphDataset*,  
int, int, GDALDataType)in IntergraphBand.o
       _GDALRegister_INGR in IntergraphDataset.o

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Permalink | Reply | 4 comments |
headers
Frank Warmerdam | 15 May 16:35
Picon
Favicon
Gravatar

GDAL/OGR 1.9.1 Release Candidate

Folks,

I have prepared a GDAL/OGR 1.9.1 Release Candidate at:

   http://download.osgeo.org/gdal/gdal-1.9.1RC1.tar.gz
   http://download.osgeo.org/gdal/gdal191RC1.zip

Please test and confirm there are no regressions since 1.9.0.  I'll send
a separate message motioning to declare this 1.9.1 final once I've done a
bit of testing myself.

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush    | Geospatial Software Developer
Permalink | Reply | 5 comments |
headers
Mateusz Loskot | 15 May 14:48
Gravatar

Building trunk with VS2010 SP1

Folks,

Has anyone successfully built GDAL trunk using
Visual Studio 2010 with SP1 installed?

Best regards,
--

-- 
Mateusz Loskot, http://mateusz.loskot.net
Permalink | Reply | 1 comment |

Gmane