Re: [gdal-dev] [Qgis-developer] EPSG 8.0 Upgrade

2012-12-11 Thread pcreso
On a sort of related topic, (another NZ projection :-)

EPSG:3994 supercedes EPSG:3752, as EPSG got the initial specification wrong. 
This is a projection used for the wider region around NZ, rather than the NZ 
mainland, and this projection is used primarily in ESRI to avoid 180 meridian 
issues.

I assume once QGIS picks up the new GDAL which picks up the current EPSG list, 
it will natively support 3994 instead of 3752.

I was also wondering if there is any reason that 
http://www.spatialreference.org/ref/epsg/3994/ does not include a Postgis, 
Mapserver or Proj.4 definition, and if there is any way the map there could 
show the area covered by the coordinate system rather than the longitudes not 
covered?

Thanks,

  Brent Wood



--- On Wed, 12/12/12, Jeremy Palmer  wrote:

From: Jeremy Palmer 
Subject: Re: [Qgis-developer] [gdal-dev] EPSG 8.0 Upgrade
To: "Frank Warmerdam" 
Cc: "gdal-dev" , "qgis-develo...@lists.osgeo.org" 

Date: Wednesday, December 12, 2012, 8:34 AM

Hi Frank,

Yes it would be great if grid shifts are supported in proj.4 by default, but 
for more importantly for us within Qgis. Currently I see QGIS builds it's CRS 
database using crssync which relies on GDAL OSRExportToProj4 for creating 
proj.4 strings. Does that mean that the gdal CSV files also need to support the 
grid shift? Before I raise any tickets it would be good to know where to 
actually fix the problem.

nzgd2kgrid0005.grd is the transformation between NZGD1949 and NZGD2000, not 
WGS84 and NZGD2000. See more information here 
http://www.linz.govt.nz/geodetic/software-downloads#distortiongrid. 
nzgd2kgrid0005.grd is created from the ASCII file which can be downloaded here 
http://www.linz.govt.nz/sites/default/files/geodetic/software-downloads/nzgd2kgrid9911.zip

Cheers,
Jeremy
 

From: fwarmer...@gmail.com [fwarmer...@gmail.com] On Behalf Of Frank Warmerdam 
[warmer...@pobox.com]
Sent: Saturday, 8 December 2012 8:03 a.m.
To: Jeremy Palmer
Cc: gdal-dev; meta...@lists.osgeo.org
Subject: Re: [gdal-dev] EPSG 8.0 Upgrade

Jeremy,

Unfortunately I do not automatically pickup references to grid shift files from 
the EPSG database.  To the extent these are supported it is accomplished by 
special hackery. In fact skimming the epsg file, I think the only datum for 
which grid shift files are used *by default* is NAD27.   Perhaps this would be 
a good time for me to review how to utilize at least the grid shift files we 
are distributing with PROJ.4 like ntf_r93.gsb and nzgd2kgrid0005.gsb.

Hmm, I am getting the impression that nzgd2kgrid0005.grd is actually the 
transformation between NZGD2000 and WGS84 and that we would actually need 
another file - possibly something like Nzgd49ToNzgd2K.gdc to support NZGD1949 - 
is that right?

I'd suggest you file a ticket in the PROJ.4 Trac on this issue with suggestions 
on how to proceed.

Best regards,
Frank



On Thu, Dec 6, 2012 at 10:12 AM, Jeremy Palmer 
mailto:jpal...@linz.govt.nz>> wrote:
HI Frank,

Thanks that's great news. Has this upgrade now started supporting data shift 
grids, such as NZGD2000<->NZGD1949?

Cheers
Jeremy

From: gdal-dev-boun...@lists.osgeo.org 
[gdal-dev-boun...@lists.osgeo.org] On 
Behalf Of Frank Warmerdam [warmer...@pobox.com]
Sent: Thursday, 6 December 2012 1:18 p.m.
To: PROJ.4 and general Projections Discussions; GeoTIFF; gdal-dev; 
meta...@lists.osgeo.org
Subject: [gdal-dev] EPSG 8.0 Upgrade

