[gdal-dev] python CreateFeature() error when converting OGR features from gpsbabel layer to PostGIS layer
Hi All,
For months I've been happily pulling GPS tracks into PostGIS using ogr in a
pretty simple python script. The essence of it approximately this:
rlyr = ogr.Open(gpsbabel_src).GetLayerByName('tracks')
wlyr = ogr.Open(pg_con_string).GetLayerByName('tracks')
fid_map = {}
for feat in rlyr:
fFID = feat.GetFID()
feat.SetFID(-1)
rv = wlyr.CreateFeature(feat)
fid_map[fFID] = feat.GetFID()
It had been working great until the other day when I added another field
(start_time timestamp with time zone) to the 'tracks' table in the database.
Oddly, with this new field in the destination layer, the call to
CreateFeature() fails. Looking into the PG query log, I see that ogr is making
a curious choice of insertion fields. The INSERT statement is:
INSERT INTO "tracks" ("wkb_geometry" , "name", "number", "start_time") VALUES
(''::GEOMETRY, '279', 15, 'MULTILINESTRING') RETURNING "ogc_fid"
Note that the last field in the insert statement says "start_time" and it's
trying to insert 'MULTILINESTRING' in the field. The source layer doesn't have
any fields named start_time, so I'm not even sure why CreateFeature() would try
to insert something for it, and it certainly doesn't have anything to do with
the geometry type.
FWIW, ogr2ogr appears to do the right thing and only uses fields
("wkb_geometry" , "name", "number"), but it doesn't meet my needs for a number
of other reasons. Is this a bug in the python bindings for CreateFeature()?
Or are there any other leads that I should follow? I'm using GDAL 1.9.1.
Thanks in advance for any help that can be offered.
~James
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Selecting Python during configuration
Michael, --with-python sets the path to the python binary that you want to use and while that may not intuitively seem like it sets the install path, it actually does. If you have multiple separate python binaries installed on the system (e.g. from using virtualenv), generally each one of them has their own separate site-packages directory and when you tell configure which binary you want to use, the binary tells configure where to find the appropriate site-packages directory and where to install gdal. I did a quick example run of this, just to make sure that I'm right and the workflow is something like this: 1) Setup your separate python binary with virtualenv (or by some other means) james@granite:~$ virtualenv python-alt New python executable in python-alt/bin/python Installing distribute.done. Installing pip...done. 2a) At this point you might be able to use pip to download/build/install gdal (you just may not have as much control over the build process) james@granite:~$ ./python-alt/bin/pip install gdal Downloading/unpacking gdal Downloading GDAL-1.9.1.tar.gz (420Kb): 420Kb downloaded Running setup.py egg_info for package gdal Installing collected packages: gdal Running setup.py install for gdal building 'osgeo._gdal' extension ... Successfully installed gdal Cleaning up... james@granite:~$ ./python-alt/bin/python Python 2.7.3 (default, Aug 1 2012, 05:16:07) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gdal >>> gdal.__file__ '/home/james/python-alt/local/lib/python2.7/site-packages/gdal.pyc' >>> 2b) Or you can build from the subversion repo james@granite:~/code/svn/gdal$ ./configure --with-python=$HOME/python-alt/bin/python --prefix=$HOME ... james@granite:~/code/svn/gdal$ make ... james@granite:~/code/svn/gdal$ make install ... At this point you should have all of the gdal goodies in your python install: james@granite:~/code/svn/gdal$ ls ~/python-alt/local/lib/python2.7/site-packages/GDAL-2.0.0-py2.7-linux-i686.egg/ EGG-INFO gdalconst.py gdalconst.pyc gdal.py gdal.pyc ogr.py ogr.pyc osgeo osr.py osr.pyc james@granite:~/code/svn/gdal$ ls ~/python-alt/local/lib/python2.7/site-packages/GDAL-2.0.0-py2.7-linux-i686.egg/osgeo/ gdal_array.py _gdalconst.pyc gdalnumeric.pyc gdal.pyc _ogr.py _ogr.so osr.pyc gdal_array.pyc gdalconst.pyc _gdal.py _gdal.so ogr.py _osr.py _osr.so _gdalconst.py _gdalconst.so gdal.py __init__.py _ogr.pyc osr.py gdalconst.pygdalnumeric.py _gdal.pyc__init__.pyc ogr.pyc _osr.pyc ...and you should be able to load the gdal module. james@granite:~/code/svn/gdal$ ~/python-alt/bin/python Python 2.7.3 (default, Aug 1 2012, 05:16:07) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from osgeo import gdal >>> gdal.__file__ '/home/james/python-alt/local/lib/python2.7/site-packages/GDAL-2.0.0-py2.7-linux-i686.egg/osgeo/gdal.pyc' Hope that helps. ~James On Fri, Nov 02, 2012 at 01:01:26AM +, Michael Speth wrote: > Greetings, > > I am attempting to compile gdal with python support. However, I don't want > to use the system installed python; I want to use a locally compiled version > of > python. I am unable to find how to select the python version to use with the > gdal install. > > > > It seems that --with-python doesn't have an option to set the python install > directory; --with-hdf5 can set the install directory of hdf5. > > > > Is there a way to set gdal to point to a different install directory for > python? > > > > If not, how does gdal find the path to python? Is it possible to set an > environment variable (I am compiling on GNU/Linux)? > > > > Thanks > > > > -- > > Michael Speth > > Research Systems Developer > > Landcare Research > > > ━━━ > > Please consider the environment before printing this email > Warning: This electronic message together with any attachments is > confidential. > If you receive it in error: (i) you must not read, use, disclose, copy or > retain it; (ii) please contact the sender immediately by reply email and then > delete the emails. > The views expressed in this email may not be those of Landcare Research New > Zealand Limited. http://www.landcareresearch.co.nz > ___ > 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] gdalinfo on PostGIS rasters (GDAL 1.9)
Mathieu, Might be a couple things going on, but have you properly set the georeferencing properties of your raster? What is the output of SELECT st_georeference([raster_column]) from myraster If they're not set, then you essentially just have a picture in your database (which is why it displays properly in QGIS, but it's probably showing it in pixel space). See here: http://postgis.refractions.net/docs/RT_ST_GeoReference.html http://postgis.refractions.net/docs/RT_ST_SetGeoReference.html Or you can use ST_SetScale, ST_SetUpperLeft, and ST_SetSkew to do the same thing. ~James On Wed, Nov 07, 2012 at 05:30:26PM -0500, Mathieu Basille wrote: > Dear GDAL developers, > > I am currently working with a PostGIS data base, which contains a few > rasters imported from .img raster files. The rasters work properly in > PostGIS, and are displayed properly in QGIS. They are projected as WGS84 > (SRID 4326). They were imported using raster2pgsql, such as: > > $ raster2pgsql -s 4326 -t 25x25 -I -C -M -F raster.img myschema.myraster | > psql -h localhost -d mydb -U pguser > > In PostGIS, the raster seem fine (they look OK in 'raster_columns'). > However, if I try to access them using gdalinfo, I only get wrong > information (i.e. empty raster, wrong coordinate system, etc.). For example: > > $ gdalinfo "PG:dbname=mydb host=localhost user=pguser schema=myschema > table=myraster" > Driver: PostGISRaster/PostGIS Raster driver > Files: none associated > Size is 0, 0 > Coordinate System is: > PROJCS["ETRS89 / ETRS-TM33", > GEOGCS["ETRS89", > DATUM["European_Terrestrial_Reference_System_1989", > SPHEROID["GRS 1980",6378137,298.257222101, > AUTHORITY["EPSG","7019"]], > TOWGS84[0,0,0,0,0,0,0], > AUTHORITY["EPSG","6258"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4258"]], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]], > PROJECTION["Transverse_Mercator"], > PARAMETER["latitude_of_origin",0], > PARAMETER["central_meridian",15], > PARAMETER["scale_factor",0.9996], > PARAMETER["false_easting",50], > PARAMETER["false_northing",0], > AUTHORITY["EPSG","3045"], > AXIS["Northing",NORTH], > AXIS["Easting",EAST]] > Origin = (0.000,0.000) > Pixel Size = (1.000,1.000) > Subdatasets: > ... [list of all tiles] > Corner Coordinates: > Upper Left ( 0.000, 0.000) ( 10d30'40.52"E, 0d 0' 0.01"N) > Lower Left ( 0.000, 0.000) ( 10d30'40.52"E, 0d 0' 0.01"N) > Upper Right ( 0.000, 0.000) ( 10d30'40.52"E, 0d 0' 0.01"N) > Lower Right ( 0.000, 0.000) ( 10d30'40.52"E, 0d 0' 0.01"N) > Center ( 0.000, 0.000) ( 10d30'40.52"E, 0d 0' 0.01"N) > > Detailed set-up: > * PostGIS 2.1.0SVN (r10597) > * GDAL 1.9.0, released 2011/12/29 > * OS: Debian Wheezy > > My ultimate goal is actually to import these rasters in R, but it seems > that my first problem is between GDAL and PostGIS. Is there anything I'm > doing wrong here? > > Of course, I'd be happy to provide more information if required. Any advice > would be greatly appreciated! > > Mathieu Basille. > > > PS: I hope I'm using this list properly. Please let me know if you feel > that the question should be addressed to postgis-devel instead. > > -- > > ~$ whoami > Mathieu Basille, PhD > > ~$ locate --details > University of Florida \\ > Fort Lauderdale Research and Education Center > (+1) 954-577-6314 > http://ase-research.org/basille > > ~$ fortune > « Le tout est de tout dire, et je manque de mots > Et je manque de temps, et je manque d'audace. » > -- Paul Éluard > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- James Hiebert Lead, Computational Support Pacific Climate Impacts Consortium http://www.pacificclimate.org Room 112, University House 1, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 E-mail: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How does GDAL's NetCDF driver determine the spatial reference system
Hi All,
I'm trying to use GDAL (version 1.7.2 on Gentoo built with hdf5 and netcdf
support) to read NetCDF files, but I'm a little unclear on how the NetCDF
driver attempts to determine the georeferencing.
The driver page here:
http://www.gdal.org/frmt_netcdf.html
states that it will attempt to read the metadata "spatial_ref" for a Well
Know Text definition of the spatial reference (I assume that it means that
it will try to use a global attribute of the NetCDF file named spatial_ref).
Since this would be convenient for my application, I attempted to use GDAL
this way without success.
+ I added a global attribute named "spatial_ref" with the WKT definition of
the spatial reference system.
+ gdalinfo on the file still reports "Coordinate System is `'"
+ opening the file with the python bindings and calling dst.GetProjection()
returns a blank string (i.e. no projection information)
The full listings of my spatial reference definition, the output of ncdump
and gdalinfo and the output from the python session are listed below. Can
anyone tell me whether I'm doing something wrong, or should I not count on
georeferencing being supported by the NetCDF driver?
~James
ja...@basalt ~ $ ncatted -a
spatial_ref,global,a,c,'PROJCS["unnamed",GEOGCS["Normal Sphere
(r=6370997)",DATUM["unknown",SPHEROID["sphere",6370997,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Polar_Stereographic"],PARAMETER["latitude_of_origin",60],PARAMETER["central_meridian",263],PARAMETER["scale_factor",1],PARAMETER["false_easting",3925000],PARAMETER["false_northing",8325000]]'
narccap_ecpc-20c3m-tasmin-ncep.nc narccap_ecpc-20c3m-tasmin-ncep-with-srs.nc
ja...@basalt ~ $ ncdump -h narccap_ecpc-20c3m-tasmin-ncep-with-srs.nc
netcdf narccap_ecpc-20c3m-tasmin-ncep-with-srs {
dimensions:
xc = 123 ;
yc = 104 ;
time = UNLIMITED ; // (9496 currently)
bnds = 2 ;
variables:
char polar_stereographic ;
polar_stereographic:grid_mapping_name =
"polar_stereographic" ;
polar_stereographic:longitude_of_central_meridian = 263. ;
polar_stereographic:straight_vertical_longitude_from_pole =
263. ;
polar_stereographic:standard_parallel = 60. ;
polar_stereographic:TrueGridLength_Latitude = 60. ;
polar_stereographic:XGridLength_M = 5. ;
polar_stereographic:YGridLength_M = 5. ;
polar_stereographic:PoleOnPlane = "north" ;
polar_stereographic:false_easting = 3925000. ;
polar_stereographic:false_northing = 8325000. ;
polar_stereographic:latitude_of_projection_origin = 90. ;
double yc(yc) ;
yc:long_name = "y-coordinate of Cartesian system" ;
yc:standard_name = "projection_y_coordinate" ;
yc:axis = "Y" ;
yc:units = "m" ;
double xc(xc) ;
xc:long_name = "x-coordinate of Cartesian system" ;
xc:standard_name = "projection_x_coordinate" ;
xc:axis = "X" ;
xc:units = "m" ;
double lon(yc, xc) ;
lon:units = "degrees_east" ;
lon:long_name = "longitude" ;
lon:standard_name = "longitude" ;
lon:axis = "X" ;
lon:NX_NumPntsOnParallel = 123 ;
lon:NY_NumPntsOnMeridian = 104 ;
lon:actual_range = 211.5412f, 316.2759f ;
lon:XGridLength_M = 5. ;
lon:YGridLength_M = 5. ;
lon:PoleOnPlane = "north" ;
double lat(yc, xc) ;
lat:units = "degrees_north" ;
lat:long_name = "latitude" ;
lat:standard_name = "latitude" ;
lat:axis = "Y" ;
lat:NX_NumPntsOnParallel = 123 ;
lat:NY_NumPntsOnMeridian = 104 ;
lat:actual_range = 21.23807f, 67.63758f ;
lat:XGridLength_M = 5. ;
lat:YGridLength_M = 5. ;
lat:PoleOnPlane = "north" ;
...
// global attributes:
...
:history = "Mon Aug 9 13:44:50 2010: ncatted -a
spatial_ref,global,a,c,PROJCS[\"unnamed\",GEOGCS[\"Normal
Sphere
(r=6370997)\",DATUM[\"unknown\",SPHEROID[\"sphere\",6370997,0]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433]],PROJECTION[\"Polar_Stereographic\"],PARAMETER[\"latitude_of_origin\",60],PARAMETER[\"central_meridian\",263],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",3925000],PARAMETER[\"false_northing\",8325000]]
narccap_ecpc-20c3m-tasmin-ncep.nc
narccap_ecpc-20c3m-tasmin-ncep-with-srs.nc\n",
"Fri May 8 09:34:14 2009: ncrcat
tasmin_ECPC_1979010106.nc tasmin_ECPC_1981010106.nc
tasmin_ECPC_1986010106.nc tasmin_ECPC_1991010106.nc
tasmin_ECPC_1996010106.nc tasmin_ECPC_2
Re: [gdal-dev] How does GDAL's NetCDF driver determine the spatial reference system
Sure. The ticket can be found here:
https://trac.osgeo.org/gdal/ticket/3715
~James
On Mon, Aug 09, 2010 at 03:13:59PM -0400, Lucena, Ivan wrote:
> James,
>
> Could do file a ticked and upload a sample file on
> http://trac.osgeo.org/gdal/ ?
>
> Regards,
>
> Ivan
>
> James Hiebert wrote:
> > Hi All,
> >
> > I'm trying to use GDAL (version 1.7.2 on Gentoo built with hdf5 and netcdf
> > support) to read NetCDF files, but I'm a little unclear on how the NetCDF
> > driver attempts to determine the georeferencing.
> >
> > The driver page here:
> > http://www.gdal.org/frmt_netcdf.html
> > states that it will attempt to read the metadata "spatial_ref" for a Well
> > Know Text definition of the spatial reference (I assume that it means that
> > it will try to use a global attribute of the NetCDF file named spatial_ref).
> >
> > Since this would be convenient for my application, I attempted to use GDAL
> > this way without success.
> >
> > + I added a global attribute named "spatial_ref" with the WKT definition of
> > the spatial reference system.
> > + gdalinfo on the file still reports "Coordinate System is `'"
> > + opening the file with the python bindings and calling dst.GetProjection()
> > returns a blank string (i.e. no projection information)
> >
> > The full listings of my spatial reference definition, the output of ncdump
> > and gdalinfo and the output from the python session are listed below. Can
> > anyone tell me whether I'm doing something wrong, or should I not count on
> > georeferencing being supported by the NetCDF driver?
> >
> > ~James
> >
> > ja...@basalt ~ $ ncatted -a
> > spatial_ref,global,a,c,'PROJCS["unnamed",GEOGCS["Normal Sphere
> > (r=6370997)",DATUM["unknown",SPHEROID["sphere",6370997,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Polar_Stereographic"],PARAMETER["latitude_of_origin",60],PARAMETER["central_meridian",263],PARAMETER["scale_factor",1],PARAMETER["false_easting",3925000],PARAMETER["false_northing",8325000]]'
> > narccap_ecpc-20c3m-tasmin-ncep.nc narccap_ecpc-20c3m-tasmin-ncep-with-srs.nc
> >
> >
> > ja...@basalt ~ $ ncdump -h narccap_ecpc-20c3m-tasmin-ncep-with-srs.nc
> > netcdf narccap_ecpc-20c3m-tasmin-ncep-with-srs {
> > dimensions:
> > xc = 123 ;
> > yc = 104 ;
> > time = UNLIMITED ; // (9496 currently)
> > bnds = 2 ;
> > variables:
> > char polar_stereographic ;
> > polar_stereographic:grid_mapping_name =
> > "polar_stereographic" ;
> > polar_stereographic:longitude_of_central_meridian = 263. ;
> > polar_stereographic:straight_vertical_longitude_from_pole =
> > 263. ;
> > polar_stereographic:standard_parallel = 60. ;
> > polar_stereographic:TrueGridLength_Latitude = 60. ;
> > polar_stereographic:XGridLength_M = 5. ;
> > polar_stereographic:YGridLength_M = 5. ;
> > polar_stereographic:PoleOnPlane = "north" ;
> > polar_stereographic:false_easting = 3925000. ;
> > polar_stereographic:false_northing = 8325000. ;
> > polar_stereographic:latitude_of_projection_origin = 90. ;
> > double yc(yc) ;
> > yc:long_name = "y-coordinate of Cartesian system" ;
> > yc:standard_name = "projection_y_coordinate" ;
> > yc:axis = "Y" ;
> > yc:units = "m" ;
> > double xc(xc) ;
> > xc:long_name = "x-coordinate of Cartesian system" ;
> > xc:standard_name = "projection_x_coordinate" ;
> > xc:axis = "X" ;
> > xc:units = "m" ;
> > double lon(yc, xc) ;
> > lon:units = "degrees_east" ;
> > lon:long_name = "longitude" ;
> > lon:standard_name = "longitude" ;
> > lon:axis = "X" ;
> > lon:NX_NumPntsOnParallel = 123 ;
> > lon:NY_NumPntsOnMeridian = 104 ;
> > lon:actual_range = 211.5412f, 316.2759f ;
> > lon:XGridLength_M = 5. ;
> > lon:YGridLength_M = 5. ;
> > lon:PoleOnPlane = "north" ;
> > double lat(yc, xc) ;
> > lat:units = &
[gdal-dev] Problem using gdalwarp to reproject Lambert Conformal Conic (LCC) to longlat
All, Below is a question/probelm from one of my co-workers (who doesn't (yet) want to subscribe to the list). ~James Hiebert From: Hailey Eckstrand Date: Fri, 7 Jan 2011 13:05:10 -0800 Hello all, I am trying to reproject a geotif using gdalwarp: gdalwarp -t_srs "+proj=longlat" -s_srs "+proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637" -r bilinear -srcnodata "1e20" -dstnodata "1e20" -tr 0.5 0.5 -te -137.812943839532 33.8985446218588 -102.312943839532 63.3985446218588 mm5i-lcc.tif mm5i-latlong.tif ERROR 1: Translating source or target SRS failed: +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637 When I use the proj/invproj unix command, it works fine: invproj +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637 << EOF 80 80 85 80 90 80 EOF 125d15'53.681"W 20d51'29.908"N 124d50'5.035"W 21d0'18.418"N 124d24'10.336"W 21d8'59.642"N Any idea where the problem is? Here is my gdal build info: $ svn info Path: . URL: https://svn.osgeo.org/gdal/trunk/gdal Repository Root: https://svn.osgeo.org/gdal Repository UUID: f0d54148-0727-0410-94bb-9a71ac55c965 Revision: 21425 Node Kind: directory Schedule: normal Last Changed Author: warmerdam Last Changed Rev: 21425 Last Changed Date: 2011-01-07 11:36:23 -0800 (Fri, 07 Jan 2011) revision number 21425 Hailey Eckstrand hail...@uvic.ca<mailto:hail...@uvic.ca> GIS Analyst Pacific Climate Impacts Consortium www.PacificClimate.Org<http://www.PacificClimate.Org> C198 Segdewick Building, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 Tel: (250) 472-5591 Fax: (250) 472-4830 - End forwarded message - -- James Hiebert Lead, Computational Support Pacific Climate Impacts Consortium http://www.pacificclimate.org C178 Segdewick Building, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 E-mail: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem using gdalwarp to reproject Lambert Conformal Conic (LCC) to longlat
Thanks for the quick response. It was definitely the missing +b. It seems that proj will fill in the +b with the same value if +a is given. Adding +b to the s_srs flag did the trick. ~James On Fri, Jan 07, 2011 at 04:51:05PM -0500, Frank Warmerdam wrote: > On 11-01-07 04:18 PM, James Hiebert wrote: > > All, > > > > Below is a question/probelm from one of my co-workers (who doesn't (yet) > > want to subscribe to the list). > > > > ~James Hiebert > > > > > > From: Hailey Eckstrand > > Date: Fri, 7 Jan 2011 13:05:10 -0800 > > > > Hello all, > > I am trying to reproject a geotif using gdalwarp: > > gdalwarp -t_srs "+proj=longlat" -s_srs "+proj=lcc +lat_0=47.5 +lat_1=30.0 > > +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 +lon_0=-97.0 +a=637" -r > > bilinear -srcnodata "1e20" -dstnodata "1e20" -tr 0.5 0.5 -te > > -137.812943839532 33.8985446218588 -102.312943839532 63.3985446218588 > > mm5i-lcc.tif mm5i-latlong.tif > > > > ERROR 1: Translating source or target SRS failed: > > +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 +x_0=3825000.0 > > +lon_0=-97.0 +a=637 > > > > When I use the proj/invproj unix command, it works fine: > > > > invproj +proj=lcc +lat_0=47.5 +lat_1=30.0 +y_0=320.0 +lat_2=60.0 > > +x_0=3825000.0 +lon_0=-97.0 +a=637<< EOF > > James, > > I would suggest you collegue be more explicit about the earth models. > PROJ.4 definitions passed to GDAL utility are parsed by GDAL, converted > to WKT, and then later converted back to PROJ.4 format and so not all > definitions supported by PROJ.4 are necessarily supported by GDAL. > > In this case I suspect GDAL is confused by the lack of a +b value for > the lcc projection. It may also not handle a missing earth model on the > geographic coordinate system well. > > 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 -- James Hiebert Lead, Computational Support Pacific Climate Impacts Consortium http://www.pacificclimate.org C178 Segdewick Building, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 E-mail: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr SQL Date Calculation
In PostgreSQL, you should be able to do something like: > SELECT now() - INTERVAL '30 DAYS'; ?column? -- 2011-06-11 08:34:03.32524-07 (1 row) See table 9-26 on this page: http://www.postgresql.org/docs/8.4/static/functions-datetime.html for a wide variety of other functions and options. ~James Hiebert On Mon, Jul 11, 2011 at 04:11:54PM +0100, Langford, Robert wrote: > All, > > I am trying to use ogr2ogr as a scheduled command line task to run weekly to > convert a .SHP file to a .TAB file whilst filtering the data based on a date > field. I would like to only convert records that have a date from the last > 30 days. > > Therefore If the task ran today (11/07/2011) the below line would return the > required data: > > ogr2ogr -f "MapInfo File" -sql "select * from DCPOLY where > DATE_CREA1>'2011/06/11'" D:\Data\Plan_Apps.tab D:\Data\DCPOLY.shp > > Obviously if the task ran tomorrow the date would have to be changed to > '2011/06/12'. So I need the field SQL to be something like: > > DATE_CREA1> Todays_Date - 30 > > Does anyone know of a way to automate this using something like; GetDate(), > Now(), sysdate, Date /t, etc? Any help would be greatly appreciated. > > Many thanks, > > Rob > > > Robert Langford > Systems Developer (GIS) > Corporate Applications Team > Salford City Council > > Tel: 0161 793 2492 > Email: robert.langf...@salford.gov.uk<mailto:robert.langf...@salford.gov.uk> > Web:www.salford.gov.uk<http://www.salford.gov.uk/> > > Salford Civic Centre, > Chorley Road, Swinton, M27 5DA > > > > > DISCLAIMER: The information in this message is confidential and may be > legally privileged. It is intended solely for the addressee. > > Access to this message by anyone else is unauthorised. If you are not the > intended recipient, any disclosure, copying, or distribution of the message, > or any action or omission taken by you in reliance on it, is prohibited and > may be unlawful. > As a public body, Salford City Council may be required to disclose this email > [or any response to it] under the Freedom of Information Act 2000, unless the > information in it is covered by one of the exemptions in the Act. > Please immediately contact the sender if you have received this message in > error. > > For the full disclaimer please access http://www.salford.gov.uk/e-mail. > Thank you. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- James Hiebert Lead, Computational Support Pacific Climate Impacts Consortium http://www.pacificclimate.org Room 113, University House 1, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 E-mail: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] discussion on improvements to the NetCDF driver and CF-1 convention
FWIW my organization is a heavy user of both GDAL and geographic netcdfs (usually disparately since GDAL can't always handle the CF-1.x compliant files that we have/use/create). So if you're assessing need in the community, I'll add a +1. Not sure how much I can help; I'm not an expert in either CF or GDAL, but have used them enough to be able to attest that the support could be improved. Cheers, ~James On Thu, Aug 25, 2011 at 10:26:09AM -0600, Kyle Shannon wrote: > Etienne, > I am all for the improvements. I am a little short on time for the next 2-4 > weeks, but I would like to spend some time on this. I think that the closer > we get to a CF-1.x compliant file the better. That also gives us a little > better specification to work towards. I hope to have some more time soon to > work on this. There does seem to be more interest in the driver and the > file format recently. > > kss > > /** > * > * Kyle Shannon > * ksshan...@gmail.com > * > */ > > > > > On Wed, Aug 24, 2011 at 14:37, Etienne Tourigny wrote: > > > Hi all, > > > > I would like to start a discussion with those interested about fixing > > various issues in the NetCDF driver. > > > > As it stands, it is not fully CF-1.0 compliant, and produces geographical > > grids that are not valid for other software. > > Also, the infamous "up-side down" problem has been addressed for importing > > netcdfs, but needs to be addressed for exporting. > > > > Related ticket: http://trac.osgeo.org/gdal/ticket/2129 > > I have been submitting patches for some time to fix the related issues. > > > > I have identified a number of issues, of which the following have been > > fixed partially in my proposed patch. > > > > 1- conform to the cf-1.0 standard for geographical grids (creating lat and > > lon dimensions and variables) > > 2- make netcdf grids "bottom-up" by default, as all software out there uses > > that convention > > 3- fix problems related to floating-point / string conversions (also > > reported in issue #4200 ) > > 4- fix metadata handling and duplication (as reported in issue #4204), and > > keep band (variable) metadata outside of the global metadata > > > > Pending issues: > > > > 5- how to deal with netcdfs which have no datum? Can we assume WGS84? > > These files are extremely common, and CF-1.0 has provisions for > > identifying the key variables, but no Proj/Wkt codes. > > 6- fix proper export of projected CRS (this is not fully necessary though) > > with lat/lon values respecting CF-1.0 > > 7- handle time axis properly (at least when creating a netcdf) - that would > > be great for import/export of netcdf > > > > Regards, > > Etienne > > > > ___ > > 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 -- James Hiebert Lead, Computational Support Pacific Climate Impacts Consortium http://www.pacificclimate.org Room 113, University House 1, University of Victoria PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2 E-mail: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ogr2ogr, gpx -> PostGIS, preserving fid links
Hi all, I'm trying to use ogr2ogr to load gpx tracks into PostGIS and am having trouble preserving the foreign keys between the "track_points" layer/table and the "tracks" layer/table. My use case is as such: I typically collect gps traces in the field and use gpsbabel to download the traces from one of my gps receivers. Afterwards I want to load them into PostGIS, adding the trace(s) from the last period of time to my archive of gps traces from the past several years. When inserting into PostGIS, I would like to include both the track_points layer (to include all of the point attributes such as time, elevation, hdop/vdop, etc.) and the tracks layer. I would like for each of the track_point rows to include a foreign key to the corresponding track and GDAL's GPX driver seems to support this according to here: http://gis-lab.info/docs/gdal/gdal_ogr_user_docs.html Whenever running ogr2ogr in append mode, however, the track_fid column of the track_points are never translated to account for what is the actual fid of the corresponding track. For example, if there are already 10 tracks in my database, and the track fid sequence is at 10, the new track will be loaded in with fid=10, but the track_points from that track will be loaded in with track_fid=0 (i.e. it points to the track_fid in the new gpx file, not the database). I thought that perhaps the -preserve_fid command line switch would help, but it's essentially useless in -append mode. If you're adding a new set of tracks to the database, there's no point in preserving the fids; all of the fids (0-n) in the new gpx file have all been used up by the existing tracks in the database and I'll just get primary key errors on anything after the first insertion. I think that I'm missing something. For example, I don't really understand why this old ticket http://trac.osgeo.org/gdal/ticket/3637 is marked as invalid. Perhaps it's just that my use case isn't supported by ogr2ogr? (If so, let me know and I'll move on). What's my best solution here? Is there an easy way out that I'm not thinking of/don't know about, or do I have to do some several step process like use ogr2ogr to insert into a temprorary table and then move them into the multi-track archive using a select/insert? Or should I just not use ogr2ogr and write my own program with GDAL which retrieves the track_fid upon writing that layer and then uses it for writing the track_points layer? FWIW I'm using GDAL 1.9.0, PostgreSQL 9.1.3 and PostGIS 1.5.3-r1 all built on Linux. Cheers, ~James ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr, gpx -> PostGIS, preserving fid links
> The ticket #3637 was invalid because there was nothing to fix. The change in
> track_fid values was not unexpected.
Good to know. I guess as a very periphrial GDAL user, I'm still learning what
to expect and what is not core functionality.
> Please let us know how you solved this issue.
It turned out that a pretty simple python script solved my problem (thanks
largely to the "Retrieving FID of newly inserted feature" from here:
http://www.gdal.org/ogr/drv_pg_advanced.html). Without any attempt to optimize
for performance or catch any errors, it can be expressed in a short page
(below) and seems to do the right foreign key mapping; at least for the several
test cases that I tried. We'll see what happens when I go to load years worth
of data :)
Thanks for the feedback.
~James
import ogr
rd = ogr.Open('/path/to/my/file.gpx')
wt = ogr.Open("PG:dbname='spatial' host='my.host' user='me' password='**'")
rlyr = rd.GetLayerByName('tracks')
wlyr = wt.GetLayerByName('tracks')
fid_map = {}
# Copy tracks, saving the database fid
for feat in rlyr:
fFID = feat.GetFID()
feat.SetFID(-1)
rv = wlyr.CreateFeature(feat)
fid_map[fFID] = feat.GetFID()
print "fid map:", fid_map
ptrlyr = rd.GetLayerByName('track_points')
ptwlyr = wt.GetLayerByName('track_points')
# Copy track-points using the database track_fid rather than the file track_fid
for feat in ptrlyr:
feat.SetFID(-1)
feat.SetField('track_fid', fid_map[feat.track_fid])
rv = ptwlyr.CreateFeature(feat)
On Mon, Mar 26, 2012 at 01:33:51PM +0530, Chaitanya kumar CH wrote:
> James,
>
> The ticket #3637 was invalid because there was nothing to fix. The change in
> track_fid values was not unexpected.
>
> Whatever we do, we need to keep track of the foreign keys. That is not a
> trivial case. It is more of a DBMS area. In fact, the solution you specified,
> which is to have a temporary table, was my first idea too.
>
> Please let us know how you solved this issue.
>
> On Mon, Mar 26, 2012 at 10:29 AM, James Hiebert wrote:
>
> Hi all,
>
> I'm trying to use ogr2ogr to load gpx tracks into PostGIS and am having
> trouble preserving the foreign keys between the "track_points" layer/table
> and the "tracks" layer/table.
>
> My use case is as such:
> I typically collect gps traces in the field and use gpsbabel to download
> the traces from one of my gps receivers. Afterwards I want to load them
> into PostGIS, adding the trace(s) from the last period of time to my
> archive of gps traces from the past several years. When inserting into
> PostGIS, I would like to include both the track_points layer (to include
> all of the point attributes such as time, elevation, hdop/vdop, etc.) and
> the tracks layer. I would like for each of the track_point rows to
> include
> a foreign key to the corresponding track and GDAL's GPX driver seems to
> support this according to here: http://gis-lab.info/docs/gdal/
> gdal_ogr_user_docs.html
>
> Whenever running ogr2ogr in append mode, however, the track_fid column of
> the track_points are never translated to account for what is the actual
> fid
> of the corresponding track. For example, if there are already 10 tracks
> in
> my database, and the track fid sequence is at 10, the new track will be
> loaded in with fid=10, but the track_points from that track will be loaded
> in with track_fid=0 (i.e. it points to the track_fid in the new gpx file,
> not the database).
>
> I thought that perhaps the -preserve_fid command line switch would help,
> but it's essentially useless in -append mode. If you're adding a new set
> of tracks to the database, there's no point in preserving the fids; all of
> the fids (0-n) in the new gpx file have all been used up by the existing
> tracks in the database and I'll just get primary key errors on anything
> after the first insertion. I think that I'm missing something. For
> example, I don't really understand why this old ticket http://
> trac.osgeo.org/gdal/ticket/3637 is marked as invalid. Perhaps it's just
> that my use case isn't supported by ogr2ogr? (If so, let me know and I'll
> move on).
>
> What's my best solution here? Is there an easy way out that I'm not
> thinking of/don't know about, or do I have to do some several step process
> like use ogr2ogr to insert into a temprorary table and then move them into
> the multi-track archive using a select/insert? Or should I just not use
>
