[gdal-dev] Gamma parameter not set in proj4 string for RSO projections
Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4 is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems that
it is not set in
https://svn.osgeo.org/fdo/trunk/Thirdparty/gdal/ogr/ogr_srs_proj4.cpp:
else if( EQUAL(pszProj,omerc) )
{
SetHOM( OSR_GDV( papszNV, lat_0, 0.0 ),
OSR_GDV( papszNV, lonc, 0.0 ),
OSR_GDV( papszNV, alpha, 0.0 ),
0.0, /* ??? */
OSR_GDV( papszNV, k, 1.0 ),
OSR_GDV( papszNV, x_0, 0.0 ),
OSR_GDV( papszNV, y_0, 0.0 ) );
}
...
else
{
sprintf( szProj4+strlen(szProj4),
+proj=omerc +lat_0=%.16g +lonc=%.16g +alpha=%.16g
+k=%.16g +x_0=%.16g +y_0=%.16g ,
GetNormProjParm(SRS_PP_LATITUDE_OF_ORIGIN,0.0),
GetNormProjParm(SRS_PP_CENTRAL_MERIDIAN,0.0),
GetNormProjParm(SRS_PP_AZIMUTH,0.0),
GetNormProjParm(SRS_PP_SCALE_FACTOR,1.0),
GetNormProjParm(SRS_PP_FALSE_EASTING,0.0),
GetNormProjParm(SRS_PP_FALSE_NORTHING,0.0) );
}
There seems to be some uncertainty about this parameter. How can this be
resolved and how can I help?
Thanks.
*Hilmy*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
Selon Hilmy Hashim hil...@gmail.com:
Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4 is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems that
it is not set in
https://svn.osgeo.org/fdo/trunk/Thirdparty/gdal/ogr/ogr_srs_proj4.cpp:
-- You are not looking to the right repository (the one above is an import of
an older GDAL version by the FDO project). The main GDAL repository is located
at http://svn.osgeo.org/gdal/trunk.
I can see that a fix for the gamma parameter in
http://trac.osgeo.org/gdal/changeset/18950. This is in GDAL 1.8.0 and the
testepsg utility gives :
PROJ.4 rendering of [EPSG:3168] = +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0
257905 +k=0.99984 +x_0=804670.24 +y_0=0 +gamma=323.130102361 +a=6377295.664
+b=6356094.667915204 +units=m +no_defs
else if( EQUAL(pszProj,omerc) )
{
SetHOM( OSR_GDV( papszNV, lat_0, 0.0 ),
OSR_GDV( papszNV, lonc, 0.0 ),
OSR_GDV( papszNV, alpha, 0.0 ),
0.0, /* ??? */
OSR_GDV( papszNV, k, 1.0 ),
OSR_GDV( papszNV, x_0, 0.0 ),
OSR_GDV( papszNV, y_0, 0.0 ) );
}
...
else
{
sprintf( szProj4+strlen(szProj4),
+proj=omerc +lat_0=%.16g +lonc=%.16g +alpha=%.16g
+k=%.16g +x_0=%.16g +y_0=%.16g ,
GetNormProjParm(SRS_PP_LATITUDE_OF_ORIGIN,0.0),
GetNormProjParm(SRS_PP_CENTRAL_MERIDIAN,0.0),
GetNormProjParm(SRS_PP_AZIMUTH,0.0),
GetNormProjParm(SRS_PP_SCALE_FACTOR,1.0),
GetNormProjParm(SRS_PP_FALSE_EASTING,0.0),
GetNormProjParm(SRS_PP_FALSE_NORTHING,0.0) );
}
There seems to be some uncertainty about this parameter. How can this be
resolved and how can I help?
Thanks.
*Hilmy*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
Merci Even,
Didn't know which one is the effective code, there are so many versions
around. It's good to know that changes have been made.
I'm using QGis 1.7 dev and the About say it's using GDAL/OGR 1.8.0. How come
the +gamma is not included there?
Regards
*Hilmy*
On Thu, Apr 14, 2011 at 3:27 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Hilmy Hashim hil...@gmail.com:
Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4
is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems
that
it is not set in
https://svn.osgeo.org/fdo/trunk/Thirdparty/gdal/ogr/ogr_srs_proj4.cpp:
-- You are not looking to the right repository (the one above is an import
of
an older GDAL version by the FDO project). The main GDAL repository is
located
at http://svn.osgeo.org/gdal/trunk.
I can see that a fix for the gamma parameter in
http://trac.osgeo.org/gdal/changeset/18950. This is in GDAL 1.8.0 and the
testepsg utility gives :
PROJ.4 rendering of [EPSG:3168] = +proj=omerc +lat_0=4 +lonc=102.25
+alpha=323.0
257905 +k=0.99984 +x_0=804670.24 +y_0=0 +gamma=323.130102361
+a=6377295.664
+b=6356094.667915204 +units=m +no_defs
else if( EQUAL(pszProj,omerc) )
{
SetHOM( OSR_GDV( papszNV, lat_0, 0.0 ),
OSR_GDV( papszNV, lonc, 0.0 ),
OSR_GDV( papszNV, alpha, 0.0 ),
0.0, /* ??? */
OSR_GDV( papszNV, k, 1.0 ),
OSR_GDV( papszNV, x_0, 0.0 ),
OSR_GDV( papszNV, y_0, 0.0 ) );
}
...
else
{
sprintf( szProj4+strlen(szProj4),
+proj=omerc +lat_0=%.16g +lonc=%.16g +alpha=%.16g
+k=%.16g +x_0=%.16g +y_0=%.16g ,
GetNormProjParm(SRS_PP_LATITUDE_OF_ORIGIN,0.0),
GetNormProjParm(SRS_PP_CENTRAL_MERIDIAN,0.0),
GetNormProjParm(SRS_PP_AZIMUTH,0.0),
GetNormProjParm(SRS_PP_SCALE_FACTOR,1.0),
GetNormProjParm(SRS_PP_FALSE_EASTING,0.0),
GetNormProjParm(SRS_PP_FALSE_NORTHING,0.0) );
}
There seems to be some uncertainty about this parameter. How can this be
resolved and how can I help?
Thanks.
*Hilmy*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
Selon Hilmy Hashim hil...@gmail.com:
Merci Even,
Didn't know which one is the effective code, there are so many versions
around. It's good to know that changes have been made.
I'm using QGis 1.7 dev and the About say it's using GDAL/OGR 1.8.0. How come
the +gamma is not included there?
I know they have updated very recently their srs.db to sync it with GDAL 1.8.0.
Perhaps you should also update to the latest svn version of qgis ?
A comment in the GDAL code also shows that the +gamma parameter is only
understood by PROJ 4.8.0 (so the svn version as 4.8.0 is unreleased yet).
But one thing is definitely weird and should be investigated first : epsg_tr.py
-proj4 3168 *should* show the +gamma parameter (whatever your proj version is).
If you don't see it, it's a clear sign you don't use GDAL 1.8.0.
What does epsg_tr.py --version return ?
Regards
*Hilmy*
On Thu, Apr 14, 2011 at 3:27 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Hilmy Hashim hil...@gmail.com:
Sorry to bring this up again. I've been looking for why epsg_tr.py -proj4
is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems
that
it is not set in
https://svn.osgeo.org/fdo/trunk/Thirdparty/gdal/ogr/ogr_srs_proj4.cpp:
-- You are not looking to the right repository (the one above is an import
of
an older GDAL version by the FDO project). The main GDAL repository is
located
at http://svn.osgeo.org/gdal/trunk.
I can see that a fix for the gamma parameter in
http://trac.osgeo.org/gdal/changeset/18950. This is in GDAL 1.8.0 and the
testepsg utility gives :
PROJ.4 rendering of [EPSG:3168] = +proj=omerc +lat_0=4 +lonc=102.25
+alpha=323.0
257905 +k=0.99984 +x_0=804670.24 +y_0=0 +gamma=323.130102361
+a=6377295.664
+b=6356094.667915204 +units=m +no_defs
else if( EQUAL(pszProj,omerc) )
{
SetHOM( OSR_GDV( papszNV, lat_0, 0.0 ),
OSR_GDV( papszNV, lonc, 0.0 ),
OSR_GDV( papszNV, alpha, 0.0 ),
0.0, /* ??? */
OSR_GDV( papszNV, k, 1.0 ),
OSR_GDV( papszNV, x_0, 0.0 ),
OSR_GDV( papszNV, y_0, 0.0 ) );
}
...
else
{
sprintf( szProj4+strlen(szProj4),
+proj=omerc +lat_0=%.16g +lonc=%.16g +alpha=%.16g
+k=%.16g +x_0=%.16g +y_0=%.16g ,
GetNormProjParm(SRS_PP_LATITUDE_OF_ORIGIN,0.0),
GetNormProjParm(SRS_PP_CENTRAL_MERIDIAN,0.0),
GetNormProjParm(SRS_PP_AZIMUTH,0.0),
GetNormProjParm(SRS_PP_SCALE_FACTOR,1.0),
GetNormProjParm(SRS_PP_FALSE_EASTING,0.0),
GetNormProjParm(SRS_PP_FALSE_NORTHING,0.0) );
}
There seems to be some uncertainty about this parameter. How can this be
resolved and how can I help?
Thanks.
*Hilmy*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and
setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04
box with GDAL 1.7.3, the gamma is not there.
I've just updated QGis 1.7.0-114 and I don't get the gamma in the CRS
listing.
Thanks
*Hilmy*
On Thu, Apr 14, 2011 at 3:51 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Hilmy Hashim hil...@gmail.com:
Merci Even,
Didn't know which one is the effective code, there are so many versions
around. It's good to know that changes have been made.
I'm using QGis 1.7 dev and the About say it's using GDAL/OGR 1.8.0. How
come
the +gamma is not included there?
I know they have updated very recently their srs.db to sync it with GDAL
1.8.0.
Perhaps you should also update to the latest svn version of qgis ?
A comment in the GDAL code also shows that the +gamma parameter is only
understood by PROJ 4.8.0 (so the svn version as 4.8.0 is unreleased yet).
But one thing is definitely weird and should be investigated first :
epsg_tr.py
-proj4 3168 *should* show the +gamma parameter (whatever your proj version
is).
If you don't see it, it's a clear sign you don't use GDAL 1.8.0.
What does epsg_tr.py --version return ?
Regards
*Hilmy*
On Thu, Apr 14, 2011 at 3:27 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Selon Hilmy Hashim hil...@gmail.com:
Sorry to bring this up again. I've been looking for why epsg_tr.py
-proj4
is
not including the +gamma (RectifiedToSkew angle) parameter for the
+proj=omerc projection as used in EPSG:3168, EPSG:3375, etc. It seems
that
it is not set in
https://svn.osgeo.org/fdo/trunk/Thirdparty/gdal/ogr/ogr_srs_proj4.cpp:
-- You are not looking to the right repository (the one above is an
import
of
an older GDAL version by the FDO project). The main GDAL repository is
located
at http://svn.osgeo.org/gdal/trunk.
I can see that a fix for the gamma parameter in
http://trac.osgeo.org/gdal/changeset/18950. This is in GDAL 1.8.0 and
the
testepsg utility gives :
PROJ.4 rendering of [EPSG:3168] = +proj=omerc +lat_0=4 +lonc=102.25
+alpha=323.0
257905 +k=0.99984 +x_0=804670.24 +y_0=0 +gamma=323.130102361
+a=6377295.664
+b=6356094.667915204 +units=m +no_defs
else if( EQUAL(pszProj,omerc) )
{
SetHOM( OSR_GDV( papszNV, lat_0, 0.0 ),
OSR_GDV( papszNV, lonc, 0.0 ),
OSR_GDV( papszNV, alpha, 0.0 ),
0.0, /* ??? */
OSR_GDV( papszNV, k, 1.0 ),
OSR_GDV( papszNV, x_0, 0.0 ),
OSR_GDV( papszNV, y_0, 0.0 ) );
}
...
else
{
sprintf( szProj4+strlen(szProj4),
+proj=omerc +lat_0=%.16g +lonc=%.16g
+alpha=%.16g
+k=%.16g +x_0=%.16g +y_0=%.16g ,
GetNormProjParm(SRS_PP_LATITUDE_OF_ORIGIN,0.0),
GetNormProjParm(SRS_PP_CENTRAL_MERIDIAN,0.0),
GetNormProjParm(SRS_PP_AZIMUTH,0.0),
GetNormProjParm(SRS_PP_SCALE_FACTOR,1.0),
GetNormProjParm(SRS_PP_FALSE_EASTING,0.0),
GetNormProjParm(SRS_PP_FALSE_NORTHING,0.0) );
}
There seems to be some uncertainty about this parameter. How can this
be
resolved and how can I help?
Thanks.
*Hilmy*
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
Hi Even, On Thu, 14. Apr 2011 at 09:51:54 +0200, Even Rouault wrote: I know they have updated very recently their srs.db to sync it with GDAL 1.8.0. Perhaps you should also update to the latest svn version of qgis ? OSGeo4W has the qgis-dev package which is a nightly build of trunk. But the sync was with PROJ and not with GDAL. And I think that was wrong. What's the process to update the SRS databases? I found a README from Frank in that it seems that geotiff is updated first, gdal from that and from there proj and postgis. Not sure what or if the metacrs project adds to the picture... Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gamma parameter not set in proj4 string for RSO projections
On 11-04-14 04:15 AM, Hilmy Hashim wrote: I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04 box with GDAL 1.7.3, the gamma is not there. I've just updated QGis 1.7.0-114 and I don't get the gamma in the CRS listing. Hilmy, For reference, in my OSGeo4W install I see: C:\warmerdaepsg_tr -proj4 3168 # Kertau (RSO) / RSO Malaya (m) 3168 +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0257905 +k=0.99984 +x_0=8046 70.24 +y_0=0 +gamma=323.130102361 +a=6377295.664 +b=6356094.667915204 +units =m +no_defs C:\warmerdaepsg_tr --version GDAL 1.8.0, released 2011/01/12 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] Gamma parameter not set in proj4 string for RSO projections
Frank, I now get the gamma with epsg_tr. The issue that remains is that the srs.db that qgis uses is not synced with the latest gdal. Thanks *Hilmy* On Thu, Apr 14, 2011 at 6:30 PM, Frank Warmerdam warmer...@pobox.comwrote: On 11-04-14 04:15 AM, Hilmy Hashim wrote: I'm using OSGeo4W on Windows 7. I just checked using the OSGeo4W shell and setting gdaldev environment epsg_tr does give me +gamma. On my Ubuntu 10.04 box with GDAL 1.7.3, the gamma is not there. I've just updated QGis 1.7.0-114 and I don't get the gamma in the CRS listing. Hilmy, For reference, in my OSGeo4W install I see: C:\warmerdaepsg_tr -proj4 3168 # Kertau (RSO) / RSO Malaya (m) 3168 +proj=omerc +lat_0=4 +lonc=102.25 +alpha=323.0257905 +k=0.99984 +x_0=8046 70.24 +y_0=0 +gamma=323.130102361 +a=6377295.664 +b=6356094.667915204 +units =m +no_defs C:\warmerdaepsg_tr --version GDAL 1.8.0, released 2011/01/12 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dateline gap
Hello: I'm having a hard time getting anything to work with the files I have. Maybe the files need to be changed or translated? Joaquim mentioned they need to be in geogs but I'm not sure how to go about checking for that or converting to that if need be. I've included output from one of the tests I ran. It works the same way with all my files no matter what the data inside is. One thing I thought was strange was that I used the -A option, and in the error message it tells me to use the -A options. Command: ps2raster -A -D./tests -E720 -TG -V -W+k testNETCDF.nc Output: ps2raster: Processing testNETCDF.nc: Find HiResBoundingBox Error: /undefined in CDF Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1151/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Current file position is 5 ps2raster: GMT FATAL ERROR: The file testNETCDF.nc has no BoundingBox in the first 20 lines or last 256 bytes. Use -A option. gdalinfo for netcdf: Driver: netCDF/Network Common Data Format Files: testNETCDF.nc Size is 512, 512 Coordinate System is `' Metadata: NC_GLOBAL#Conventions=COARDS NC_GLOBAL#calendar=standard NC_GLOBAL#comments=File NC_GLOBAL#model=geos/das NC_GLOBAL#center=gsfc Subdatasets: SUBDATASET_1_NAME=NETCDF:testNETCDF.nc:max_temp SUBDATASET_1_DESC=[15x601x1201] max_temp (32-bit floating-point) SUBDATASET_2_NAME=NETCDF:testNETCDF.nc:min_temp SUBDATASET_2_DESC=[15x601x1201] min_temp (32-bit floating-point) SUBDATASET_3_NAME=NETCDF:testNETCDF.nc:prcp SUBDATASET_3_DESC=[15x601x1201] prcp (32-bit floating-point) Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 512.0) Upper Right ( 512.0,0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) Thank you, Jerl On Tue, Apr 12, 2011 at 7:24 PM, Joaquim Luis jl...@ualg.pt wrote: Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network
Re: [gdal-dev] Dateline gap
Jerl, I suggested the ps2raster way because it's one that I know well (I'm supposed to) but probably there is also a GDAL solution (that I don't know). Since ps2raster is a GMT program I suggest that you make this questions in the GMT list. However, since I kind of start this I'll give some further infos here. Regarding the error message you got the explanation is simple. ps2raster takes a POSTSCRIPT file and converts it into other formats using ghoscript. If the ps file was created by GMT, it will detect the projection information stored as PS comments and use it to create a kml file (or geotiff btw). That means in principle ANY figure created with GMT and using plain geographical coordinates can be converted to KML. But you used ps2raster directly with the netcdf file, which is not possible at all. Finally, the netcdf file is a bit strange too. What are the coordinates? 0 512 0 512 doesn't sound like real coordinates. Joaquim Hello: I'm having a hard time getting anything to work with the files I have. Maybe the files need to be changed or translated? Joaquim mentioned they need to be in geogs but I'm not sure how to go about checking for that or converting to that if need be. I've included output from one of the tests I ran. It works the same way with all my files no matter what the data inside is. One thing I thought was strange was that I used the -A option, and in the error message it tells me to use the -A options. Command: ps2raster -A -D./tests -E720 -TG -V -W+k testNETCDF.nc Output: ps2raster: Processing testNETCDF.nc: Find HiResBoundingBox Error: /undefined in CDF Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1151/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Current file position is 5 ps2raster: GMT FATAL ERROR: The file testNETCDF.nc has no BoundingBox in the first 20 lines or last 256 bytes. Use -A option. gdalinfo for netcdf: Driver: netCDF/Network Common Data Format Files: testNETCDF.nc Size is 512, 512 Coordinate System is `' Metadata: NC_GLOBAL#Conventions=COARDS NC_GLOBAL#calendar=standard NC_GLOBAL#comments=File NC_GLOBAL#model=geos/das NC_GLOBAL#center=gsfc Subdatasets: SUBDATASET_1_NAME=NETCDF:testNETCDF.nc:max_temp SUBDATASET_1_DESC=[15x601x1201] max_temp (32-bit floating-point) SUBDATASET_2_NAME=NETCDF:testNETCDF.nc:min_temp SUBDATASET_2_DESC=[15x601x1201] min_temp (32-bit floating-point) SUBDATASET_3_NAME=NETCDF:testNETCDF.nc:prcp SUBDATASET_3_DESC=[15x601x1201] prcp (32-bit floating-point) Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 512.0) Upper Right ( 512.0,0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) Thank you, Jerl On Tue, Apr 12, 2011 at 7:24 PM, Joaquim Luisjl...@ualg.pt wrote: Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF -color-relief PNG using gdaldem color-relief ... PNG -Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG -tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into
Re: [gdal-dev] Dateline gap
Joaquim: Ok that makes more sense now. You answered some of the questions I was having, like how can ps2raster do anything with a necdf anyway? I just used the info for that one test file, because the contents were shorted. It happens with others as well like this one that has these coordinates: Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) I'll post questions on the GMT list as well. Thanks Jerl On Thu, Apr 14, 2011 at 8:06 AM, Joaquim Luis jl...@ualg.pt wrote: Jerl, I suggested the ps2raster way because it's one that I know well (I'm supposed to) but probably there is also a GDAL solution (that I don't know). Since ps2raster is a GMT program I suggest that you make this questions in the GMT list. However, since I kind of start this I'll give some further infos here. Regarding the error message you got the explanation is simple. ps2raster takes a POSTSCRIPT file and converts it into other formats using ghoscript. If the ps file was created by GMT, it will detect the projection information stored as PS comments and use it to create a kml file (or geotiff btw). That means in principle ANY figure created with GMT and using plain geographical coordinates can be converted to KML. But you used ps2raster directly with the netcdf file, which is not possible at all. Finally, the netcdf file is a bit strange too. What are the coordinates? 0 512 0 512 doesn't sound like real coordinates. Joaquim Hello: I'm having a hard time getting anything to work with the files I have. Maybe the files need to be changed or translated? Joaquim mentioned they need to be in geogs but I'm not sure how to go about checking for that or converting to that if need be. I've included output from one of the tests I ran. It works the same way with all my files no matter what the data inside is. One thing I thought was strange was that I used the -A option, and in the error message it tells me to use the -A options. Command: ps2raster -A -D./tests -E720 -TG -V -W+k testNETCDF.nc Output: ps2raster: Processing testNETCDF.nc: Find HiResBoundingBox Error: /undefined in CDF Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1151/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)-- Current allocation mode is local Current file position is 5 ps2raster: GMT FATAL ERROR: The file testNETCDF.nc has no BoundingBox in the first 20 lines or last 256 bytes. Use -A option. gdalinfo for netcdf: Driver: netCDF/Network Common Data Format Files: testNETCDF.nc Size is 512, 512 Coordinate System is `' Metadata: NC_GLOBAL#Conventions=COARDS NC_GLOBAL#calendar=standard NC_GLOBAL#comments=File NC_GLOBAL#model=geos/das NC_GLOBAL#center=gsfc Subdatasets: SUBDATASET_1_NAME=NETCDF:testNETCDF.nc:max_temp SUBDATASET_1_DESC=[15x601x1201] max_temp (32-bit floating-point) SUBDATASET_2_NAME=NETCDF:testNETCDF.nc:min_temp SUBDATASET_2_DESC=[15x601x1201] min_temp (32-bit floating-point) SUBDATASET_3_NAME=NETCDF:testNETCDF.nc:prcp SUBDATASET_3_DESC=[15x601x1201] prcp (32-bit floating-point) Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 512.0) Upper Right ( 512.0, 0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) Thank you, Jerl On Tue, Apr 12, 2011 at 7:24 PM, Joaquim Luisjl...@ualg.pt wrote: Jerl, I would do that with GMT. By using ps2raster you can convert any GMT figure (in geogs of course) into KML, and GMT has excellent care of date line transition issues. Joaquim Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my
[gdal-dev] Abstracts for FOSS4G 2011 are due tomorrow
Folks, FOSS4G 2011 presentation abstracts are due by tomorrow, April 15th. If you are thinking of attending FOSS4G 2011 in Denver and have something related to free geospatial software that you would like to present (30 minute slots including questions) then write up an abstract and submit it promptly. http://2011.foss4g.org/abstracts/ 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
[gdal-dev] Re: Dateline gap
Does anyone on the GDAL team have any suggestions on how to do this? Thank you, Jerl On Tue, Apr 12, 2011 at 2:59 PM, Jerl Simpson jsimp...@wxtrends.com wrote: Hello: I stopped by the #gdal channel on IRC to ask this question. Thank you for the help provided there. I thought it might be better if I asked a question here so I can better explain what's going on in one spot and not flood the channel. I understand this is a pixel center vs pixel edge issue. My ultimate goal is to get from a netCDF file to a google map overlay contour. The general steps I've taken, which work all the way up to about 178.29 then it just cuts off. netCDF - color-relief PNG using gdaldem color-relief ... PNG - Geocoded PNG using gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr -180.25 90.25 180.25 -90.25 on the PNG (Have also tried this with just -180 90 180 -90 PNG - tiles using gdal2tiles.py -s EPSG:4326 -z 0 -n -w google on the Geocoded PNG I guess first question, is my methodology sound? Maybe there's a better way/tool to approach the problem. Following is the output from gdalinfo, other than that, what information might I be able to provide that could help? Thank you, Jerl gdalinfo for the source netcdf: (My apologies, I'm not certain what is relevant so I'm including most everything.) Driver: netCDF/Network Common Data Format Files: test.nc Size is 721, 361 Coordinate System is `' Origin = (-180.250,90.250) Pixel Size = (0.500,-0.500) Metadata: NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#cdm_data_type=GRID NC_GLOBAL#file_format=GEMPAK NC_GLOBAL#location=test.grd NC_GLOBAL#history=Direct read of GEMPAK into NetCDF-Java 4.0 API NC_GLOBAL#_CoordinateModelRunDate=2011-04-12T00:00:00Z UVIN_NONE#long_name=testdata UVIN_NONE#units= UVIN_NONE#missing_value=-9.999000e+03 UVIN_NONE#VectorComponentFlag=gridRelative time#long_name=forecast time time#units=minute since 2011-04-12T00:00:00Z time#_CoordinateAxisType=Time lat#units=degrees_north lat#long_name=latitude coordinate lat#standard_name=latitude lat#grid_spacing=0.5 degrees_north lat#_CoordinateAxisType=Lat lon#units=degrees_east lon#long_name=longitude coordinate lon#standard_name=longitude lon#grid_spacing=0.5 degrees_east lon#_CoordinateAxisType=Lon Corner Coordinates: Upper Left (-180.250, 90.250) Lower Left (-180.250, -90.250) Upper Right ( 180.250, 90.250) Lower Right ( 180.250, -90.250) Center ( 0.000, 0.000) gdalinfo of geocoded PNG: Driver: PNG/Portable Network Graphics Files: testWorld.png testWorld.png.aux.xml Size is 4096, 4096 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.01745329251994328, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326]] Origin = (-180.000,90.000) Pixel Size = (0.08789062500,-0.04394531250) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-180.000, 90.000) (180d 0'0.00W, 90d 0'0.00N) Lower Left (-180.000, -90.000) (180d 0'0.00W, 90d 0'0.00S) Upper Right ( 180.000, 90.000) (180d 0'0.00E, 90d 0'0.00N) Lower Right ( 180.000, -90.000) (180d 0'0.00E, 90d 0'0.00S) Center ( 0.000, 0.000) ( 0d 0'0.01E, 0d 0'0.01N) Band 1 Block=4096x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=4096x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=4096x1 Type=Byte, ColorInterp=Alpha -- This communication is privileged and may contain confidential information. It's intended only for the use of the person or entity named above. If you are not the intended recipient, do not distribute or copy this communication. If you have received this communication in error, please notify the sender immediately and return the original to the email address above. © Copyright 2011 Weather Trends International, Inc. -- This communication is privileged and may contain confidential information. It's intended only for the use of the person or entity named above. If you are not the intended recipient, do not distribute or copy this communication. If you have received this communication in error, please notify the sender immediately and return the original to the email address above. © Copyright 2011 Weather Trends International, Inc. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Cleaning up the tilefilename generation in gdal2tiles.py
Martin Krüger martin.krueger at gmx.com writes: Hello I was in need to generate tiles from a geotiff to publish the image as a tms-service. So i was happy to find the gdal2tiles.py script which does the job. The only issue i stumbled over: gdal2tiles.py generates the tiles in the google format(0,0=top-left) , i need the tms format(0,0=bottom-left). Are you sure about that? I do believe that gdal2tiles.py and MapTiler program based on gdal2tiles are particularly generating TMS tiles. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few errors. On the first step I got: eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal -I/home/eadam/filegdb/dist/include -L/home/eadam/filegdb/dist/lib -I/home/eadam/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDatasource.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDriver.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbLayer.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbUtils.h:33, from ogr/ogrsf_frmts/filegdb/FGdbUtils.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning Then I added to ~.bashrc: GDAL_DRIVER_PATH=/usr/local/src/gdal export GDAL_DRIVER_PATH then: eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) ... ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Best Regards, Eli On 4/12/2011 at 11:47 AM, in message 201104122047.20004.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : Even, How do you configure gdal/ogr to build with the linux api? This is a bit involved since there's no ./configure support yet, so I compile it at hand as a plugin Here's the line I use from GDAL root source directory : g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI You must change the /home/even/filegdb/ paths to where you uncompress the filegdb API And you must define the GDAL_DRIVER_PATH environmenet variable to point to the path where ogr_filegdb.so is I'm working on getting some example datasets together. Mike Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann
[gdal-dev] gdaladdo creates very large files in 1.8 but not trunk
This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800 Last step was to add some overviews: gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128 It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr, is 375G! That was using 1.8.0. I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results. The ovr is about 3G. A dif of gdalinfo on the .tif and .ovr are the same. (I hope that is not the result of a typo when I initially typed the command. I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.) I have tried making the overviews internal and external with similar results. I also tried making the overviews on the uncompressed files (the vrt) with the same results. Then I made the overviews 1 level at a time and those results seemed reasonable. I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed. Just reporting in case it is useful. Do you want any other information? Thanks, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
Le jeudi 14 avril 2011 16:50:16, Eli Adam a écrit : I tried compiling the FileGDB OGR driver on ubuntu 8.04 and got a few errors. On the first step I got: eadam@lgis0229ubuntu:/usr/local/src/gdal$ g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport -Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal -I/home/eadam/filegdb/dist/include -L/home/eadam/filegdb/dist/lib -I/home/eadam/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDatasource.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbDriver.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbLayer.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning In file included from ogr/ogrsf_frmts/filegdb/ogr_fgdb.h:51, from ogr/ogrsf_frmts/filegdb/FGdbUtils.h:33, from ogr/ogrsf_frmts/filegdb/FGdbUtils.cpp:29: /home/eadam/filegdb/dist/include/Geodatabase.h:237: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:238: warning: ignoring #pragma warning /home/eadam/filegdb/dist/include/Geodatabase.h:242: warning: ignoring #pragma warning Just warnings due to a #pragma in filegdb headers. Although it is a bit annoying, nothing to worry about Then I added to ~.bashrc: GDAL_DRIVER_PATH=/usr/local/src/gdal export GDAL_DRIVER_PATH then: eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) ... Just add /home/eadam/filegdb/dist/lib to your LD_LIBRARY_PATH ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Yes I agree. At some point, it would be desirable for the driver to be integrated properly to the build system Best Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: FileGDB OGR driver test
I reviewed this a little further. I was mistaken in my first report, the field RDSRCDATE was created as DATE (as opposed to DateTime) and populated with null. I had mistakenly checked and reported on the field CONST_DATE which is created as an Integer and populated with null. (I don't know if the field is populated in the fgdb.) eadam@lgis0229ubuntu:/usr/local/src/gdal$ ogrinfo --formats ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory ERROR 1: libFileGDBAPI.so: cannot open shared object file: No such file or directory Supported Formats: - ESRI Shapefile (read/write) - MapInfo File (read/write) - UK .NTF (readonly) - SDTS (readonly) - TIGER (read/write) ... ... Any suggestions? I've been tracking trunk of gdal for about a year, although always in a simple fashion (no plugins etc). I would not necessarily catch something basic. Based on reading this two sites, http://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-su and http://replay.waybackmachine.org/20090301081221/http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html I fixed this by calling it this way, eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogrinfo --formats Now I get eadam@lgis0229ubuntu:~$ LD_LIBRARY_PATH=.:/home/eadam/filegdb/dist/lib ogr2ogr ODF_Lincoln_Roads_v2.shp ~/Desktop/West_Oregon_Roads.gdb ODF_Lincoln_Roads Warning 6: Field RDSRCDATE create as date field, though DateTime requested. Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to 'CONSTRUCTE' Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 RDSRCDATE has dates in it now. So it looks like this was a DateTime field and got successfully demoted to a date field. Thanks, Eli On 4/12/2011 at 11:47 AM, in message 201104122047.20004.even.roua...@mines-paris.org, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:37:06, Smith, Michael ERDC-CRREL-NH a écrit : Even, How do you configure gdal/ogr to build with the linux api? This is a bit involved since there's no ./configure support yet, so I compile it at hand as a plugin Here's the line I use from GDAL root source directory : g++ -Wall -g ogr/ogrsf_frmts/filegdb/*.c* -shared -o ogr_filegdb.so -Iport - Igcore -Iogr -Iogr/ogrsf_frmts -Iogr/ogrsf_frmts/filegdb -L. -lgdal - I/home/even/filegdb/dist/include -L/home/even/filegdb/dist/lib - I/home/even/filegdb/dist/src/FileGDBEngine/include/FileGDBLinux -lFileGDBAPI You must change the /home/even/filegdb/ paths to where you uncompress the filegdb API And you must define the GDAL_DRIVER_PATH environmenet variable to point to the path where ogr_filegdb.so is I'm working on getting some example datasets together. Mike Le mardi 12 avril 2011 19:08:24, Hermann Peifer a écrit : On 04/04/2011 05:05, Ragi Burhum wrote: Hello list, I am trying to test a new version of the FileGDB driver for OGR, but I lack enough FileGDBs to test :) Is the lack of FileGDBs still an issue? At work, we have several hundreds of them and I could check if I can make some available. ArcGIS 10 FileGDB's right ? Yes real data would be usefull. But it would also be usefull if you (or anyone else) could provide small and freely redistribuable samples (potentially fake data) with different types of geometries (1 feature for each geometry type is enough in theory), column types (integer, single, double, string, date), etc.. so that it can be included in the GDAL/OGR autotest suite. If you have an *ArcGIS 10* FileGDB and would like to test the FileGDB driver (and report back), feel free to grab a gdal-trunk binary I made for Windows. A related question: will there ever be a FileGDB driver for a non-Windows OS? Is this feasible at all? Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) Hermann ___ 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 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 mailing list gdal-dev@lists.osgeo.org
Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk
Le jeudi 14 avril 2011 17:02:36, Eli Adam a écrit : I'm not aware of any recent change in the GTiff driver that could have solved the issue you've seen. This is a bit surprising. Could you also try with the -stable builds (based on 1.8 branch) from http://vbkto.dyndns.org/sdk/ to compare ? This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800 Last step was to add some overviews: gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128 It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr, is 375G! That was using 1.8.0. I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results. The ovr is about 3G. A dif of gdalinfo on the .tif and .ovr are the same. (I hope that is not the result of a typo when I initially typed the command. I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.) I have tried making the overviews internal and external with similar results. I also tried making the overviews on the uncompressed files (the vrt) with the same results. Then I made the overviews 1 level at a time and those results seemed reasonable. I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed. Just reporting in case it is useful. Do you want any other information? Thanks, Eli ___ 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] Re: gdaladdo creates very large files in 1.8 but not trunk
Eli Adam EAdam at co.lincoln.or.us writes: It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. Hi, You can check which kind of overview file you really have with gdalinfo if you first rename the .ovr file to something.tif. Gdalinfo then shows the compression method used and sizes of overviews. No need to do guessing with OpenEV. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: gdaladdo creates very large files in 1.8 but not trunk
You can check which kind of overview file you really have with gdalinfo if you first rename the .ovr file to something.tif. Gdalinfo then shows the compression method used and sizes of overviews. No need to do guessing with OpenEV. You don't even need to rename the file. GDAL doesn't care about the extension to recognized TIFF files -Jukka Rahkonen- ___ 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] Re: FileGDB OGR driver test
Even, The I have a feeling that the handling of blobs may be a little more involved. The blobs in ESRI GeoDatabases are serialized COM SafeArrays that contain the actual binary information. So in order to *really* access the blob, one would have to strip the safearray portion out and expose the blob for reads, and wrap it with safearrays for writes so that it plays nice with the GDB. In all honesty, I am not sure, so I would have to write some tests to verify this, that is why I punted it. As far as the date fields go, filegdb uses date-time fields... thanks for extending to make them work. - Ragi On Wed, Apr 13, 2011 at 12:16 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mercredi 13 avril 2011 21:00:42, Eli Adam a écrit : Ragi, I tested the driver on just one FileGDB which included a date field. You stated, Known issues with build / FileGDB driver - (driver issue) blobs and date fields are not handled at all Yesterday, with the Michael Smith's test filegdb, I fixed the handling of date fields, so if you just update from SVN, it should work now. An example with blobs would be usefull Here is what I did and successfully got the data. The date field was made a double and populated with 0, however, since it says that date fields are not handled, it is nice that the rest of the process still worked on the other fields and the data was exported. ogr2ogr ODF_Lincoln_Roads.shp West_Oregon_Roads.gdb ODF_Lincoln_Roads Warning 6: Field RDSRCDATE create as date field, though DateTime requested. Warning 6: Normalized/laundered field name: 'CONSTRUCTED' to 'CONSTRUCTE' Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' Warning 1: Row id: 4 col:10 has unhandled col type (11). Setting to NULL. ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 ERROR 1: GDB Error: Failed to determine value for column CONST_DATE long:-2147217395 Thanks for the work on this. Eli On 4/13/2011 at 11:13 AM, in message banlktimitsqyjfixfrys05jkeibya+t...@mail.gmail.com, Ragi Burhum r...@burhum.com wrote: Perfect. Thank you Michael. - Ragi Date: Tue, 12 Apr 2011 15:45:25 -0400 From: Smith, Michael ERDC-CRREL-NH michael.sm...@usace.army.mil Subject: Re: [gdal-dev] Re: FileGDB OGR driver test To: Even Rouault even.roua...@mines-paris.org, gdal-dev@lists.osgeo.org Message-ID: c9ca2415.2220d%michael.sm...@usace.army.mil Content-Type: text/plain; charset=ISO-8859-1 I have a test v10 filegdb with points, lines, polygons (all with Z and M but I think the measures aren't populated). There are also some non geometry tables and some relationship classes. Its available at http://12.189.158.78:8081/downloads/test_fgdb.gdb.zip Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers On 4/12/11 2:48 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mardi 12 avril 2011 20:40:58, Matt Wilkie a écrit : ArcGIS 10 FileGDB's right ? If the api allows for using gdb's from different versions then the test suite should have different versions too. In any case I can make v10 gdb's. No, the FileGDB API only reads v10 gdb's. Current GDAL trunk builds against FileGDB API beta3 under Linux 32bit. Too bad ESRI doesn't provide any 64bit build of the FileGDB API (yet... ?) We are working on a Linux 64-bit release of the File Geodatabase API. It will not release with the 1.0 release of the API, but as a part of a follow on release later this year. Lance Shipman Geodatabase Product Engineer, File Geodatabase esri ___ 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] PCIDSK Write Endian Fix
PCIDSK doesn't always write in network order. I believe that it is missing a SwapPixel. Here is a trivial patch against 1.8.0. --- cpixelinterleavedchannel.cpp~ 2011-01-13 21:19:05.0 -0800 +++ cpixelinterleavedchannel.cpp2011-04-13 16:43:36.447932521 -0700 @@ -254,6 +254,8 @@ /* */ /* Do byte swapping if needed. */ /* */ +if( needs_swap ) +SwapPixels( buffer, pixel_type, width); return 1; } Regards, -- Rui-Tao Dong, Ph.D Neos Geosolutions Principal System Architect 100 Bayview Circle, Suite 300 (949)885-9979(O)Newport Beach, CA 92660 (949)287-1077(M)rd...@neosgeo.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaladdo creates very large files in 1.8 but not trunk
I'm not aware of any recent change in the GTiff driver that could have solved the issue you've seen. This is a bit surprising. Could you also try with the -stable builds (based on 1.8 branch) from http://vbkto.dyndns.org/sdk/ to compare ? I am trying it with, http://vbkto.dyndns.org/sdk/PackageList.aspx?file=release-1500-gdal-1-8-mapserver-5-6.zip Although not finished, based on progress so far, it looks to be working properly and on track to create a 3G ovr. That is consistent with trunk. I'll provide more information when it finishes. Eli This is an informational report only, there are not problems in trunk. Using 1.8.0 from OSGeo4W on XP, I made a mosaic of about 1200 uncompressed tifs totally 80G. gdalbuildvrt mosaic.vrt *.tif Then gdal_translated that to a compressed tif of about 8G gdal_translate mosaic.vrt mosaic_ycbcr_big.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHEMAX 800 Last step was to add some overviews: gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config BIGTIFF_OVERVIEW YES --config GDAL_CACHEMAX 800 -r average -ro mosaic_ycbcr_big.tif 2 4 8 16 32 64 128 It works (at least in OpenEV it displays quickly like it is using overviews), except the file sizes for the overviews seem odd and too large. The tiles are about 80G, the result of gdal_translate is 8G, the result of gdaladdo, mosaic_ycbcr_big.tif.ovr, is 375G! That was using 1.8.0. I tested on trunk on ubuntu and XP from here, http://vbkto.dyndns.org/sdk/ which produce reasonable results. The ovr is about 3G. A dif of gdalinfo on the .tif and .ovr are the same. (I hope that is not the result of a typo when I initially typed the command. I unfortunately don't have the shell around any more but took the above listed commands from some notes I took.) I have tried making the overviews internal and external with similar results. I also tried making the overviews on the uncompressed files (the vrt) with the same results. Then I made the overviews 1 level at a time and those results seemed reasonable. I didn't find any tickets about this in trac, but don't experience this in trunk so apparently it is fixed. Just reporting in case it is useful. Do you want any other information? Thanks, Eli ___ 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