Folks,

At the request of Howard Butler, I have upgraded PROJ.4, libgeotiff, and
GDAL to use the EPSG 8.0 database in development "trunk".

This was accomplished, as usual based on the process described here:

   http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

Amoung other things this will result in some datums having new preferred
datum shift solutions.  Upgrade with care.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, 
warmer...@pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush    | Geospatial Software Developer

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

This message contains information, which is confidential and may be subject to 
legal privilege. If you are not the intended recipient, you must not peruse, 
use, disseminate, distribute or copy this message. If you have received this 
message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. 
LINZ accepts no responsibility for changes to this email, or fo

[gdal-dev] image Compilation of Qgis 1.8 with gdal svn (Windows7_64bits)

2012-12-11 Thread image
Hello,

I need to use qgis 1.8 with the last gdal svn 1.10.0 on my Windows 7 64 bits
station.I know that i'm obliged to compile in a 1st time gdal svn & in a 2nd
time qgis targetting the gdal svn version. Up to now, i succeed in compiling
gdal svn thanks to "TortoiseSvn" & Visual Studio. Now, i 'm trying to
compile Qgis1.8 thanks to this following "help install_api" :
 http://www.qgis.org/api/INSTALL.html#toc13

I 'm following the 4th part of this webpage called "Building on windows". I
have chosen to use Visual C++ Express edition rather than MinGW. Up to now,
i installed :*Cmake/Flex/Bison/SVN/GIT/OSGeo4W. For information, i have not
installed  the "Microsoft Windows Server® 2003 R2 Platform SDK" (Core
SDK/Build environment(x86 32 bits).
Then, thanks to OSGeo4W(advanced_installation), i installed
:*expat/fcgi/gdal/grass/gsl-devel/iconv/pyqt4/qt4-devel/qwt5-devel-qt4/sip/spatialite/libspatialindex-devel/python-qscintilla.
For information, i chosen "Gdal_dev 1.8-Pre6"  even if i want the last
version of gdal dev called "1.10.0", unselectable via this OSGeo4W_setup.
Then, i pasted the file unistd.h from "GnuWin32\include" toward VC\include
directory of my Visual C++ installation.

Now, i'm at the step 4.1.3 called 'Setting up the Visual Studio project with
CMake'. I do not understand the instructions and how to create the batch
file.

1/ Do you think the method that I opted is adapted to my goal (use qgis with
the last version of gdal svn that i have already compiled) ? This method is
really the easiest and most viable?

2/Could you give me details in order i succeed  in creating the batch file.

3/How to ensure that  the building take into account the gdal svn that i
have already compiled?

In advance, thank you to throw light for me.
With kind regards.  

IMAGE 



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/image-Compilation-of-Qgis-1-8-with-gdal-svn-Windows7-64bits-tp5022355.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdalwarp -ts issue when output size is too large.

2012-12-11 Thread Jerl Simpson
I'm having an issue using gdalwarp to interpolate over some data to smooth
it out.
gdalwarp --version
GDAL 1.9.1, released 2012/05/16

I have a dataset that's rather small:
gdalinfo shows:

Size is 360, 181
Coordinate System is `'
Origin = (-0.500,90.500)
Pixel Size = (1.000,-1.000)
Size is 360, 181
Coordinate System is `'
Origin = (-0.500,90.500)
Pixel Size = (1.000,-1.000)

For testing I'm using
gdalwarp -of netCDF -r cubicspline -ts WIDTH 0 in.nc out.nc

Everything is great, until I get the WIDTH >= 5765

My data goes from 0-360.  When I'm below 5765, I see the full set of data
when I use ncview or gdaldem to view results.  When I am at or above 5765,
however, I only see the data from 180-360.

Exactly half the data is missing, and it's always missing from 0-180.
File size is 64Mb, so it's not an issue with being over the 2Gb limit.

gdalinfo on the warped image is:
Size is 5765, 2899
Coordinate System is `'
Origin = (-0.500,90.500)
Pixel Size = (0.062445793581960,-0.062445793581960)

Does anyone have an insight as to what might be going on?

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

Re: [gdal-dev] EPSG 8.0 Upgrade

2012-12-11 Thread Jeremy Palmer
Hi Frank,

Yes it would be great if grid shifts are supported in proj.4 by default, but 
for more importantly for us within Qgis. Currently I see QGIS builds it's CRS 
database using crssync which relies on GDAL OSRExportToProj4 for creating 
proj.4 strings. Does that mean that the gdal CSV files also need to support the 
grid shift? Before I raise any tickets it would be good to know where to 
actually fix the problem.

nzgd2kgrid0005.grd is the transformation between NZGD1949 and NZGD2000, not 
WGS84 and NZGD2000. See more information here 
http://www.linz.govt.nz/geodetic/software-downloads#distortiongrid. 
nzgd2kgrid0005.grd is created from the ASCII file which can be downloaded here 
http://www.linz.govt.nz/sites/default/files/geodetic/software-downloads/nzgd2kgrid9911.zip

Cheers,
Jeremy
 

From: fwarmer...@gmail.com [fwarmer...@gmail.com] On Behalf Of Frank Warmerdam 
[warmer...@pobox.com]
Sent: Saturday, 8 December 2012 8:03 a.m.
To: Jeremy Palmer
Cc: gdal-dev; meta...@lists.osgeo.org
Subject: Re: [gdal-dev] EPSG 8.0 Upgrade

Jeremy,

Unfortunately I do not automatically pickup references to grid shift files from 
the EPSG database.  To the extent these are supported it is accomplished by 
special hackery. In fact skimming the epsg file, I think the only datum for 
which grid shift files are used *by default* is NAD27.   Perhaps this would be 
a good time for me to review how to utilize at least the grid shift files we 
are distributing with PROJ.4 like ntf_r93.gsb and nzgd2kgrid0005.gsb.

Hmm, I am getting the impression that nzgd2kgrid0005.grd is actually the 
transformation between NZGD2000 and WGS84 and that we would actually need 
another file - possibly something like Nzgd49ToNzgd2K.gdc to support NZGD1949 - 
is that right?

I'd suggest you file a ticket in the PROJ.4 Trac on this issue with suggestions 
on how to proceed.

Best regards,
Frank



On Thu, Dec 6, 2012 at 10:12 AM, Jeremy Palmer 
mailto:jpal...@linz.govt.nz>> wrote:
HI Frank,

Thanks that's great news. Has this upgrade now started supporting data shift 
grids, such as NZGD2000<->NZGD1949?

Cheers
Jeremy

From: gdal-dev-boun...@lists.osgeo.org 
[gdal-dev-boun...@lists.osgeo.org] On 
Behalf Of Frank Warmerdam [warmer...@pobox.com]
Sent: Thursday, 6 December 2012 1:18 p.m.
To: PROJ.4 and general Projections Discussions; GeoTIFF; gdal-dev; 
meta...@lists.osgeo.org
Subject: [gdal-dev] EPSG 8.0 Upgrade

Folks,

At the request of Howard Butler, I have upgraded PROJ.4, libgeotiff, and
GDAL to use the EPSG 8.0 database in development "trunk".

This was accomplished, as usual based on the process described here:

   http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

Amoung other things this will result in some datums having new preferred
datum shift solutions.  Upgrade with care.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, 
warmer...@pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush| Geospatial Software Developer

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

This message contains information, which is confidential and may be subject to 
legal privilege. If you are not the intended recipient, you must not peruse, 
use, disseminate, distribute or copy this message. If you have received this 
message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. 
LINZ accepts no responsibility for changes to this email, or for any 
attachments, after its transmission from LINZ. Thank You.



--
---+--
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 Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] FIDN-issue

2012-12-11 Thread s duclos
Nikhil,


I loaded your S57. Here's a typical output for FIDN in US51.000

S52.c:2719 in S52_loadLayer(): LOADING LAYER NAME: LIGHTS
S57ogr.c:81 in _setAtt(): FIDN:44884
S57ogr.c:81 in _setAtt(): FIDN:44877
S57ogr.c:81 in _setAtt(): FIDN:44885
S57ogr.c:81 in _setAtt(): FIDN:1521038204 // --> 44886 !
S57ogr.c:81 in _setAtt(): FIDN:-1257713504    // --> 44887 !
S57ogr.c:81 in _setAtt(): FIDN:-72495485    // --> 44888 !
S57ogr.c:81 in _setAtt(): FIDN:-2048579800    // --> 44889 !
S57ogr.c:81 in _setAtt(): FIDN:44880
S57ogr.c:81 in _setAtt(): FIDN:44872
S57ogr.c:81 in _setAtt(): FIDN:44881
S57ogr.c:81 in _setAtt(): FIDN:44873
S57ogr.c:81 in _setAtt(): FIDN:44882
S57ogr.c:81 in _setAtt(): FIDN:44874
S57ogr.c:81 in _setAtt(): FIDN:44883
S57ogr.c:81 in _setAtt(): FIDN:44875
S57ogr.c:81 in _setAtt(): FIDN:44876
S57ogr.c:81 in _setAtt(): FIDN:44879
S57ogr.c:81 in _setAtt(): FIDN:44878
S57ogr.c:81 in _setAtt(): FIDN:44886
S57ogr.c:81 in _setAtt(): FIDN:44887
S57ogr.c:81 in _setAtt(): FIDN:2054113595    // --> 44888 !



This chart is in the Indian Ocean in the middle of nowhere !

Sound like a chart you've made yourself. That lead me to think
that the culprit might be the soft that made this S57.

Most of your FIDN seem consistent but, for example, the 4th line:

1521038204 should be 44886



Sound like a rollover or something like that ..


rgds,

Sylvain.



>
> From: Nikhil Sai Parupalli 
>To: "gdal-dev@lists.osgeo.org"  
>Cc: 'Frank Warmerdam' ; 's duclos' 
> 
>Sent: Tuesday, December 11, 2012 2:19:26 AM
>Subject: FIDN-issue
> 
>
> 
>Hi ,
> 
>In my application I am fetching S57 data set where it is fetching FIDN with 
>negative value which is wrong  because FIDN should be in Range: 1 to 2 power 
>32-1
>Is there any instance that any one got the same issue.
>If the same data source is loaded in Caris Easy view it is showing some other 
>legal value.
> 
>Please load the sample data with any application in open source it will show 
>the same as mentioned above
> 
> 
> 
> 
> 
>Thanks and Regards
>Nikhil Sai Parupalli
> 
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Overviews using GDAL

2012-12-11 Thread Dmitry Baryshnikov

Hi,

When you use RasterIO 
(http://www.gdal.org/classGDALDataset.html#ae077c53268d2272eebed10b891a05743) 
GDAL automatically switch to right overview based on input parameters. I 
think ArcGIS do it the same way.


Regards,
Dmitry

11.12.2012 16:58, HariPrasad пишет:

Iam beginner to GDAL.

I have an Image which has internal overviews in it. I am able to display
each overview separately, but i want to dynamically select the corresponding
overview when that image is zoomed in/out. Which method i need to use in
GDAL to achieve this functionality.  And how does ArcEditor 10 understand
which overview to display.



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/Overviews-using-GDAL-tp506.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
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] Overviews using GDAL

2012-12-11 Thread HariPrasad
Iam beginner to GDAL.

I have an Image which has internal overviews in it. I am able to display
each overview separately, but i want to dynamically select the corresponding
overview when that image is zoomed in/out. Which method i need to use in
GDAL to achieve this functionality.  And how does ArcEditor 10 understand
which overview to display.



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/Overviews-using-GDAL-tp506.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev