Re: [gdal-dev] https://github.com/OSGeo/gdal is the current SCM and ticketing system

[Kyle Shannon]

Even,

On Fri, Mar 23, 2018 at 8:09 AM, Even Rouault
 wrote:
> OK, so now you can and should use https://github.com/OSGeo/gdal to track
> developement and file new tickets/issues
> Trac ticket creation has been disabled. You can still modify existing tickets.
>
> One side effect of pushing the rewritten commit messages is that all still
> opened pull requests (~20) in the previous mirror have been forced closed (not
> surprising since the sha1sum of the base commits have been modified). So if
> you had pending work, please rebase it on top of the current
> https://github.com/OSGeo/gdal and issue a new pull request. Forks of the
> previous https://github.com/OSGeo/gdal will probably have to be recreated from
> scratch, or "rebased" to the current one as well.
>
> The cron job that triggers website refresh has now been updated.
>
> GDAL SVN committers that don't have yet push rights to github, please submit a
> pull request to gdal/COMMITTERS file with a new line with your contact
> information, so your github nickname can be added to the authorized list of
> people with push rights (if you already have push rights, please also update
> COMMITTERS with your info)
>
> I've updated a few things on Trac wiki to point to github. If you still see
> references to svn or Trac for new tickets, you're welcome to fix them.
>
> I've initiated
> https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md
> Needs more love.
>
> Kyle, you'll likely need to update your job for Coverity Scan.

I'll work on enabling the webhook enabled scan and drop the cron job
on my machine when that is up.

>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com



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

Re: [gdal-dev] What is CPL?

[Kyle Shannon]

Hi,

On Mon, Jun 19, 2017 at 6:24 PM, NASAHARA Kenlo <24dake...@gmail.com> wrote:
> Dear GDAL people,
>
> Let me raise a silly question, please.
>
> What is "CPL" which appears around the
> GDAL world, such as "CPLError"?
>
> I tried to figure out but I still cannot.
> For example,
>  Combined Programming Language
>  computer pidgin language
>  Combined Programming Language
> ...
>
> --
> Kenlo Nishida Nasahara
> Faculty of Life and Environmental Sciences
> University of Tsukuba, Japan 305-8572
> 24dake...@gmail.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

If I remember correctly, it stands for Common Portability Library.

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

Re: [gdal-dev] Dropping GeoPackage table doesn't reduce file size

[Kyle Shannon]

Jerome,

On Mon, Oct 31, 2016 at 8:14 AM, jguelat  wrote:
> Thanks for you help! I thought this was done automatically...

It is disabled by default:

https://www.sqlite.org/pragma.html#pragma_auto_vacuum

If you want to enable it through OGR, you can use OGR_SQLITE_PRAGMA:

"""

Starting with OGR 1.11, any SQLite pragma can be specified with the
OGR_SQLITE_PRAGMA configuration option. The syntax is
OGR_SQLITE_PRAGMA =
"pragma_name=pragma_value[,pragma_name2=pragma_value2]*".

"""

from the SQLite driver page:

http://gdal.org/drv_sqlite.html

>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/gdal-dev-Dropping-GeoPackage-table-doesn-t-reduce-file-size-tp5293603p5293618.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] netCDF signed nodata value

[Kyle Shannon]

Simon,

On Mon, Oct 26, 2015 at 5:04 PM, Simon Lyngby Kokkendorff
 wrote:
> Hello list,
>
>Just observed a puzzling behaviour of the netCDF driver. When creating a
> netCDF dataset of Byte type, the netCDF driver seems to interpret the nodata
> value as a signed byte.
>  For example a nodata value assigned with -a_nodata 200, will become -56. Of
> course one can work around this by simply casting the nodata value (as e.g.
> returned by band.GetNoDataValue()) to an unsigned byte.

It appears the driver has a sort of data type mis-match with no data
and the band type.  A work around, if available, is to set FORMAT=NC4
as a creation option.  I am not sure if it is in gdal or the netcdf
library at this point.

>
> A simple example:
>
>>gdalinfo --version
> GDAL 1.11.2, released 2015/02/10
>>gdal_translate -of netCDF -a_nodata 200 something.tif something.nc
>>gdalinfo something.nc
> Driver: netCDF/Network Common Data Format
> Files: something.nc
> Size is 10, 10
> Coordinate System is `'
> Origin = (0.000,10.000)
> Pixel Size = (1.000,-1.000)
> Metadata:
>   Band1#_FillValue=-56
>   Band1#_Unsigned=true
>   Band1#long_name=GDAL Band Number 1
>   Band1#valid_range={0,255}
>   lat#long_name=latitude
>   lat#standard_name=latitude
>   lat#units=degrees_north
>   lon#long_name=longitude
>   lon#standard_name=longitude
>   lon#units=degrees_east
>   NC_GLOBAL#Conventions=CF-1.5
>   NC_GLOBAL#GDAL=GDAL 1.11.2, released 2015/02/10
>   NC_GLOBAL#history=Mon Oct 26 23:58:09 2015: GDAL CreateCopy( something.nc,
> ... )
> Corner Coordinates:
> Upper Left  (   0.000,  10.000)
> Lower Left  (   0.000,   0.000)
> Upper Right (  10.000,  10.000)
> Lower Right (  10.000,   0.000)
> Center  (   5.000,   5.000)
> Band 1 Block=10x1 Type=Byte, ColorInterp=Undefined
>   NoData Value=-56
>   Metadata:
> _FillValue=-56
> _Unsigned=true
> long_name=GDAL Band Number 1
> NETCDF_VARNAME=Band1
> valid_range={0,255}
>
> Cheers,
> Simon Kokkendorff, DMI
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Allocate large memory space with CPLMalloc(). Bug or not?

[Kyle Shannon]

On Thu, Oct 1, 2015 at 1:18 PM, fazotron  wrote:
>
> Hello!
>
> Take a look on the following code:
>
> *...
> size_t w = 1, h = 5000, d = 150;
> size_t sz = w * h * d * sizeof(float); // ~27.94 Gb
>
> float *volume = (float*)CPLMalloc(sz);
> ...*
>
> In this case GDAL throws error in runtime: "ERROR 1: CPLMalloc(-664771072):
> Silly size requested."
> But I think that it's not silly, because such amount of free RAM is
> available on my system. For example I can successfully allocate it calling
> standart malloc().
>
> I have opened CPLMalloc() source code and seen the following lines:
>
> *void *CPLMalloc( size_t nSize )
> ...
> if( long(nSize) < 0 )
> {
> CPLError( CE_Failure, CPLE_AppDefined,
>   "CPLMalloc(%ld): Silly size requested.\n",
>   (long) nSize );
> return NULL;
> }
> ...*
>
> In my case long( size_t nSize ) returns negative value and it leads to
> error.
> As far as I understand converting one integer type to another smaller
> integer type (e.g. long long/size_t to long) is implementation-defined, so
> it's not safe to use CPLMalloc() with 64-bit integers.
>

According to the documentation, CPLMalloc is a convenience for
'smaller' allocations where the caller is 'unwilling to test for out
of memory conditions':

/**
 * Safe version of malloc().
 *
 * This function is like the C library malloc(), but raises a CE_Fatal
 * error with CPLError() if it fails to allocate the desired memory.  It
 * should be used for small memory allocations that are unlikely to fail
 * and for which the application is unwilling to test for out of memory
 * conditions.  It uses VSIMalloc() to get the memory, so any hooking of
 * VSIMalloc() will apply to CPLMalloc() as well.  CPLFree() or VSIFree()
 * can be used free memory allocated by CPLMalloc().
 *
 * @param nSize size (in bytes) of memory block to allocate.
 * @return pointer to newly allocated memory, only NULL if nSize is zero.
 */


Use the VSIMalloc*() family, it is just a wrapper for malloc, but
checks for overflow in VSIMalloc2(), VSIMalloc3().

>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Allocate-large-memory-space-with-CPLMalloc-Bug-or-not-tp5227443.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




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

Re: [gdal-dev] Coverity scan schedule

[Kyle Shannon]

Kurt,

On Fri, Sep 4, 2015 at 10:21 AM, Kurt Schwehr  wrote:
> Hi Kyle and/or the other coverity project admins (Even, Frank, Tamas, &
> Pirmin),
>
> Any chance you could add additional times throughout the week for Coverity
> Scans?  We should be able to get 4 a week (for 500K-1M LOC).  I propose that
> we add Weds, Thurs, Sun.   That would be a big help for my efforts to crush
> as many of our 779 outstanding issues as I can.
>
> Thanks!
> -kurt

I will bump the builds to MWF.  I am working on a travis ci based
submission that is a fork of OSGeo/gdal.  It will have better
coverage.

kss

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

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

[Kyle Shannon]

On Wed, Aug 26, 2015 at 1:55 PM, Even Rouault
 wrote:
> Le mercredi 26 août 2015 21:44:10, Kyle Shannon a écrit :
>> Hi,
>>
>> On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault
>>
>>  wrote:
>> > Hi,
>> >
>> > Summer of code 2015 being finished now, Faza's work now include
>> > librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza
>> > will continue working on some other utilities.
>>
>> Which other utilities are being considered?  Has there been any
>> discussion or thoughts on this?
>
> I think we discussed with Faza about pursuing with gdalbuildvrt. gdaldem would
> probably be interesting too. Anyone interested can contribute to the effort.
>
>>
>> > We'd be happy to hear about your comments, especially on the API. So
>> > speak now please.
>>
>> The API looks good to me.
>>
>> How does documentation work for utilities now?
>
> You mean for the binaries ? Well, it is unchanged. Mainly in
> gdal_utilities.dox, and for some of them (gdalwarp at least), in the .cpp.
>
>> I guess changes should
>> be documented in the *_lib.cpp or *_lib.h and also gdal_utilities.dox,
>> similar to how the utilities closely coupled with certain alg/ APIs
>> (gdalgrid for example).
>>
>> > The overview of the work is there:
>> > https://trac.osgeo.org/gdal/wiki/rfc59_utilities_as_a_library
>>
>> If I am reading correctly, a separate lib will now be created.  Is
>> this to keep the building cleaner? Is there a problem with just adding
>> it to the libgdal C API?
>
> The idea was to be a bit more modular, and avoid growing the core library.
>
>>
>> > I'd like to call for a vote soon as I'd want that to be merged as soon as
>> > possible, so it gets more widely tested and to avoid increasing merge
>> > difficulties.
>> >
>> > Even
>> >
>> > --
>> > Spatialys - Geospatial professional services
>> > http://www.spatialys.com
>> > ___
>> > gdal-dev mailing list
>> > gdal-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> Thanks.
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com

Thanks Even...

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

Re: [gdal-dev] Call for discussion on RFC 59 (v2): GDAL/OGR utilities as a library

[Kyle Shannon]

Hi,

On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault
 wrote:
> Hi,
>
> Summer of code 2015 being finished now, Faza's work now include 
> librarification
> of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza will continue working
> on some other utilities.

Which other utilities are being considered?  Has there been any
discussion or thoughts on this?

>
> We'd be happy to hear about your comments, especially on the API. So speak now
> please.

The API looks good to me.

How does documentation work for utilities now?  I guess changes should
be documented in the *_lib.cpp or *_lib.h and also gdal_utilities.dox,
similar to how the utilities closely coupled with certain alg/ APIs
(gdalgrid for example).

>
> The overview of the work is there:
> https://trac.osgeo.org/gdal/wiki/rfc59_utilities_as_a_library

If I am reading correctly, a separate lib will now be created.  Is
this to keep the building cleaner? Is there a problem with just adding
it to the libgdal C API?

>
> I'd like to call for a vote soon as I'd want that to be merged as soon as
> possible, so it gets more widely tested and to avoid increasing merge
> difficulties.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Thanks.

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

Re: [gdal-dev] vector VRT: Warning 1: Line 2: Attribute value should be single or double quoted.

[Kyle Shannon]

Helmut,


On Wed, Aug 26, 2015 at 12:16 PM, Helmut Kudrnovsky  wrote:
> hi,
>
> I have a vector VRT which refers to a CSV.
>
> both files are attached to the mail:
>
> chondrilla.vrt
> 
> chondrilla.csv
> 
>
> when I do ogrinfo on the VRT, I get following warning:
>
>>ogrinfo chondrilla.vrt
>>Warning 1: Line 2: Attribute value should be single or double quoted. Going
> on,
>>but this is invalid XML that might be rejected in future versions.
>>INFO: Open of `chondrilla.vrt'
>>  using driver `VRT' successful.
>>1: chondrilla (Point)
>
> a look into the CSV file:
>
> "gbifid","datasetkey","occurrenceid",...
> "895176382","834a4794-f762-11e1-a439-00145eb45e9a","",...
> ...
>
> any idea what should be changed in the VRT or in CSV, as the attribute
> values are quoted?

Quote the '1' in relativeToVRT:

chondrilla.csv

>
> thanks
>
>
>
>
>
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/vector-VRT-Warning-1-Line-2-Attribute-value-should-be-single-or-double-quoted-tp5221290.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Fedora 20, fatal error: gdal/ogrsf_frmts.h: No such file or directory

[Kyle Shannon]

mario,

On Wed, Aug 19, 2015 at 1:51 PM, mario60  wrote:
> Hi my first post. I am trying to install mysql-workbench from source on a 32
> bit Fedora 22 machine. I get the following error msg:
>
> In file included from
> /root/rpmbuild/BUILD/mysql-workbench-community-6.3.4-src/backend/wbpublic/grt/spatial_handler.cpp:20:0:
> /root/rpmbuild/BUILD/mysql-workbench-community-6.3.4-src/backend/wbpublic/grt/spatial_handler.h:23:30:
> fatal error: gdal/ogrsf_frmts.h: No such file or directory compilation
> terminated.
>
> Google does not help, and I am not sure what to look for.
> Could you help somehow?
> I appreciate
> mario
> 
>
> [root@localhost bin]# locate gdal
> /usr/bin/gdal_contour
> /usr/bin/gdal_grid
> /usr/bin/gdal_rasterize
> /usr/bin/gdal_translate
> /usr/bin/gdaladdo
> /usr/bin/gdalbuildvrt
> /usr/bin/gdaldem
> /usr/bin/gdalenhance
> /usr/bin/gdalinfo
> /usr/bin/gdallocationinfo
> /usr/bin/gdalmanage
> /usr/bin/gdalserver
> /usr/bin/gdalsrsinfo
> /usr/bin/gdaltindex
> /usr/bin/gdaltransform
> /usr/bin/gdalwarp
> /usr/lib/gdalplugins
> /usr/lib/libgdal.so.1
> /usr/lib/libgdal.so.1.18.2
> /usr/lib/ogdi/libgdal.so
> /usr/share/gdal
> /usr/share/aclocal/ax_lib_gdal.m4
> /usr/share/doc/gdal-libs
> /usr/share/doc/gdal-libs/COMMITERS
> /usr/share/doc/gdal-libs/LICENSE.TXT
> /usr/share/doc/gdal-libs/NEWS
> /usr/share/doc/gdal-libs/PROVENANCE.TXT
> /usr/share/doc/gdal-libs/PROVENANCE.TXT-fedora
> /usr/share/gdal/GDALLogoBW.svg
> /usr/share/gdal/GDALLogoColor.svg
> /usr/share/gdal/GDALLogoGS.svg
> /usr/share/gdal/compdcs.csv
> /usr/share/gdal/coordinate_axis.csv
> /usr/share/gdal/datum_shift.csv
> /usr/share/gdal/ellipsoid.csv
> /usr/share/gdal/epsg.wkt
> /usr/share/gdal/gcs.csv
> /usr/share/gdal/gcs.override.csv
> /usr/share/gdal/gdal_datum.csv
> /usr/share/gdal/gdalicon.png
> /usr/share/gdal/geoccs.csv
> /usr/share/gdal/gml_registry.xml
> /usr/share/gdal/gt_datum.csv
> /usr/share/gdal/gt_ellips.csv
> /usr/share/gdal/header.dxf
> /usr/share/gdal/inspire_cp_BasicPropertyUnit.gfs
> /usr/share/gdal/inspire_cp_CadastralBoundary.gfs
> /usr/share/gdal/inspire_cp_CadastralParcel.gfs
> /usr/share/gdal/inspire_cp_CadastralZoning.gfs
> /usr/share/gdal/nitf_spec.xml
> /usr/share/gdal/nitf_spec.xsd
> /usr/share/gdal/ogrvrt.xsd
> /usr/share/gdal/osmconf.ini
> /usr/share/gdal/ozi_datum.csv
> /usr/share/gdal/ozi_ellips.csv
> /usr/share/gdal/pci_datum.txt
> /usr/share/gdal/pci_ellips.txt
> /usr/share/gdal/pcs.csv
> /usr/share/gdal/pcs.override.csv
> /usr/share/gdal/prime_meridian.csv
> /usr/share/gdal/projop_wparm.csv
> /usr/share/gdal/ruian_vf_ob_v1.gfs
> /usr/share/gdal/ruian_vf_st_uvoh_v1.gfs
> /usr/share/gdal/ruian_vf_st_v1.gfs
> /usr/share/gdal/ruian_vf_v1.gfs
> /usr/share/gdal/s57agencies.csv
> /usr/share/gdal/s57attributes.csv
> /usr/share/gdal/s57attributes_aml.csv
> /usr/share/gdal/s57attributes_iw.csv
> /usr/share/gdal/s57expectedinput.csv
> /usr/share/gdal/s57objectclasses.csv
> /usr/share/gdal/s57objectclasses_aml.csv
> /usr/share/gdal/s57objectclasses_iw.csv
> /usr/share/gdal/seed_2d.dgn
> /usr/share/gdal/seed_3d.dgn
> /usr/share/gdal/stateplane.csv
> /usr/share/gdal/trailer.dxf
> /usr/share/gdal/unit_of_measure.csv
> /usr/share/gdal/vertcs.csv
> /usr/share/gdal/vertcs.override.csv
> /usr/share/man/man1/gdal_calc.1.gz
> /usr/share/man/man1/gdal_contour.1.gz
> /usr/share/man/man1/gdal_edit.1.gz
> /usr/share/man/man1/gdal_grid.1.gz
> /usr/share/man/man1/gdal_polygonize.1.gz
> /usr/share/man/man1/gdal_proximity.1.gz
> /usr/share/man/man1/gdal_rasterize.1.gz
> /usr/share/man/man1/gdal_translate.1.gz
> /usr/share/man/man1/gdal_utilities.1.gz
> /usr/share/man/man1/gdaladdo.1.gz
> /usr/share/man/man1/gdalbuildvrt.1.gz
> /usr/share/man/man1/gdalcompare.1.gz
> /usr/share/man/man1/gdaldem.1.gz
> /usr/share/man/man1/gdalinfo.1.gz
> /usr/share/man/man1/gdallocationinfo.1.gz
> /usr/share/man/man1/gdalmanage.1.gz
> /usr/share/man/man1/gdalmove.1.gz
> /usr/share/man/man1/gdalsrsinfo.1.gz
> /usr/share/man/man1/gdaltindex.1.gz
> /usr/share/man/man1/gdaltransform.1.gz
> /usr/share/man/man1/gdalwarp.1.gz
>
>
> 
> View this message in context: Fedora 20, fatal error: gdal/ogrsf_frmts.h: No
> such file or directory
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

You need the include files for gdal, I am not on a fedora machine, but
something like:

yum install gdal-devel

Will get the files needed to compile against.

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

Re: [gdal-dev] Increase width and change offset of the shape file rasterized

[Kyle Shannon]

Gane,

Something similar came up on irc yesterday.  I've recently checked in
a commit that allows the -dialect option in gdal_rasterize.  I don't
think it solves you problem completely, but may help.  Excuse the
verbosity, but a quick example of how to increase your width using the
sqlite dialect and ST_Buffer() on a linestring:

kyle@kyle-bsu-workstation:~/Desktop/tmp$ cat in.csv
WKT,value
"LINESTRING (0 0, 5 5, 10 0, 10 10)",1

kyle@kyle-bsu-workstation:~/Desktop/tmp$ gdal_rasterize -burn 1 -init
0 in.csv -tr 1 1 nobuff.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

kyle@kyle-bsu-workstation:~/Desktop/tmp$ gdal_translate -of aaigrid
nobuff.tif nobuff.asc
Input file size is 10, 10
0...10...20...30...40...50...60...70...80...90...100 - done.

kyle@kyle-bsu-workstation:~/Desktop/tmp$ cat nobuff.asc
ncols10
nrows10
xllcorner0.
yllcorner0.
cellsize 1.
 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 1 0 0 0 0
 0 0 0 0 1 0 1 0 0 0
 0 0 0 1 0 0 0 1 0 0
 0 0 1 0 0 0 0 0 1 0
 0 1 0 0 0 0 0 0 0 1

kyle@kyle-bsu-workstation:~/Desktop/tmp$ gdal_rasterize -burn 1 -init
0 -sql "SELECT ST_Buffer(GEOMETRY, 2) FROM 'in'" -dialect sqlite
in.csv -tr 1 1 buff.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

kyle@kyle-bsu-workstation:~/Desktop/tmp$ gdal_translate -of aaigrid
buff.tif buff.asc
Input file size is 14, 14
0...10...20...30...40...50...60...70...80...90...100 - done.

kyle@kyle-bsu-workstation:~/Desktop/tmp$ cat buff.asc
ncols14
nrows14
xllcorner-2.
yllcorner-2.
cellsize 1.
 0 0 0 0 0 0 0 0 0 0 0 1 1 0
 0 0 0 0 0 0 0 0 0 0 1 1 1 1
 0 0 0 0 0 0 0 0 0 0 1 1 1 1
 0 0 0 0 0 0 0 0 0 0 1 1 1 1
 0 0 0 0 0 0 0 0 0 0 1 1 1 1
 0 0 0 0 0 0 1 1 0 0 1 1 1 1
 0 0 0 0 0 1 1 1 1 0 1 1 1 1
 0 0 0 0 1 1 1 1 1 1 1 1 1 1
 0 0 0 1 1 1 1 1 1 1 1 1 1 1
 0 0 1 1 1 1 1 1 1 1 1 1 1 1
 0 1 1 1 1 1 0 0 1 1 1 1 1 1
 1 1 1 1 1 0 0 0 0 1 1 1 1 1
 1 1 1 1 0 0 0 0 0 0 1 1 1 1
 0 1 1 0 0 0 0 0 0 0 0 1 1 0

On Fri, Jul 3, 2015 at 6:18 AM, Gane R  wrote:
> Questions: 1. How can I change the width of the vector (shapefile) and
> change the offset.
>
> I see GDALdllImageLine calling - pfnPointFunc - calling gvBurnPoint
>
> Questions: 2.  gdalrasterize generate transparent png of the raster
>
> i know the png driver doesn't support create but create copy.
>
> How about the buffer written to MEM driver and then to PNG driver. But I
> want it to transparent and not black ?
>
> Thanks for your previous replies.
>
> Gane
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Spatial Resolution from img file

[Kyle Shannon]

On Thu, Jul 30, 2015 at 5:03 AM, user gdal  wrote:
> Dear friends,
> I have a geo ref. ERDAS img file. How to obtain its spatial resolution
> programmatically (C++)?
>
> One suggestion I received was to refer to gdalinfo.c However I couldn't get
> the required information in gdalinfo.c. I also felt it to be unclear. What I
> have seen in gdalinfo is how to get columns, rows etc. (for which we needn't
> visit the gdalinfo program).

It's in there, the program prints out:

...
Pixel Sizes = (dx,-dy)
...

So it has to have the code.

>
> I expected something like GetXResolution(..) and GetYResolution(...) kind of
> situation. But...

The information you are looking for is contained in the geotranform
matrix available through

GDALGetGeoTransform(GDALDatasetH, double*);

See the api tutorial for more information:

http://gdal.org/gdal_tutorial.html

>
> Any help, please!
>
> With thanks,
>
> Yours sincerely,
>
> B. Ramesh
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] gdalwarp add the stats to a raster

[Kyle Shannon]

Andrea,

On Tue, Jul 28, 2015 at 10:51 PM, Andrea Peri  wrote:
> Hi,
> I see the gdalwarp has no the parameter (-stats) as gdal_translate to
> force the add of statistics.
>
> But I dont understand if gdalwarp will add however the stats to a raster or 
> not.

gdalwarp does not, but

gdalinfo -stats warped.tif

will recompute the stats for you.
>
> Thx.
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

kss

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

Re: [gdal-dev] New OGR driver for DB2 Spatial support

[Kyle Shannon]

Patch is a diff of the source tree:

https://en.wikipedia.org/wiki/Patch_%28Unix%29

Yours will mostly be new files, but a few will change.

Easiest way to to do that is with svn checkout the trunk, make your
changes, svn add them, then do svn diff > db2.patch.  That makes it
easier for the gdal devs to test.

On Fri, Jun 12, 2015 at 1:21 PM, David Adler
 wrote:
> Kyle, thank you for the quick response.
>
> I'll take a look at the autotest suite and test_ogrsf.
>
> By "patch", do you mean a zip file of the new and changed files?
>
>
> On 6/12/2015 1:43 PM, Kyle Shannon wrote:
>>
>> David
>>
>> On Fri, Jun 12, 2015 at 11:33 AM, David Adler
>>  wrote:
>>>
>>> I have mostly completed the driver for DB2 Spatial using the ODBC support
>>> and would appreciate pointers into the GDAL information for the
>>> following:
>>>
>>> 1. Is there a test suite / framework for OGR drivers?
>>
>> Yes, you can download the autotest suite here (for 1.11.2):
>>
>> http://download.osgeo.org/gdal/1.11.2/
>>
>> there is also test_ogrsf in apps/
>>
>> cd apps
>> make test_ogrsf
>> ./test_ogrsf --help
>> Usage: test_ogrsf [-ro] [-q] [-threads N] [-loops M] [-fsf]
>>(datasource_name | [-driver driver_name] [[-dsco
>> NAME=VALUE] ...] [[-lco NAME=VALUE] ...] | -all_drivers)
>>[[layer1_name, layer2_name, ...] | [-sql statement]
>> [-dialect dialect]]
>> [[-oo NAME=VALUE] ...]
>>
>> -fsf : full spatial filter testing (slow)
>>
>>> 2. What is the mechanism for submitting a new driver?
>>
>> Submit a ticket on the trac instance at:
>>
>> https://trac.osgeo.org/gdal/newticket
>>
>> attach the patch for the gdal trunk, and the new unit tests as a patch
>> in autotest.
>>
>>> 3. What is the plan for the transition to GDAL 2.0?  My driver was
>>> developed
>>> against GDAL 1.11.2 and parallels similar drivers for MSSQL, PostGIS,
>>> Oracle, etc.
>>
>> Current trunk is 2.0, with a release candidate out.  You may have to
>> do a little work to update the driver.
>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>



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

Re: [gdal-dev] New OGR driver for DB2 Spatial support

[Kyle Shannon]

David

On Fri, Jun 12, 2015 at 11:33 AM, David Adler
 wrote:
> I have mostly completed the driver for DB2 Spatial using the ODBC support
> and would appreciate pointers into the GDAL information for the following:
>
> 1. Is there a test suite / framework for OGR drivers?

Yes, you can download the autotest suite here (for 1.11.2):

http://download.osgeo.org/gdal/1.11.2/

there is also test_ogrsf in apps/

cd apps
make test_ogrsf
./test_ogrsf --help
Usage: test_ogrsf [-ro] [-q] [-threads N] [-loops M] [-fsf]
  (datasource_name | [-driver driver_name] [[-dsco
NAME=VALUE] ...] [[-lco NAME=VALUE] ...] | -all_drivers)
  [[layer1_name, layer2_name, ...] | [-sql statement]
[-dialect dialect]]
   [[-oo NAME=VALUE] ...]

-fsf : full spatial filter testing (slow)

> 2. What is the mechanism for submitting a new driver?

Submit a ticket on the trac instance at:

https://trac.osgeo.org/gdal/newticket

attach the patch for the gdal trunk, and the new unit tests as a patch
in autotest.

> 3. What is the plan for the transition to GDAL 2.0?  My driver was developed
> against GDAL 1.11.2 and parallels similar drivers for MSSQL, PostGIS,
> Oracle, etc.

Current trunk is 2.0, with a release candidate out.  You may have to
do a little work to update the driver.

>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Proj4 Transformation Error 6

[Kyle Shannon]

Jay,


On Fri, Jun 12, 2015 at 11:21 AM, Kyle Shannon  wrote:
> Jay,
>
>
> On Fri, Jun 12, 2015 at 10:59 AM, Jay L.  wrote:
>> Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
>>
>> I have a WKT projection:
>> 'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",180.0],PARAMETER["Standard_Parallel_1",0.0],UNIT["Meter",1.0]]'
>>
>> I import this into a srs object and attempt to export to Proj4.  This is
>> throwing:
>>
>> RuntimeError: No translation for Mercator to PROJ.4 format is known.
>
> OGRSpatialReference needs a specific Mercator projection such as:
> Mercator_1SP, Mercator_2SP, etc.  Use Mercator_1SP in your case for
> the PROJECTION parameter.
>
>>
>> Along the same lines, I am trying to compute pixel to latlon and the
>> inverse.  So I need a transformation object.  No problem setting that up
>> until:
>>
>> RuntimeError: Failed to initialize PROJ.4 with `+proj=merc +lon_0=0 +k=0
>> +x_0=0 +y_0=0 +a=3396190 +b=3376200 +units=m +no_defs '.
>>
>> Which leads me to try:
>>
>> gdalsrsinfo -V '+proj=merc +lon_0=0 +k=0 +x_0=0 +y_0=0 +a=3396190 +b=3376200
>> +units=m +no_defs'
>>
>> Validate Succeeds
>>
>> PROJ.4 : '+proj=merc +lon_0=0 +k=0 +x_0=0 +y_0=0 +a=3396190 +b=3376200
>> +units=m +no_defs '
>>
>> OGC WKT :
>> PROJCS["unnamed",
>> GEOGCS["unnamed ellipse",
>> DATUM["unknown",
>> SPHEROID["unnamed",3396190,169.894447223611]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433]],
>> PROJECTION["Mercator_1SP"],
>> PARAMETER["central_meridian",0],
>> PARAMETER["scale_factor",0],
>> PARAMETER["false_easting",0],
>> PARAMETER["false_northing",0],
>> UNIT["Meter",1]]
>>
>> So gdalsrsinfo is able to validate the proj4 string.
>
> gdalsrsinfo can't validate the WKT though, without the Mercator_1SP
>
>>
>> Any ideas?
>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> Kyle

Mercator is a valid key in the ESRI WKT dialect:

Type "copyright", "credits" or "license()" for more information.
>>> from osgeo import osr
>>> wkt = 
>>> 'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",180.0],PARAMETER["Standard_Parallel_1",0.0],UNIT["Meter",1.0]]'
>>> srs1 = osr.SpatialReference()
>>> srs1.ImportFromWkt(wkt)
0
>>> srs1.ExportToProj4()
''
>>> srs1.MorphFromESRI()
0
>>> srs1.ExportToProj4()
'+proj=merc +lon_0=180 +k=1 +x_0=0 +y_0=0 +a=1737400 +b=1737400
+units=m +no_defs '

The osr.SpatialReference.MorphFromESRI() should do the job too.

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

Re: [gdal-dev] Proj4 Transformation Error 6

[Kyle Shannon]

Jay,


On Fri, Jun 12, 2015 at 10:59 AM, Jay L.  wrote:
> Using GDAL 1.11.2 (Anaconda Python osgeo binstar install).
>
> I have a WKT projection:
> 'PROJCS["Mercator",GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",180.0],PARAMETER["Standard_Parallel_1",0.0],UNIT["Meter",1.0]]'
>
> I import this into a srs object and attempt to export to Proj4.  This is
> throwing:
>
> RuntimeError: No translation for Mercator to PROJ.4 format is known.

OGRSpatialReference needs a specific Mercator projection such as:
Mercator_1SP, Mercator_2SP, etc.  Use Mercator_1SP in your case for
the PROJECTION parameter.

>
> Along the same lines, I am trying to compute pixel to latlon and the
> inverse.  So I need a transformation object.  No problem setting that up
> until:
>
> RuntimeError: Failed to initialize PROJ.4 with `+proj=merc +lon_0=0 +k=0
> +x_0=0 +y_0=0 +a=3396190 +b=3376200 +units=m +no_defs '.
>
> Which leads me to try:
>
> gdalsrsinfo -V '+proj=merc +lon_0=0 +k=0 +x_0=0 +y_0=0 +a=3396190 +b=3376200
> +units=m +no_defs'
>
> Validate Succeeds
>
> PROJ.4 : '+proj=merc +lon_0=0 +k=0 +x_0=0 +y_0=0 +a=3396190 +b=3376200
> +units=m +no_defs '
>
> OGC WKT :
> PROJCS["unnamed",
> GEOGCS["unnamed ellipse",
> DATUM["unknown",
> SPHEROID["unnamed",3396190,169.894447223611]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433]],
> PROJECTION["Mercator_1SP"],
> PARAMETER["central_meridian",0],
> PARAMETER["scale_factor",0],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],
> UNIT["Meter",1]]
>
> So gdalsrsinfo is able to validate the proj4 string.

gdalsrsinfo can't validate the WKT though, without the Mercator_1SP

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



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

Re: [gdal-dev] Querying Geographic Coordinate System from an existing image file.

[Kyle Shannon]

Jim,

On Mon, Jun 8, 2015 at 10:11 AM, Tilton, James C. (GSFC-6063)
 wrote:
> I seem to be missing some key point in understanding the use of OGR
> Projections.
>
>
>
> The OGR Projections Tutorial (www.gdal.org/osr_tutorial.html) very clearly
> describes how to set up a new OGRSpatialReference,
>
> but does not tell how to determine and query the OGRSpatialReference from an
> existing image data set (e.g. and GeoTiff image).
>
>
>
> Could someone please point me to examples/instructions on how to do this?

See gdalsrsinfo:

http://www.gdal.org/gdalsrsinfo.html

and the source:

https://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdalsrsinfo.cpp

For a geotiff, it'd be something like:

GDALDatasetH hDS = GDALOpen("mytiff.tif", GA_ReadOnly);
const char *pszWkt = GDALGetProjectionRef(hDS);
OGRSpatialReferenceH hSRS;
hSRS = OSRNewSpatialReference(pszWkt);

using the C API (and not doing error checking, obviously).

>
>
>
> Thanks.
>
>
>
> Jim Tilton
>
> 
>
> Dr. James C. Tilton   Voice:
> 301-286-9510
>
> NASA Goddard Space Flight Center   FAX: 301-286-1776
>
> Mail Code 606.3E-Mail:
> james.c.til...@nasa.gov
>
> (Computational & Information Sciences and Technology Office)
>
> Greenbelt, MD 20771
>
> URLs:
> http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=home.main&&navOrgCode=606
>
> and . http://geography.wr.usgs.gov/science/croplands/index.html
>
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] RGB to Grayscale

[Kyle Shannon]

Tomer,

On 04/16/2015 03:03 PM, Tomer wrote:

Hello,

I want to change a rgb image to a grayscale image.
Is there a way to make it through the gdal_translate.exe utility or through
other utilities.

Best regards,
Tomer.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/RGB-to-Grayscale-tp5201726.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



Have you seen/tried rgb2pct.py:

http://gdal.org/rgb2pct.html

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

Re: [gdal-dev] Setting up C++ environment with GDAL on CentOS

[Kyle Shannon]

Joshua,

On 04/15/2015 12:58 PM, Dr. Joshua Jackson wrote:

Hey GDAL Team - I have a server running CentOS 6.  I have downloaded the
complete 1.11.2 source and successfully built and installed GDAL.

I am now trying to make my C++ program which uses GDAL and I’m not
having any luck.  I get an “unknown reference” error on all my calls to
GDAL methods. (GDALAllRegister, GDALOpen, etc).

On my #include I get an error if I use #include “gdal/gdal_priv.h”; but
it makes it past that point if I use #include “gdal_priv.h” alone.


#include "gdal_priv.h" is the proper syntax.  If you use a pre-built 
package from ubuntu or fedora or other package maintainer, they 
sometimes install the headers in a folder named gdal.  The standard 
build does not.




I am using cmake with this project and here is my CMakeLists.txt below.
  I have manually set GDAL_INCLUDE_DIRS to be /usr/local/lib which is
where all the libgdal*.so files are located.


I believe the proper name is GDAL_INCLUDE_DIR and it needs to point to 
the headers so it should be /usr/local/include (assuming a standard 
installation, see above).




cmake_minimum_required(VERSION 2.8)
project( AerialMask )
find_package( OpenCV )
find_package( GDAL )
include_directories(
${OpenCV_INCLUDE_DIRS}
${GDAL_INCLUDE_DIRS}
)
add_executable( AerialMask AerialMask.cpp )
target_link_libraries( AerialMask ${OpenCV_LIBS} )


You need to link to libgdal, so:

target_link_libraries( AerialMask ${OpenCV_LIBS} ${GDAL_LIBRARY} )





Joshua Jackson, PhD

Senior ResearchEngineer

(800) 604-1822 Ext. 5109 (256) 648-5109


j...@nside.io www.nSide.io 

4031 Parkway Dr, Suite B, Florence, AL 35630






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



kss

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

Re: [gdal-dev] Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'

[Kyle Shannon]

Brendan,

On 02/10/2015 11:13 AM, DeTracey, Brendan wrote:

The should be on the path. (Very strange that the Anaconda installer dumped a 
copy in its root directory.)

C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda>echo %PATH%
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
 Files\MATLAB\R2012a\bin;C:\Program Files 
(x86)\MATLAB\R2010bSP1\bin;C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda;C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda\Scripts;

C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda>dir proj.*
  Volume in drive C is OSDisk
  Volume Serial Number is 7A59-3F7E

  Directory of C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda

06/02/2015  07:45 AM   369,152 proj.dll
06/02/2015  07:45 AM19,456 proj.exe
2 File(s)388,608 bytes
0 Dir(s)  76,317,147,136 bytes free

C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda>proj.exe
Rel. 4.8.0, 6 March 2012
usage: proj.exe [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]

I also tried adding to the script :
gdal.SetConfigOption('PROJSO', 
'C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda\proj.dll')

This also did not work.



-Original Message-
From: Even Rouault [mailto:even.roua...@spatialys.com]
Sent: February-10-15 11:55 AM
To: gdal-dev@lists.osgeo.org
Cc: DeTracey, Brendan
Subject: Re: [gdal-dev] Wrong number or type of arguments for overloaded
function 'CoordinateTransformation_TransformPoint'

Le mardi 10 février 2015 16:27:54, DeTracey, Brendan a écrit :

Hi,

I am using the GDAL python bindings via Windows 64 bit Anaconda, but I
am getting an error when I try to run one of the GDAL sample scripts,
tolatlong.py e.g.

E:\parse_cis>python tolatlong.py 0 0 temp.tif Traceback (most recent
call last):
   File "tolatlong.py", line 106, in 
 (int, lat, height) = ct.TransformPoint(X, Y)
   File
"C:\Users\DeTraceyB\AppData\Local\Continuum\Anaconda\lib\site-packages
\osg eo\osr.py", line 757, in TransformPoint return
_osr.CoordinateTransformation_TransformPoint(self, *args)
NotImplementedError: Wrong number or type of arguments for overloaded
function 'CoordinateTransformation_TransformPoint'. Possible C/C++
prototypes are:
 OSRCoordinateTransformationShadow::TransformPoint(double [3])
 OSRCoordinateTransformationShadow::TransformPoint(double
[3],double,double,double)

When I google this error I find it might be related to GDAL not
finding Proj (https://github.com/avalentino/gsdview/issues/89). Could
someone please verify that this would be the source of this error? I
have installed Proj under Anaconda and am trying to rule out whether
it is a problem with Anaconda or GDAL.


Yes, it seems very likely this is due to proj missing. Check that proj.dll is
available in one of the paths in the PATH.



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


--
Spatialys - Geospatial professional services http://www.spatialys.com

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



Is GDAL_DATA set?  I seem to remember that error if it was missing. 
Just a guess though...


kss

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

Re: [gdal-dev] Parse GML without geometry

[Kyle Shannon]

Steve,

On Fri, Dec 12, 2014 at 12:35 PM,   wrote:
> Hi,
> I need to parse the GML returned by this query, to make a list of unique
> value of NA2DESC tag using python
> http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&REQUEST=GetFeature&version=1.1.0&Typename=continents&maxfeatures=10&propertyname=(NA2DESC)
>
> I could not make it with a XML parser yet. I consider using ogr API but can
> I use it even if there is no geometry?

This one has a geometry, or so ogr thinks so:

kyle@kyle-workstation:~$ ogrinfo -so -al -ro
"/vsicurl_streaming/http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&REQUEST=GetFeature&version=1.1.0&Typename=continents&maxfeatures=10&propertyname=(NA2DESC)"
INFO: Open of 
`/vsicurl_streaming/http://demo.mapserver.org/cgi-bin/wfs?SERVICE=WFS&REQUEST=GetFeature&version=1.1.0&Typename=continents&maxfeatures=10&propertyname=(NA2DESC)'
  using driver `GML' successful.

Layer name: continents
Geometry: Unknown (any)
Feature Count: 10
Extent: (-90.00, -180.00) - (83.627419, 180.00)
Layer SRS WKT:
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.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]
Geometry Column = msGeometry
gml_id: String (0.0)
NA2DESC: String (0.0)
NA3DESC: String (0.0)

>
> If ogr api is a good option, any link to examples or tutorial would be
> appreciated since I never used the API.

API tutorials:

For gdal 2.x:

http://gdal.org/ogr_apitut.html

For gdal 1.x (the vector side is ogr):

http://gdal.org/1.11/ogr/ogr_apitut.html

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

kss

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

Re: [gdal-dev] QGIS crashes in ogrsqlitevirtualogr.cpp::OGR2SQLITE_Register

[Kyle Shannon]

Sandro,

On Thu, Dec 4, 2014 at 2:50 PM, Sandro Mani  wrote:
> Hi,
>
> QGIS is currently crashing in Fedora 21+ when listing the supported ogr
> drivers. In QgsVectorFileWriter::ogrDriverList, there is a portion of code
>
> // Unfortunately it seems that there is no simple way to detect if
> // OGR SQLite driver is compiled with SpatiaLite support.
> // We have HAVE_SPATIALITE in QGIS, but that may differ from OGR
> // http://lists.osgeo.org/pipermail/gdal-dev/2012-November/034580.html
> // -> test if creation failes
> [...]
> OGRDataSourceH ds = OGR_Dr_CreateDataSource( poDriver, TO8F( QString(
> "/vsimem/spatialitetest.sqlite" ) ), options );
>
> which then (see stack trace below) ends up calling OGR2SQLITE_Register,
> which itself calls sqlite3_auto_extension which is a macro defined as
> sqlite3_api->auto_extension. This last call crashes because sqlite3_api is
> null.
>
> Reading the code it looks like the only way for sqlite3_api to be
> initialized is via ogrsqlitevirtualogr.cpp::sqlite3_extension_init, which is
> supposedly called when loading the extension via SQLite. I don't see
> sqlite3_extension_init being called otherwise, so I wonder whether this is a
> bug in ogr, or whether QGIS is doing something it shouldn't.
>
> The backtrace is:
>
> (gdb) bt
> #0  0x74ad36ce in OGR2SQLITE_Register() () at
> ogrsqlitevirtualogr.cpp:2460
> #1  0x74ab0148 in OGRSQLiteDataSource::OpenOrCreateDB(int)
> (this=this@entry=0x4278780, flags=flags@entry=6) at
> ogrsqlitedatasource.cpp:455
> #2  0x74ab473e in OGRSQLiteDataSource::Create(char const*, char**)
> (this=this@entry=0x4278780, pszNameIn=pszNameIn@entry=0x42786d8
> "/vsimem/spatialitetest.sqlite", papszOptions=papszOptions@entry=0x1e695d0)
> at ogrsqlitedatasource.cpp:610
> #3  0x74ab8666 in OGRSQLiteDriver::CreateDataSource(char const*,
> char**) (this=, pszName=0x42786d8
> "/vsimem/spatialitetest.sqlite", papszOptions=0x1e695d0)
> at ogrsqlitedriver.cpp:203
> #4  0x74aa5f82 in OGR_Dr_CreateDataSource(OGRSFDriverH, char const*,
> char**) (hDriver=0x11f4b80, pszName=, papszOptions= out>) at ogrsfdriver.cpp:74
> #5  0x73d2477e in QgsVectorFileWriter::ogrDriverList() () at
> /usr/src/debug/qgis-2.6.0/src/core/qgsvectorfilewriter.cpp:2127
>
> (gdb) frame 0
> #0  0x74ad36ce in OGR2SQLITE_Register () at
> ogrsqlitevirtualogr.cpp:2460
> 2460sqlite3_auto_extension ((void (*)(void))
> OGR2SQLITE_static_register);
>
> (gdb) print sqlite3_api
> $1 = (const sqlite3_api_routines *) 0x0
>
>
> Thanks for any inputs.
>
> Best,
> Sandro
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

It looks like this may be the issue:
http://trac.osgeo.org/gdal/ticket/5725, and a fix has been committed.
I think this has to do with more recent versions of sqlite.  What
version are you using?

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

Re: [gdal-dev] Trying to write a gridded XYZ from an cloud of points...

[Kyle Shannon]

Wong,

On Fri, Nov 21, 2014 at 12:33 PM, Wong Hua  wrote:
> Hello, I am a osgeo4w user and very green in the field of geo data.
>
> I am using gdal_grid to grid and ungridded set of points (a CSV file).
>
> I ultimately want to use it with gdaltransform to change the projection type
> and gdaltransform does not work with ungridded files from my understanding.
>
> The problem I have is that when I use gdal_grid, I get :
> ERROR 6: GDALDriver::Create() ... no create method implemented for this
> format
> Unable to create target dataset "newgrid".
> GDALDriver::Create() ... no create method implemented for this format
>
> Here is the command line :
> gdal_grid -zfield field_3 -of xyz -l grid grid.vrt newgrid
>
> Is there anything I have to install to be able to write gridded XYZ files?
>
> Thanks for any help.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

The gdalgrid utility needs to write to a format that supports Create().  Try:

gdal_grid -zfield field_3 -of gtiff -l grid grid.vrt newgrid.tif
gdal_translate -of xyz newgrid.tif newgrid.xyz

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

Re: [gdal-dev] handle GRIB files in polar stereographic projection

[Kyle Shannon]

Daniel,
Can you report your GDAL version, and perhaps a sample dataset?

On Mon, Oct 6, 2014 at 1:32 PM, teeschke  wrote:
> Dear list,
>
> I am having trouble to handle grib files, that are polar stereographic
> projected. My goal is to reproject the grib into WGS84, but gdalinfo and
> gdalwrap cannot find any data iside the grib.
>
> $ gdalinfo south_hemisphere.grb
> Warning: Inside GRIB2Inventory, Message # 2
> ERROR: Ran out of file reading SECT0
> There were 94 trailing bytes in the file.
> ERROR 4: south_hemisphere.grb is a grib file, but no raster dataset was
> successfully identified.
> gdalinfo failed - unable to open 'south_hemisphere.grb'.
>
>
> Analyzing the file with wgrib brings the following result
>
> $ wgrib -V south_hemisphere.grb
> rec 1:0:date 2014092012 ICEC kpds5=91 kpds6=1 kpds7=0 levels=(0,0) grid=5
> sfc anl: bitmap: 0 undef
>   ICEC=Ice (ice=1;no ice=0) [fraction]
>   timerange 0 P1 0 P2 0 TimeU 1  nx 790 ny 830 GDS grid 5 num_in_ave 0
> missing 0
>   center 88 subcenter 0 process 1 Table 1 scan: WE:SN winds(N/S)
>   polar stereo: Lat1 -41.501000 Long1 -135.00 Orient 0.00
>  north pole (790 x 830) Dx 1 Dy 1 scan 64 mode 0
>   min/max data -199 100  num bits 16  BDS_Ref -199  DecScale 0 BinScale -7
>
> With wgrib and the netcdf-tools* I can display the metadata. Panoply** can
> also display the grib file in variouse projections
>
> Is GDAL made for working with polar stereographic projected gribs? Do you
> have any idea how I can reproject the grib file?
>
> Thanks you so much and best regards,
> Daniel
>
> *
> http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/documentation.htm
> ** http://www.giss.nasa.gov/tools/panoply/
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/handle-GRIB-files-in-polar-stereographic-projection-tp5166227.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] ogr2ogr sqldump?

[Kyle Shannon]

Vladan,

On Sat, Sep 27, 2014 at 9:45 AM, Vladan Divljak  wrote:
> Hi,
>
> I want migrate data between PostGIS enabled Postgres database and SQL Server
> spatial database. ogr2ogr seems like easiest possible way, but there is a
> catch with this ticket: http://trac.osgeo.org/gdal/ticket/5239
>
> I tried it nonetheless, but as expected Postgres tables with UTF-8 strings
> show garbage in SQL Server.
>
> I don't see any switch in org2ogr to be able to dump sql queries that
> ogr2ogr executes in migration process. Is there any? That way I can
> search/replace to get correct sql queries for the task.

Have you looked at the pgdump driver for ogr:

http://gdal.org/drv_pgdump.html

It may suit your needs.

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



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

Re: [gdal-dev] Fwd: gdalwarp -r average bug?

[Kyle Shannon]

On Thu, Sep 25, 2014 at 8:10 AM, Kyle Shannon  wrote:
> Stephen,
>
> On Wed, Sep 24, 2014 at 2:21 PM, Stephen Roecker
>  wrote:
>> Out of curiousity the other day I compared the results of gdalwarp (-r
>> average) against  the raster R package aggregate(fun=mean) function
>> for aggregating a raster to a coarser resolution. I was suprized how
>> different the results of gdalwarp were from raster. When zooming in
>> and manually averaging the overlapping cells, the results of gdal were
>> off.
>>
>> The elevation difference between the raster and gdal aggregated
>> rasters only averaged 0.66 meters, but had a max of 12 meters. Also
>> when subtracting the raster and gdal aggregated rasters, the resulting
>> subtracted layer looked like a hillshade, suggesting the GDAL
>> aggregated raster was shifted. However the raster and GDAL rasters
>> overlapped perfectly, so I can only assume the shift occured during
>> the aggregation process.
>>
>> Can someone explain gdal's behavior to me? Why the difference, is this
>> a bug in gdal? gdalwarp claims it's averaging all the overlapping
>> cells except the NA. That doesn't seem to be the case. FYI I'm using
>> GDAL 1.10.1
>>
>> See a reproduceable R example below.
>>
>> Stephen
>>
>> library(gdalUtils)
>> library(raster)
>>
>> src_dataset <- system.file("external/tahoe_lidar_bareearth.tif",
>> package="gdalUtils")
>> test <- raster(x=src_dataset)
>>
>> writeRaster(test, "test.tif", overwrite=T)
>> gdal_setInstallation(search_path="C:/ProgramData/QGIS/QGISDufour/bin",
>> rescan=T, verbose=T)
>> gdalwarp(srcfile=src_dataset, dstfile="test_gdal.tif", of="GTiff",
>> r="average", ot="Float32", tr=res(test)*3, overwrite=TRUE,
>> verbose=TRUE)
>>
>> aggregate(x=raster(src_dataset), fact=3, filename="test_raster.tif",
>> format="GTiff", NAflag=-9,
>>   progress="text", overwrite=T)
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> Without looking too far into it, it seems similar to:
>
> http://trac.osgeo.org/gdal/ticket/5311
>
> --
> Kyle

Apologies, it does appear to be different, my mistake.

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

Re: [gdal-dev] Fwd: gdalwarp -r average bug?

[Kyle Shannon]

Stephen,

On Wed, Sep 24, 2014 at 2:21 PM, Stephen Roecker
 wrote:
> Out of curiousity the other day I compared the results of gdalwarp (-r
> average) against  the raster R package aggregate(fun=mean) function
> for aggregating a raster to a coarser resolution. I was suprized how
> different the results of gdalwarp were from raster. When zooming in
> and manually averaging the overlapping cells, the results of gdal were
> off.
>
> The elevation difference between the raster and gdal aggregated
> rasters only averaged 0.66 meters, but had a max of 12 meters. Also
> when subtracting the raster and gdal aggregated rasters, the resulting
> subtracted layer looked like a hillshade, suggesting the GDAL
> aggregated raster was shifted. However the raster and GDAL rasters
> overlapped perfectly, so I can only assume the shift occured during
> the aggregation process.
>
> Can someone explain gdal's behavior to me? Why the difference, is this
> a bug in gdal? gdalwarp claims it's averaging all the overlapping
> cells except the NA. That doesn't seem to be the case. FYI I'm using
> GDAL 1.10.1
>
> See a reproduceable R example below.
>
> Stephen
>
> library(gdalUtils)
> library(raster)
>
> src_dataset <- system.file("external/tahoe_lidar_bareearth.tif",
> package="gdalUtils")
> test <- raster(x=src_dataset)
>
> writeRaster(test, "test.tif", overwrite=T)
> gdal_setInstallation(search_path="C:/ProgramData/QGIS/QGISDufour/bin",
> rescan=T, verbose=T)
> gdalwarp(srcfile=src_dataset, dstfile="test_gdal.tif", of="GTiff",
> r="average", ot="Float32", tr=res(test)*3, overwrite=TRUE,
> verbose=TRUE)
>
> aggregate(x=raster(src_dataset), fact=3, filename="test_raster.tif",
> format="GTiff", NAflag=-9,
>   progress="text", overwrite=T)
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Without looking too far into it, it seems similar to:

http://trac.osgeo.org/gdal/ticket/5311

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

Re: [gdal-dev] unable to write a shapefile using ogr

[Kyle Shannon]

Beau,

On Wed, Sep 10, 2014 at 7:30 AM, Beau Taylor  wrote:
> The following program successfully creates a shape file I am requiring.
>
> from osgeo import ogr
> from osgeo import osr
>
> def myRing(coords):
> ring = ogr.Geometry(ogr.wkbLinearRing)
> for xy in coords:
> ring.AddPoint(xy[0],xy[1])
> return ring
>
> coords = [(-23.378906,68.974164), (-23.378906,34.307144),
> (31.464844,34.307144), (31.464844,68.974164), (-23.378906,68.974164)]
>
> ring = myRing(coords)
> poly = ogr.Geometry(ogr.wkbPolygon)
> poly.AddGeometry(ring)
>
> outDriver = ogr.GetDriverByName('ESRI Shapefile')
> data_source = outDriver.CreateDataSource('test.shp')
> srs = osr.SpatialReference()
> srs.ImportFromEPSG(4326)
> layer = data_source.CreateLayer('test.shp', srs, ogr.wkbPolygon)
>
> feature = ogr.Feature(layer.GetLayerDefn())
> feature.SetGeometry(poly)
> layer.CreateFeature(feature)
>
> feature.Destroy
> data_source.Destroy()
>
> However, I did not know how to do the followings:
>
> -set the color of outer ring as blue,
> -do not fill the polygen

Style is usually dictated by the application.  You can set them in the
app, or for some formats/drivers you can use the OGR style API:

http://gdal.org/ogr_feature_style.html

AFAIK, shapefiles do not support styles

> -name the feature as 'test'

Add a field to the feature definition, called 'name', see the
tutorial, I think it has that exact example:

http://gdal.org/ogr_apitut.html

>
> I hope someone can help me.
>
> Thanks in the advance.
> Beau
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

If you are using GDAL/OGR 1.x, use the docs at:

http://gdal.org/1.11/index.html


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

Re: [gdal-dev] SVG support

[Kyle Shannon]

Scott,

On Fri, Aug 29, 2014 at 9:25 AM, Scott Rowles  wrote:
> Hi,
>
> I am using the 1.11 precompiled binaries with with libexpat included in the
> GDAL_DATA path.  I am trying to read an SVG file, which according to the
> vector format support table should work.  But it is failing and saying that
> it cannot open the file.

The svg driver appears to be very limited:

http://gdal.org/drv_svg.html

"""
Currently, it will only read SVG files that are the output from
Cloudmade Vector Stream Server
"""

>
> Any thoughts on how to troubleshoot/resolve this?
>
> scott
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] "ESRI Shapefile" Driver Not Found

[Kyle Shannon]

On Tue, Jul 29, 2014 at 1:46 PM, Michael Aschenbeck
 wrote:
> Hello,
>
> I'm having trouble creating a shapefile.  My problems are isolated to the
> following c++ block:
>
> const char *pszDriverName = "ESRI Shapefile";
> GDALDriver *poDriver;
> GDALAllRegister();
> poDriver = GetGDALDriverManager()->GetDriverByName(pszDriverName );
> if( poDriver == NULL )
> {
> printf( "%s driver not available.\n", pszDriverName );
> exit( 1 );
> }
>
> which enters the conditional since it cannot find the "ESRI Shapefile"
> driver.
>
> The funny thing is that this driver loads no problem with my Python
> bindings.  Does anyone have any advice to help me out?
>
> Thanks,
> Mike
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Michael,

What version of GDAL are you using?  2.0+ has a unified driver
manager, but in previous versions the vector drivers (such as ESRI
Shapefile) were OGR drivers.  The older documentation can be found
here:

http://gdal.org/1.11/index.html

OGR docs:

http://gdal.org/1.11/ogr/index.html

OGR tutorial:

http://gdal.org/1.11/ogr/ogr_apitut.html

The documentation at gdal.org represents the development version and
if you are using the that version(2.0), AFAIK your code would work
fine.

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

Re: [gdal-dev] Call for discussion on RFC 46: GDAL/OGR unification

[Kyle Shannon]

Even,

On Wed, May 7, 2014 at 4:13 PM, Even Rouault
 wrote:
> Hi,
>
> This is a call for discussion on "RFC 46: GDAL/OGR unification"
>
>   http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification
>
> Best regards,
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

It looks good to me, and surprisingly few changes for users (I think).
 Thanks for the work.

kss

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

Re: [gdal-dev] FileGDB feature datasets

[Kyle Shannon]

William,

On Fri, May 2, 2014 at 1:44 PM, William Kyngesburye
 wrote:
> For a while I've been converting FileGDB v9 files to v10 with Arc (export to 
> GDB multiple) so I can read them with GDAL (1.10).  This works fine, the 
> conversion creates a flat GDB, though the original GDB has the data grouped 
> in feature datasets.
>
> I just got some v10 GDBs, so no conversion needed, right?  Nothing is visible 
> with GDAL.  They also have data divided into feature datasets within the GDB, 
> so it sounds like GDAL can't acces the dataset groups.  Unless I'm missing an 
> option (the GDAL docs for the FileGDB format don't mention datasets)?

Do you have non-standard SRS in the layers?  FileGDB driver can't see
some layers if that is the case, see:

http://trac.osgeo.org/gdal/ticket/4578

However, with 1.11, there is an OpenFileGDB driver that should be able
to pick up the layers in that case (and read version 9 gdb).

http://gdal.org/ogr/drv_openfilegdb.html

I doubt the FileGDB driver can write them though, and OpenFileGDB is
read-only.  You may be able to reproject them though.

If the SRS issue isn't the case, trying 1.11.0 and OpenFileGDB wouldn't hurt.

>
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
>
> "Mon Dieu! but they are all alike.  Cheating, murdering, lying, fighting, and 
> all for things that the beasts of the jungle would not deign to possess - 
> money to purchase the effeminate pleasures of weaklings.  And yet withal 
> bound down by silly customs that make them slaves to their unhappy lot while 
> firm in the belief that they be the lords of creation enjoying the only real 
> pleasures of existence
>
> - the wisdom of Tarzan
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] New OGR Driver for MongoDB

[Kyle Shannon]

Shuai

On Wed, Apr 30, 2014 at 7:55 AM, Zhang, Shuai  wrote:
> Hi there,
>
> I wrote a ogr driver for mongodb and wish to contribute to the community.
> but I'm not sure where to start and how to do it.

You can file a ticket for a new feature here:

http://trac.osgeo.org/gdal/newticket

Attach the new driver as a patch.

> Is there anyone who can give me a hand or some guidance about it?
> it will be terrific if you know geojson driver or couchdb driver well,
> so that we may have discussions on the code level.

Discussion can take place in the comments on the ticket.

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



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

Re: [gdal-dev] Import .GDB into MSSQL Server database

[Kyle Shannon]

On Tue, Apr 8, 2014 at 4:47 PM, Jan Heckman  wrote:
> Depends on the geodatabase version.
> If (AG) 10, there is a ogr driver for it, so you would not need shapefiles
> and avoid losing long fieldnames etc.
> There is no driver for earlier AG/gdb versions.

OpenFileGDB should handle earlier versions, read only:

http://gdal.org/ogr/drv_openfilegdb.html

It's in the trunk.

> Maybe it's an old thread, but it has some information.
> Integration in ogr.
> good luck,
> Jan
>
>
> On Tue, Apr 8, 2014 at 8:44 PM, cdp  wrote:
>>
>> Any ideas on how to import a .GDB into MSSQL Server database without
>> converting to a .shp first?
>>
>> Thanks all!
>> C
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Import-GDB-into-MSSQL-Server-database-tp5133917.html
>> Sent from the GDAL - Dev mailing list archive at Nabble.com.
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

On Tue, Apr 1, 2014 at 12:36 PM, Etienne Tourigny
 wrote:
> The 2 objections I have with json are :
>
> - it is so verbose that editing by hand is not as easy as .csv
> - the xml tags make file size much larger than .csv files, unless they would
> be stored in a compressed file (gzip)
>
> On the other hand, who messes with theses files on a regular basis anyway?
>
> It seems like a nice idea. In what ways would it be better than Even's
> suggestion to use sqlite?
>
>
> On Mon, Mar 31, 2014 at 4:37 PM, Dmitriy Baryshnikov 
> wrote:
>>
>> Hi,
>>
>> I think the JSON format is good for metadata storing and representation.
>> JSON support to store string, digits, bool, dates, etc. Write such data and
>> read such data from files.
>> But need good library or set of classes to work with it in memory
>> representation.
>> For example I like  wxJSON - it support to get value by name or iterate
>> values by index.
>>
>> int majorVer = root["wxWidgets"]["Version"]["Major"].AsInt();
>>
>>
>> root["wxWidgets"]["Authors"][0] = "J. Smart";
>> root["wxWidgets"]["Authors"][1] = "V. Zeitling";
>> root["wxWidgets"]["Authors"][2] = "R. Roebling";
>>
>>
>> It consist only 3 files (json reader, json writer and json value).
>>
>> It seems to me that json-c library is more complicated. Unfortunately
>> wxJSON cannot be used in GDAL as it have bindings to wxWidgets library, but
>> the approach is interesting. By the way wxWidgets have more democratic
>> license instead of qt.
>>
>> Best regards,
>> Dmitry
>>
>> 31.03.2014 23:03, Even Rouault пишет:
>>
>> Hi Etienne,
>>
>> Thanks for your ideas.
>>
>> Hi all,
>>
>> I have a few suggestions for gdal 2.0, based on my personal experience in
>> learning to use, enhance and maintain gdal/ogr code.
>>
>> - replace cpl/csl/string/xml code with a mainstream, modern cross-platform
>> toolkit such as QT, boost, etc.
>>
>> QT is certainly a dependency we wouldn't want to draw. Too big for some
>> embededded usage, and it would make GDAL to be practially bound by the
>> LGPL.
>> I guess standard C++ libraries classes, or perhaps boost, should do the
>> job
>> for what you mention below.
>>
>> While cpl/csl classes are robust and "do the job", they are not well
>> documented and not very intuitive for a new gdal coder. This is from my
>> personal experience, some may not agree.
>> They are also not used outside gdal, as such do not benefit from
>> enhancements as other toolkits.
>>
>> Well, at least, MapServer uses a few CPL functions : CPL minixml,
>> CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename,
>> CSLInsertString, etc..
>>
>> The drawback is that some data/methods would not be easily available in c
>> and other bindings. Also it might not be available for all platforms.
>> Existing code would still be able to use cpl/csl code but be deprecated
>> until a given release.
>>
>>
>> - upgrade/migrate gdal support file (files in .csv format such as gcs.csv)
>> reading to use containers (e.g. hash maps) instead of reading the relevant
>> .csv files every time
>>
>> Current reading of gdal support files is sub-optimal as any query for
>> support data requires reading the relevant support file(s). It would be
>> more efficient to read these once and cache into a container (such as hash
>> map). This could be done using a cross-platform toolkit mentioned earlier.
>>
>> Another option would be to use a .sqlite database with proper indices.
>> SQLite
>> would become a runtime requirement, but I don't think that would be a big
>> problem.
>>
>> - modify metadata treatment to be able to store/retrieve data in formats
>> other than strings (e.g. floats, doubles, boolean), and query the actual
>> type of a given metadata item.
>>
>> Currently there is no way to know if a given metadata item represents an
>> integer, float, double (or string).
>>
>> In the netcdf driver, I overcame this limitation in 2 ways:
>> 1) parsing the value to test if it is an int, float or double (potentially
>> error-prone)
>> 2) add an extra metadata item to specify the type of the data represented
>> (cumbersome and non-standard)
>>
>> My suggestion would be to be able to store metadata value along with its
>> data type (default string as previously). This would require some kind of
>> container for internal representation (e.g. in qt: QMap> QVariant>)
>> and a way to represent this on file (as .aux.xml or otherwise in files
>> that
>> support metadata) such as gtiff. Values could be stored as strings to
>> avoid
>> big/little endian conversion problems. Data type could be stored in a
>> (hidden) metadata domain, one item for each "real" metadata key.
>>
>> Interesting idea.
>>
>> Well, we need coders now ;-)
>>
>> Even
>>
>>
>>
>> ___
>> 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.

Re: [gdal-dev] Rasterize a shapefile as mask

[Kyle Shannon]

On Mon, Mar 31, 2014 at 9:19 AM, shawn gong  wrote:
> Hi list,
>
> I have a RSAT-2 image and a shoreline vector (consists of 2 polygons). I
> want to generate a mask with the same # of lines and pixels as the RSAT-2
> image, and make inside polygons as 0, outside as 1.
>
> The example that I could find is UTM based, which I tried and sort of
> worked. But the mask image is not oblique as the RSAT-2 image. When I used
> the lat/lon projection, the gdal.RasterizeLayer() doesn't work. Would
> someone tell me why?
>
> thanks,
> Shawn
>
>
> UTM version that worked:
> from osgeo import gdal, ogr, gdal_array
>
> # Filename of input OGR file
> vector_file = 'shoreline_utm.shp'
>
> # Open the data source and read in the extent
> vector_ds = ogr.Open(vector_file)
> vector_layer = vector_ds.GetLayer()
> #vector_srs = vector_layer.GetSpatialRef()
> x_min, x_max, y_min, y_max = vector_layer.GetExtent()
>
> # raster Tiff that will be created
> new_raster = 'shoreline_utm.tif'
>
> pixel_spacing = 9.77
> line_spacing = 5.5
> xsize = int((x_max - x_min) / pixel_spacing)
> ysize = int((y_max - y_min) / line_spacing)
>
> new_raster_ds = gdal.GetDriverByName('GTiff').Create(new_raster, xsize,
> ysize, 1, gdal.GDT_Byte)
> new_raster_ds.SetGeoTransform((x_min, pixel_spacing, 0, y_max, 0,
> -line_spacing))
>
> band = new_raster_ds.GetRasterBand(1)
> band.Fill(1)
> gdal.RasterizeLayer(new_raster_ds, [1], vector_layer, burn_values=[0])
>
>
> lat/lon version:
> from osgeo import gdal, ogr, gdal_array
>
> # Filename of input OGR file
> vector_file = 'shoreline.shp'
>
> # Open the data source and read in the extent
> vector_ds = ogr.Open(vector_file)
> vector_layer = vector_ds.GetLayer()
>
> # raster Tiff that will be created
> new_raster = 'shorelineTest.tif'
>
> # master Tiff whose size will be copied
> master = 'product.xml'
> master_ds = gdal.Open(master)
> xsize, ysize = master_ds.RasterXSize, master_ds.RasterYSize
>
> new_raster_ds = gdal.GetDriverByName('GTiff').Create(new_raster, xsize,
> ysize, 1, gdal.GDT_Byte)
>
> # use georeferencing from the main product.xml dataset
> gdal_array.CopyDatasetInfo(master_ds, new_raster_ds)
>
> band = new_raster_ds.GetRasterBand(1)
> band.Fill(1)
>
> gdal.RasterizeLayer(new_raster_ds, [1], vector_layer, burn_values=[0])
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Shawn,
According to the docs, the layer has to be in the same srs as the
raster.  Are you doing this?  If it's not, you can provide a
transformer, or reproject the geometries yourself.  See:

http://gdal.org/gdal__alg_8h.html#adfe5e5d287d6c184aab03acbfa567cb1

notably the pfnTransformer arg.

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

Re: [gdal-dev] GDAL 1.11 release plan

[Kyle Shannon]

On Fri, Mar 28, 2014 at 8:14 AM, Vincent Mora  wrote:
> On 28/03/2014 10:06, Even Rouault wrote:
>>>
>>> A good plan! Especially when including the Walk driver
>
> And the WAsP driver ?
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Vincent,
The trunk will be 1.11.0, the WAsP driver will be included.

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

Re: [gdal-dev] Extra Decimal places added to ASCII gdal_translate mosaic

[Kyle Shannon]

Hi,
I restored DECIMAL_PRECISION and added SIGNIFICANT_DIGIT and also
reformatted the NODATA_value, although that may or may not be correct
as per Even's remarks.  See:

http://trac.osgeo.org/gdal/ticket/3732

for a review.

On Mon, Mar 10, 2014 at 1:21 PM, Even Rouault
 wrote:
> Le lundi 10 mars 2014 18:55:36, Jonathan Moules a écrit :
>> Hi Etienne,
>> I was looking for something like that but the
>> http://www.gdal.org/frmt_gtiff.html page didn't list it explicitly.
>>
>> That said, looking at the gdalinfo now (a little late) I see that it's
>> already defaulting to Float32. I also tested with the "-ot Float32"
>> arguement, but there was no change. I'm counting 16 significant figures; I
>> only want 5 or 6.
>
> TIFF stores floating point values as IEEE754 floats. Talking about significant
> figures doesn't make much sense. You could test using Float64 with the hope
> that 50.597 can be exactly represented as a Float64. Otherwise you'll have to
> do the rounding when reading back from TIFF.
>
>>
>> Cheers,
>> Jonathan
>>
>> On 10 March 2014 17:49, Etienne Tourigny  wrote:
>> > Have you tried using a 36bit (float) instead of 64bit (double) output?
>> >
>> >  double is usually the default output type and has more significant
>> >  digits
>> >
>> > (~16) than your source, so it's representation is "ok" in double format
>> >
>> > see [1] for an explanation on floating-point precision
>> >
>> > the following argument would do this "-ot Float32"
>> >
>> > [1] http://en.wikipedia.org/wiki/Floating_point
>> >
>> > Etienne
>> >
>> >
>> > On Mon, Mar 10, 2014 at 2:25 PM, Jonathan Moules <
>> >
>> > jonathanmou...@warwickshire.gov.uk> wrote:
>> >> Hi List,
>> >> Bringing back an old thread but with a slight change.
>> >>
>> >> I'm now trying to get GDAL to mosaic and export from the ASCII files to
>> >> a GeoTIFF.
>> >> But the GeoTIFF writer in GDAL is doing the exact same thing as the
>> >> ASCII writer was - it's taking *50.597* (source value) and converting
>> >> it into something like *50.596895342423*.
>> >>
>> >> I've tried using both gdal_merge and going via a VRT (gdalbuildvrt -
>> >> gdal_translate). The result is the same.
>> >>
>> >> I also tried the *DECIMAL_PRECISION* trick, but gdal informs me:
>> >>> Warning 6: Driver GTiff does not support DECIMAL_PRECISION creation
>> >>> option
>> >>
>> >> How do I get GDAL to merge these into a GeoTIFF without altering the
>> >> data?
>> >>
>> >> Thanks,
>> >> Jonathan
>> >>
>> >>
>> >> On 24 January 2014 16:12, Jonathan Moules <
>> >>
>> >> jonathanmou...@warwickshire.gov.uk> wrote:
>> >>> Thanks Norman. I'd already seen that page but failed to read it!
>> >>> However, having tested it, it's not functioning as the manual says.
>> >>>
>> >>> As best I can tell, DECIMAL_PRECISION=3 should give me 3 decimal
>> >>> places. But what it instead does it give me 3 significant figures. So
>> >>> 98.354 has become 98.3.
>> >>> This becomes a problem because many of my heights are hovering around
>> >>> 100. So some will either have to be 1 character too long to ensure no
>> >>> data loss for the rest.
>> >>>
>> >>> Is this a bug? The documentation on the page linked to is quite clear
>> >>> it should be decimal places.
>> >>>
>> >>> Less of an issue, but it also didn't make any difference to:
>>  xllcorner432000.
>>  yllcorner242000.
>>  cellsize 2.
>> >>>
>> >>> GDAL 1.10.1, released 2013/08/26
>> >>>
>> >>>
>> >>> Cheers,
>> >>> Jonathan
>> >>>
>> >>> On 24 January 2014 15:11, Norman Vine  wrote:
>>  try
>> 
>>  gdal_translate -of AAIGrid -co DECIMAL_PRECISION=3  abc.vrt abc.asc
>> 
>>  see http://www.gdal.org/frmt_various.html
>>  HTH
>>  Norman
>> 
>>  On Jan 24, 2014, at 10:01 AM, Jonathan Moules <
>>  jonathanmou...@warwickshire.gov.uk> wrote:
>> 
>>  Hi List,
>>  I'm trying to mosaic some ASCII grid tiles into a single large ASCII
>>  file (which can then easily be handled).
>> 
>>  I'm using this process:
>> > REM Create list of files
>> > dir /b /s *.asc > asc_list.txt
>> >
>> >
>> >
>> > REM Turn into VRT
>> > gdalbuildvrt -srcnodata "-" -vrtnodata "0" -a_srs "EPSG:27700"
>> > -input_file_list "asc_list.txt" abc.vrt
>> >
>> >
>> >
>> > REM actual mosaicing
>> > gdal_translate -of AAIGrid abc.vrt abc.asc
>> 
>>  The input files are like:
>> > ncols 500
>> > nrows 500
>> > xllcorner 432000.000
>> > yllcorner 243000.000
>> > cellsize  2
>> > nodata_value  -.0
>> > 98.354 98.449 98.658 98.874 99.038 99.096
>> 
>>  But the outputs are like:
>> 
>>  fncols500
>> 
>> > nrows1000
>> > xllcorner432000.
>> > yllcorner242000.
>> > cellsize 2.
>> > NODATA_value  0
>> >
>> >  98.353996276855469 98.448997497558594 98.657

Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
 wrote:
> Hi,
>
> I've confirmed my presence to the OSGeo Vienna code sprint (
> http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 ). Are there folks that
> will be there and indent doing some work on GDAL ? Any particular topics of
> interest ?
>
> It could be the opportunity to take a crack at some changes that have been
> mentionned for some time and are listed at
> http://trac.osgeo.org/gdal/wiki/GDAL20Changes
>
> We should decide how to manage the 2.0 transition. I think that the 2.0 number
> should be reserved as the opportunity of introducing breaking changes in the
> API / ABI. But this might take a long time to implement all that is listed
> above, so there's a risk we end up with a trunk that is never ready for
> release for years. Not a good thing.
> On the other hand, we could just be more modest and take breaking changes as
> they are introduced and raise the major version number (so the yearly version
> after 2.0 could be 3.0). This will require projects using GDAL to adapt
> multiple times.
> An alternative would be to prepare the API for new features even if they are
> not implemented, but that's a difficult exercise and there's a risk that at
> implementation time, the API doesn't fit.
> Any thoughts ?
>
> Currently we have no such breakage in trunk so it could qualify as GDAL 1.11.
> Perhaps we should just release it as such for now before the bigger changes ?
>
> Somes topics I can see for GDAL 2.0 that impact API/ABI :
> - well, the mythological unification of OGR driver model with GDAL driver
> model.
> - XYZM support
> - Curve geometries
> - 64 bit integer support
>
> Other possible structural changes :
> - Change of master version control system: switch to git / GitHub ?
> - New build system : cmake ?
>
> Of course all of this will more likely happen if contributors or funders show
> up !
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Hi, I meant to bring this up in my earlier email, but it slipped my
mind.  Or maybe I didn't want to open a can of worms.  What exactly
would 'unification' entail?  I assume all ogr drivers would have to
inherit GDALMajorObject (and probably OGRDataSource and OGRLayer
maybe?) and then ogr drivers would have to populate metadata.  I also
assume that this would replace GetCapabilities().  Can someone
elaborate on the scope of such a change?  Thanks.

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

Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

Dmitriy,

What version of cmake is required.

On Sat, Feb 15, 2014 at 1:31 PM, Dmitriy Baryshnikov
 wrote:
> Hi,
>
> As cmake4gdal developer I think there is no problem with cmake. By now we
> main code is cmaked, and deal only with some drivers (GDAL or OGR), which
> needed cmake scripts.
> I make needed cmake scripts for drivers what I use in may work.

Are any of your Find* scripts being pushed back into the cmake code
base, or do they live exclusively in the GDAL source tree?  It's
strange to me that cmake doesn't come bundled with find scripts for
libs like sqlite and mysql, they are fairly common.

>
> So, with some help we can do all cmake scripts rather fast.
>
> The current implementation is here:
> https://github.com/nextgis/gdal-svn/tree/cmake4gdal and
> https://github.com/aashish24/gdal-svn/tree/cmake4gdal
> The branches include not the latest GDAL repository commits, as they can
> include makefile chages, so there is some delay as I synchronize the
> branches.
>
> Now there are scripts to:
> 1) all libraries - CPL, GDAL, OGR
> 2) apps - gdaladdo, gdalbuildvrt, gdalinfo, gdallocationinfo, gdalwarp,
> gdal_contour, gdal_grid, gdal_translate, ogr2ogr, ogrinfo, test_ogrsf
> 3) GDAL drivers - bmp, dimap, gif, tiff, hfa, iso8211, jpeg, map, mem, ozi,
> png, postgisraster, raw, saga, til, vrt, wms
> 4) OGR drivers - csv, dxf, generic, geojson, gml, gpx, kml, libkml, mem,
> mitab, mysql, pg, s57, shape, sqlite, sxf, vrt, wfs
>
> Best regards,
> Dmitry
>
> 15.02.2014 22:57, Even Rouault пишет:
>
>> Thanks for your thoughs Kyle. I expect more developers and PSC members to
>> express theirs too.
>>
>>> How long would the stable branches be maintained?  Would we handle as
>>> we do now, with one stable branch and one development branch, or would
>>> we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
>>> require maintaining 3 branches?  stable, trunk, and api_break?  Any
>>> thoughts?
>>
>> What would be the api_break branch, as opposed to trunk I mean ?
>> Maintaining 2 branches in addition to the development branch seems to be a
>> bit
>> too much work. Well, backporting is not that difficult generally, but
>> releasing
>> a version is an effort that takes some energy and time, so we would have
>> likely
>> difficulty in making the necessary releases. But anyone wanting to
>> maintain a
>> branch can do it, so there's no need to set that policy in stone.
>>
 An alternative would be to prepare the API for new features even if they
 are not implemented, but that's a difficult exercise and there's a risk
 that at implementation time, the API doesn't fit.
 Any thoughts ?

 Currently we have no such breakage in trunk so it could qualify as GDAL
 1.11. Perhaps we should just release it as such for now before the
 bigger changes ?
>>>
>>> Maybe release 1.11 soon, and take a crack at 2.0 changes before the
>>> next release?  This would probably require a concerted effort from
>>> developers or funders, as Even mentioned in regard to the sprint.
>>>
 Somes topics I can see for GDAL 2.0 that impact API/ABI :
 - well, the mythological unification of OGR driver model with GDAL
 driver
 model.
 - XYZM support
 - Curve geometries
 - 64 bit integer support
>>>
>>> The 64-bit integer changes seem fairly straight forward.  I see XYZM
>>> support up for GSoC again, maybe it'll get picked up.  I have no idea
>>> what curve support would entail.
>>
>> Well, new geometry types and enhancements in drivers that would support
>> them
>> (PostGIS, ...). And also likely adapt all existing drivers that have write
>> support so they can deal with the new geometry types : ignore them, or
>> take
>> them into account.
>>
 Other possible structural changes :
 - Change of master version control system: switch to git / GitHub ?
 - New build system : cmake ?
>>>
>>> What are the benefits here?  > Is travis integration easier?
>>
>> Well, I put that on the table since it is sometimes mentionned by
>> developers,
>> but the effort vs benefit ratio is not completely obvious for existing
>> GDAL svn
>> commiters.
>> git transition would be mainly to keep up with what developers are of will
>> soon be familiar with. Someone pointed me recently that GitHub also
>> exposed
>> git repositories as subversion repositories (which I experimented a bit),
>> so
>> that could satisfy most developers. git has the benefit of easing porting
>> patches between branches, and making contributions from casual developers
>> easier. Since the git mirror already exists, the transition to github
>> would
>> essentially require porting the Trac database to Github tickets (we could
>> benefit from MapServer experience that has done that move before)
>>
>>> I believe
>>> someone has a cmake port floating around on github, any comments
>>> there?
>>
>> The effort seems to have stalled. The benefit here would be the
>> unification of
>> the Unix and Windows makefiles, but the com

Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

Even, thanks for the notes.

On Sat, Feb 15, 2014 at 11:57 AM, Even Rouault
 wrote:
> Thanks for your thoughs Kyle. I expect more developers and PSC members to
> express theirs too.
>
>>
>> How long would the stable branches be maintained?  Would we handle as
>> we do now, with one stable branch and one development branch, or would
>> we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
>> require maintaining 3 branches?  stable, trunk, and api_break?  Any
>> thoughts?
>
> What would be the api_break branch, as opposed to trunk I mean ?
> Maintaining 2 branches in addition to the development branch seems to be a bit
> too much work. Well, backporting is not that difficult generally, but 
> releasing
> a version is an effort that takes some energy and time, so we would have 
> likely
> difficulty in making the necessary releases. But anyone wanting to maintain a
> branch can do it, so there's no need to set that policy in stone.
>

Sorry, I chose poor wording, but you answered my question in regard to
two branches.  I agree with your assessment.

>>
>> > An alternative would be to prepare the API for new features even if they
>> > are not implemented, but that's a difficult exercise and there's a risk
>> > that at implementation time, the API doesn't fit.
>> > Any thoughts ?
>> >
>> > Currently we have no such breakage in trunk so it could qualify as GDAL
>> > 1.11. Perhaps we should just release it as such for now before the
>> > bigger changes ?
>>
>> Maybe release 1.11 soon, and take a crack at 2.0 changes before the
>> next release?  This would probably require a concerted effort from
>> developers or funders, as Even mentioned in regard to the sprint.
>>
>> > Somes topics I can see for GDAL 2.0 that impact API/ABI :
>> > - well, the mythological unification of OGR driver model with GDAL driver
>> > model.
>> > - XYZM support
>> > - Curve geometries
>> > - 64 bit integer support
>>
>> The 64-bit integer changes seem fairly straight forward.  I see XYZM
>> support up for GSoC again, maybe it'll get picked up.  I have no idea
>> what curve support would entail.
>
> Well, new geometry types and enhancements in drivers that would support them
> (PostGIS, ...). And also likely adapt all existing drivers that have write
> support so they can deal with the new geometry types : ignore them, or take
> them into account.
>
>>
>> > Other possible structural changes :
>> > - Change of master version control system: switch to git / GitHub ?
>> > - New build system : cmake ?
>>
>> What are the benefits here?  > Is travis integration easier?
>
> Well, I put that on the table since it is sometimes mentionned by developers,
> but the effort vs benefit ratio is not completely obvious for existing GDAL 
> svn
> commiters.
> git transition would be mainly to keep up with what developers are of will
> soon be familiar with. Someone pointed me recently that GitHub also exposed
> git repositories as subversion repositories (which I experimented a bit), so
> that could satisfy most developers. git has the benefit of easing porting
> patches between branches, and making contributions from casual developers
> easier. Since the git mirror already exists, the transition to github would
> essentially require porting the Trac database to Github tickets (we could
> benefit from MapServer experience that has done that move before)

I have no preference as to which scm is used, although if it allows
more people to use or contribute, I'm all for it.  This is probably
not realistic, but it also may be a chance to purge some older/invalid
tickets from the trac database.  I imagine there is no way of really
doing this without a human checking for validity though.

>
>> I believe
>> someone has a cmake port floating around on github, any comments
>> there?
>
> The effort seems to have stalled. The benefit here would be the unification of
> the Unix and Windows makefiles, but the complexity of GDAL dependencies makes
> the porting effort rather repelling...

I can imagine...

>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html

Thanks.

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

Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

Hi,  Just a few thoughts/questions...

On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
 wrote:
> Hi,
>
> I've confirmed my presence to the OSGeo Vienna code sprint (
> http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 ). Are there folks that
> will be there and indent doing some work on GDAL ? Any particular topics of
> interest ?
>
> It could be the opportunity to take a crack at some changes that have been
> mentionned for some time and are listed at
> http://trac.osgeo.org/gdal/wiki/GDAL20Changes
>
> We should decide how to manage the 2.0 transition. I think that the 2.0 number
> should be reserved as the opportunity of introducing breaking changes in the
> API / ABI. But this might take a long time to implement all that is listed
> above, so there's a risk we end up with a trunk that is never ready for
> release for years. Not a good thing.
> On the other hand, we could just be more modest and take breaking changes as
> they are introduced and raise the major version number (so the yearly version
> after 2.0 could be 3.0). This will require projects using GDAL to adapt
> multiple times.

How long would the stable branches be maintained?  Would we handle as
we do now, with one stable branch and one development branch, or would
we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
require maintaining 3 branches?  stable, trunk, and api_break?  Any
thoughts?

> An alternative would be to prepare the API for new features even if they are
> not implemented, but that's a difficult exercise and there's a risk that at
> implementation time, the API doesn't fit.
> Any thoughts ?
>
> Currently we have no such breakage in trunk so it could qualify as GDAL 1.11.
> Perhaps we should just release it as such for now before the bigger changes ?

Maybe release 1.11 soon, and take a crack at 2.0 changes before the
next release?  This would probably require a concerted effort from
developers or funders, as Even mentioned in regard to the sprint.

>
> Somes topics I can see for GDAL 2.0 that impact API/ABI :
> - well, the mythological unification of OGR driver model with GDAL driver
> model.
> - XYZM support
> - Curve geometries
> - 64 bit integer support

The 64-bit integer changes seem fairly straight forward.  I see XYZM
support up for GSoC again, maybe it'll get picked up.  I have no idea
what curve support would entail.

>
> Other possible structural changes :
> - Change of master version control system: switch to git / GitHub ?
> - New build system : cmake ?

What are the benefits here?  Is travis integration easier?  I believe
someone has a cmake port floating around on github, any comments
there?

>
> Of course all of this will more likely happen if contributors or funders show
> up !
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Regards,

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

Re: [gdal-dev] OGR changes some proj linear units, true or not?

[Kyle Shannon]

On Thu, Jan 30, 2014 at 2:19 PM, Jukka Rahkonen
 wrote:
> Kyle Shannon  pobox.com> writes:
>
>
> ...
>>
>> Jukka,
>>
>> I added proj4 parsing support for all units reported by cs2cs -lu in
>> the trunk in r26902, and created a ticket, #5370 to track the issue.
>> Do you want to update the QGIS ticket, or shall I?
>
> You understand better what you did so I suggest you to update the QGIS
> ticket, if you don't mind.
>
> -Jukka-
>
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Done, thanks.

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

Re: [gdal-dev] OGR changes some proj linear units, true or not?

[Kyle Shannon]

On Thu, Jan 30, 2014 at 5:31 AM, Jukka Rahkonen
 wrote:
> Hi,
>
> Noticed this one in QGIS issues http://hub.qgis.org/issues/9414
>
> Writer claims:
> "I just tried with a simple C++ wrapper around OSRImportFromProj4, and it
> seems OGR doesn't keep the unit for at least dm,cm,mm. It will only work for
> some units: such as km, ft, yd, us-ft, us-yd, etc."
>
> -Jukka Rahkonen-
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Jukka,

I added proj4 parsing support for all units reported by cs2cs -lu in
the trunk in r26902, and created a ticket, #5370 to track the issue.
Do you want to update the QGIS ticket, or shall I?

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

Re: [gdal-dev] gdal_translate - Generate Full 1 deg x 1 deg tile from partial data

[Kyle Shannon]

What version of gdal are you using?  Starting with 1.10, it
gdal_translate should do what you want.  Specifying -eco or -epo makes
it an error:

-epo: (Error when Partially Outside)(GDAL >= 1.10) If this option is
set, -srcwin or -projwin values that falls partially outside the
source raster extent will be considered as an error. The default
behaviour starting with GDAL 1.10 is to accept such requests, when
they were considered as an error before.

-eco: (Error when Completely Outside)(GDAL >= 1.10) Same as -epo,
except that the criterion for erroring out is when the request falls
completely outside the source raster extent.


http://www.gdal.org/gdal_translate.html

On Fri, Jan 17, 2014 at 8:34 AM, Metzen  wrote:
> I'm using gdalbuildvrt to combine a bunch of .dem files into a larger .vrt
> file, then using gdal_translate to slice this into 1 deg x 1 deg tiles.
>
> gdalbuildvrt index.vrt *.dem
>
> gdal_translate -of USGSDEM -projwin -88.0001042 52.0001042 -86.9998958
> 50.9998958 index.vrt output/N52W088.dem
>
> The problem comes when I need a 1 x 1 tile of an area that only has partial
> data.  Then I get "Computed -srcwin falls outside raster size".
>
> Is there a way I can pad the .vrt with null or 0values so the index.vrt
> raster size is larger and I can export a 1 x 1 tile?  The area I need to pad
> is all ocean, so 0 or null would be fine.
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/gdal-translate-Generate-Full-1-deg-x-1-deg-tile-from-partial-data-tp5098660.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] understanding gdalwarp default output resolution

[Kyle Shannon]

On Mon, Oct 28, 2013 at 8:55 AM, Ivan Marchesini
 wrote:
> Dear all,
> I'm using gdalwarp to reproject a wgs84 srtm (3 arcseconds) tile to a
> projected utm zone. I do not set "-tr" or "-ts" options, hence the final
> output resolution is estimated by the gdalwarp module itself.
>
> For my tile I obtained an output resolution of 81.19 meters and I'm
> wondering if one could explain which is the rationale behind this value.
>
> Many thanks
>
> Ivan
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Forgot the list...

Ivan,
gdalwarp uses GDALSuggestedWarpOutput:
http://gdal.org/gdal__alg_8h.html#a816819e7495bfce06dbd110f7c57af65

The docs state:

"""
...
Then a resolution is computed with the intent that the length of the
distance from the top left corner of the output imagery to the bottom
right corner would represent the same number of pixels as in the
source image. Note that if the image is somewhat rotated the diagonal
taken isn't of the whole output bounding rectangle, but instead of the
locations where the top/left and bottom/right corners transform. The
output pixel size is always square. This is intended to approximately
preserve the resolution of the input data in the output file.
...
"""

Essentially it tries to match the size of the source image in x size and y size.

kss

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

Re: [gdal-dev] Open BIL, BIP, and BSQ raster files without header

[Kyle Shannon]

Gabriel,
Did you look at the VRT dataset?

http://www.gdal.org/gdal_vrttut.html

I suspect that is what you are looking for.

kss

On Tue, Oct 22, 2013 at 7:27 AM, Gabriel Fusca
 wrote:
> Dear all,
>
> I'm using GDAL 1.9.1 and I would like to load binary raster files
> especifying manually header information such number of lines, number of
> pixels, pixel data type, byte order, bits per pixel.
>
> Also I would like to specify file offset, band offset and line offset for
> the file.
>
> Can someone please help me figure this out.
>
> Thanks in advance,
>
> Regards
> --
> Gabriel Fusca
> SUR Emprendimientos Tecnológicos
>
> Perú 345  Piso 5to Oficina "B" (C1067AAG)
> Ciudad de Buenos Aires, Argentina
> Tel. +54 (11) 4342-2976/84
> gabrielfu...@suremptec.com.ar
> http://www.suremptec.com/
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] /vsicurl/ and gz files

[Kyle Shannon]

On Fri, Oct 11, 2013 at 7:13 AM, Jose Gomez-Dans  wrote:
> Hello everyone,
>
> On 10 October 2013 19:58, Even Rouault  wrote:
>
>> Le jeudi 10 octobre 2013 20:33:49, Jose Gomez-Dans a écrit :
>> > Hi,
>> >
>> > I was wondering if it's possible to use /vsitar/ to have a peek in .gz
>> > files, such as this one:
>> >
>> > http://www.globalbedo.org/GlobAlbedo29/tiles/2004/h17v04/GlobAlbedo.2004001
>> > .h17v04.nc.gz
>>
>> This is a gzip file, not a .tar.gz file, so you would have to use /vsigzip
>> , and
>> as it is a gzip file over http, you have to combine it with /vsicurl
>
>
> I hadn't seen the /vsigzip/ option, but it's quite obvious! The /vsicurl/
> limitation isn't important, I just thought it'd be a nice way to brag about
> GDAL ;-) However, one problem still persists. While I can prod into the
> decompressed file (e.g. after I have gunzipped it), the following command
> still reports a problem, e.g:
>
> $ gdalinfo /vsigzip/GlobAlbedo.2004001.h17v04.nc.gz
> ERROR 1: netcdf error #-33 : NetCDF: Not a valid ID .
> at (netcdfdataset.cpp,~netCDFDataset,1446)
>
> gdalinfo failed - unable to open '/vsigzip/GlobAlbedo.2004001.h17v04.nc.gz'.
>
> gdalinfo --version
> GDAL 1.10.0, released 2013/04/24
>
> $ gunzip GlobAlbedo.2004001.h17v04.nc.gz
>
> $ gdalinfo GlobAlbedo.2004001.h17v04.nc.gz
> ERROR 4: `GlobAlbedo.2004001.h17v04.nc.gz' does not exist in the file
> system,
> and is not recognised as a supported dataset name.
>
> gdalinfo failed - unable to open 'GlobAlbedo.2004001.h17v04.nc.gz'.
>
> $ gdalinfo GlobAlbedo.2004001.h17v04.nc
> Driver: netCDF/Network Common Data Format
> Files: GlobAlbedo.2004001.h17v04.nc
> Size is 512, 512
> Coordinate System is `'
> Metadata:
>   NC_GLOBAL#Conventions=CF-1.4
> Subdatasets:
>   SUBDATASET_1_NAME=NETCDF:"GlobAlbedo.2004001.h17v04.nc":DHR_VIS
>   SUBDATASET_1_DESC=[1200x1200] DHR_VIS (32-bit floating-point)
> []
>
> Thanks!
> Jose
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

As Even mentioned, the NetCDF driver doesn't use the VSI*L mechanism,
so you can't use /vsi*/ stuff with it unless you use
LD_PRELOAD=vsipreload.so, see above.

kss

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

Re: [gdal-dev] Gdalinfo does not print into file on Windows

[Kyle Shannon]

On 09/17/2013 05:07 AM, Jukka Rahkonen wrote:

Hi,

I noticed that gdalinfo and gdallocationinfo tools do not print into file
with command
gdalinfo test.tif >report.txt

The file report.txt is created but it remains empty. With ogrinfo printing
into file goes well. I also had a try with some old FWTools and with that I
could redirect also gdalinfo report into file.

I was testing on Windows 7 and last nights 64-bit GDAL from trunk
http://gisinternals.com/sdk/Download.aspx?file=release-1600-x64-gdal-mapserver.zip

-Jukka Rahkonen-

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


Jukka,
There is a ticket that may be related.  See:

http://trac.osgeo.org/gdal/ticket/5073

and

http://trac.osgeo.org/gdal/ticket/5128

That user reports failure of redirection if the ecw plugin is installed.

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

[gdal-dev] Coverity Security Scan

[Kyle Shannon]

All,
I have recently created a project for GDAL on Coverity Scan.  The scan 
is a static code analysis tool that checks for various errors including 
resource leaks, dead code, out-of-bounds array access, and various other 
common errors.  If you are currently a committer and maintaining a 
driver, I (or another admin) can add you to the project if you are 
interested in your area of responsibility.  The project site is here:


https://www.scan.coverity.com/projects/749

and a little information about coverity:

https://www.scan.coverity.com/faq

If there are any questions, please feel free to ask.  Thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL Warp API Java bindings

[Kyle Shannon]

On Thu, Sep 5, 2013 at 10:30 AM, Markus Schneider
 wrote:
> kss,
>
> thanks. gdal.ReprojectImage(..) looks like what I will be using then. :-)
>
> My use case:
>
> - My huge (ECW) dataset is in EPSG:28992
> - I want to extract a defined region in EPSG:4326 as a (Java) BufferedImage
>
> How can I get hold of a suitable destination dataset so I can use
> ReprojectImage(...)?
>
> Thanks,
> Markus
>
> Am 05.09.2013 18:19, schrieb Kyle Shannon:
>> On Thu, Sep 5, 2013 at 10:05 AM, Markus Schneider
>>  wrote:
>>> Hi again,
>>>
>>> I would like to try using the Warp API from Java. It seems that there
>>> are currently no Java bindings available.
>>>
>>> - Did anbody work on Java bindings for the Warp API?
>>> - How hard would it be to define them? I may be able to invest some time
>>> here.
>>>
>>> Best regards,
>>> Markus
>>>
>>> --
>>> Markus Schneider
>>> CEO
>>>
>>> Occam Labs UG (haftungsbeschränkt)
>>> Godesberger Allee 139
>>> 53175 Bonn, Germany
>>>
>>> +49 228 93798874
>>>
>>> http://www.occamlabs.de
>>>
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> Markus,
>>
>> What are you trying to do exactly?  I see that ReprojectImage() and
>> AutoCreateWarpedVRT are exposed in org.gdal.gdal.gdal:
>>
>> http://gdal.org/java/
>>
>> kss
>>
>
>
> --
> Markus Schneider
> CEO
>
> Occam Labs UG (haftungsbeschränkt)
> Godesberger Allee 139
> 53175 Bonn, Germany
>
> +49 228 93798874
>
> http://www.occamlabs.de
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

I believe normally you can use GDALSuggestedWarpOutput
(http://gdal.org/gdal__alg_8h.html#a816819e7495bfce06dbd110f7c57af65)
but that doesn't seem to be exposed.  If it's a simple case,
AutoCreateWarpedVRT() and CreateCopy() should work instead of
ReprojectImage().

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

Re: [gdal-dev] GDAL Warp API Java bindings

[Kyle Shannon]

On Thu, Sep 5, 2013 at 10:05 AM, Markus Schneider
 wrote:
> Hi again,
>
> I would like to try using the Warp API from Java. It seems that there
> are currently no Java bindings available.
>
> - Did anbody work on Java bindings for the Warp API?
> - How hard would it be to define them? I may be able to invest some time
> here.
>
> Best regards,
> Markus
>
> --
> Markus Schneider
> CEO
>
> Occam Labs UG (haftungsbeschränkt)
> Godesberger Allee 139
> 53175 Bonn, Germany
>
> +49 228 93798874
>
> http://www.occamlabs.de
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Markus,

What are you trying to do exactly?  I see that ReprojectImage() and
AutoCreateWarpedVRT are exposed in org.gdal.gdal.gdal:

http://gdal.org/java/

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

Re: [gdal-dev] gdal_edit.py -a_nodata none

[Kyle Shannon]

On Fri, Aug 23, 2013 at 4:35 PM, Even Rouault
 wrote:
> Le vendredi 23 août 2013 23:21:06, Kyle Shannon a écrit :
>> On Fri, Aug 23, 2013 at 10:04 AM, Hermann Peifer  wrote:
>> > On 2013-08-23 15:23, Even Rouault wrote:
>> >> Selon peifer :
>> >>> Hi,
>> >>>
>> >>> http://www.gdal.org/gdal_edit.html states about -a_nodata
>> >>>
>> >>>> Assign a specified nodata value to output bands.
>> >>>> Can be set to none to remove a nodata value if one exists for the
>> >>>> dataset.
>> >>>
>> >>> I assume that none means the literal string `none', but what happens is
>> >>> given below.
>> >>>
>> >>> Is this just a plain bug or am I doing something terribly wrong?
>> >>
>> >> Hi Hermann,
>> >>
>> >> This is a documentation bug. This is not supported by the code. And
>> >> there's no
>> >> (standard) way in the GDAL API to remove a nodata value once it is set.
>> >>
>> >> Could you file a ticket about that ?
>> >
>> > Done, see http://trac.osgeo.org/gdal/ticket/5213
>> >
>> > Hermann
>> >
>> >
>> > ___
>> > gdal-dev mailing list
>> > gdal-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> Even,
>> According to the docs at
>> http://gdal.org/classGDALRasterBand.html#ac6f081d253dee55c372e54cfdd8f05a6
>>
>> """To clear the nodata value, just set it with an "out of range"
>> value. Complex band no data values must have an imagery component of
>> zero."""
>>
>> This seems a little unreliable though, especially if changing the data
>> type in gdal_translate or some other app.  If the no data value is
>> copied and is within the new range for the new data type, the behavior
>> is unexpected(I think).  Should the docs state that once a no data
>> value is set, in cannot be unset as well?  I'm a bit confused.
>
> Yes, there's no definitive and clean way of unsetting a nodata value once it 
> is
> set. Practically, you can workaround that by setting it to out of range. I'm
> not sure that conversion to a wider type will cause problems however, if the
> pixel values remain unchanged. For example if you have a byte pixel type, and
> pick -1 as nodata value, then translating it to signed int 16 will not really
> cause problems (immediately) since the pixel values will remain in the [0-255]
> range. Of course if the data is edited afterwards, then -1 coud be assigned to
> a pixel.

That was the situation I was referring to, when an 'invalid pixel' is
suddenly allowed.

>
> Feel free to edit the doc to add some caution wording.
>

I will probably add a note, no data stuff seems to always get me.

> Ideally the API should have a ClearNoDataValue() method. I'm not sure that
> many file formats could really implement it. PAM storage of course could
> support that. GeoTIFF probably too be erasing the GDAL_NODATA tag.

I checked a few drivers, and it appeared that GeoTIFF and HFA both
have a flag that signals if the no data value has been set and is
valid.  It seems that the best way to handle it would be similar.
Thanks for the reply.

>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html

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

Re: [gdal-dev] gdal_edit.py -a_nodata none

[Kyle Shannon]

On Fri, Aug 23, 2013 at 10:04 AM, Hermann Peifer  wrote:
> On 2013-08-23 15:23, Even Rouault wrote:
>>
>> Selon peifer :
>>
>>> Hi,
>>>
>>> http://www.gdal.org/gdal_edit.html states about -a_nodata
>>>
 Assign a specified nodata value to output bands.
 Can be set to none to remove a nodata value if one exists for the
 dataset.
>>>
>>>
>>> I assume that none means the literal string `none', but what happens is
>>> given below.
>>>
>>> Is this just a plain bug or am I doing something terribly wrong?
>>
>>
>> Hi Hermann,
>>
>> This is a documentation bug. This is not supported by the code. And
>> there's no
>> (standard) way in the GDAL API to remove a nodata value once it is set.
>>
>> Could you file a ticket about that ?
>>
>
> Done, see http://trac.osgeo.org/gdal/ticket/5213
>
> Hermann
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Even,
According to the docs at
http://gdal.org/classGDALRasterBand.html#ac6f081d253dee55c372e54cfdd8f05a6

"""To clear the nodata value, just set it with an "out of range"
value. Complex band no data values must have an imagery component of
zero."""

This seems a little unreliable though, especially if changing the data
type in gdal_translate or some other app.  If the no data value is
copied and is within the new range for the new data type, the behavior
is unexpected(I think).  Should the docs state that once a no data
value is set, in cannot be unset as well?  I'm a bit confused.

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

Re: [gdal-dev] Overflow in geojson values

[Kyle Shannon]

On Thu, Aug 1, 2013 at 11:36 AM, Smith, Michael ERDC-RDE-CRREL-NH
 wrote:
> I'm reading a geojson feed put out by the USGS
> (http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_day.geojson)
> but the time/updated values are overflowing. Are there any settings to allow
> the data to come across as bigint or strings?
>
> For example:
> {"type":"Feature","properties":{"mag":0.46,"place":"2km W of Lemmon Valley,
> Nevada","time":1375291903959,"updated":1375295733317,"tz":-420,"url":"http://earthquake.usgs.gov/earthquakes/eventpage/nn00419191","detail":"http://earthquake.usgs.gov/earthquakes/feed/v1.0/detail/nn00419191.geojson","felt":null,"cdi":null,"mmi":null,"alert":null,"status":"REVIEWED","tsunami":null,"sig":3,"net":"nn","code":"00419191","ids":",nn00419191,","sources":",nn,","types":",cap,general-link,geoserve,nearby-cities,origin,","nst":12,"dmin":0.069,"rms":0.1034,"gap":74,"magType":"ml","type":"earthquake"},"geometry":{"type":"Point","coordinates":[-119.8773,39.632,5.0829]},"id":"nn00419191"}
>
> Gets returned as
>
> OGRFeature(OGRGeoJSON):176
>   mag (Real) = 1.7
>   place (String) = 21km S of Lowell, Oregon
>   time (Integer) = 902732480
>   updated (Integer) = 903846662
>   tz (Integer) = -420
>   url (String) = http://earthquake.usgs.gov/earthquakes/eventpage/uw60561592
>   detail (String) =
> http://earthquake.usgs.gov/earthquakes/feed/v1.0/detail/uw60561592.geojson
>   felt (String) = (null)
>   cdi (String) = (null)
>   mmi (String) = (null)
>   alert (String) = (null)
>   status (String) = REVIEWED
>   tsunami (String) = (null)
>   sig (Integer) = 44
>   net (String) = uw
>   code (String) = 60561592
>   ids (String) = ,uw60561592,
>   sources (String) = ,uw,
>   types (String) = ,cap,general-link,geoserve,nearby-cities,origin,
>   nst (Integer) = (null)
>   dmin (Real) = 0.24254513
>   rms (Real) = 0.24
>   gap (Real) = 118.8
>   magType (String) = Md
>   type (String) = quarry
>   POINT (-122.7927 43.7262 0)
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Try the cast operator in ogr sql:

kyle@kyle-workstation:~$ ogrinfo -sql 'select *, cast(time as
character(0)),cast(updated as character(0)) from OGRGeoJSON'
/vsicurl/http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_day.geojson

...


OGRFeature(OGRGeoJSON):185
  mag (Real) = 2.4
  place (String) = 29km N of Brenas, Puerto Rico
  time (Integer) = 905049680
  updated (Integer) = 908474945
  tz (Integer) = -240
  url (String) = http://earthquake.usgs.gov/earthquakes/eventpage/pr13212004
  detail (String) =
http://earthquake.usgs.gov/earthquakes/feed/v1.0/detail/pr13212004.geojson
  felt (String) = (null)
  cdi (String) = (null)
  mmi (String) = (null)
  alert (String) = (null)
  status (String) = REVIEWED
  tsunami (String) = (null)
  sig (Integer) = 89
  net (String) = pr
  code (String) = 13212004
  ids (String) = ,pr13212004,
  sources (String) = ,pr,
  types (String) = ,cap,geoserve,nearby-cities,origin,tectonic-summary,
  nst (String) = 13
  dmin (Real) = 0.30722383
  rms (Real) = 0.27
  gap (Real) = 219.6
  magType (String) = Md
  type (String) = earthquake
  time (String) = 905049680
  updated (String) = 908474945
  POINT (-66.3495 18.7346 29)

note the values at the bottom, time and update as (String).  You could
write the entire field list in  the sql and substitue time and updated
for the casted values.

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

Re: [gdal-dev] Trouble with GDALAutoCreateWarpedVRT and No data values

[Kyle Shannon]

Jesse,

i believe I've run into this before.  The GDALWarpOptions has a
member, padfDstNoDataReal.  It is an array  of doubles nBands in size.
 Create that, fill it in with your no data values and set the Warp
Option INIT_DEST to NO_DATA:


psWarpOptions = GDALCreateWarpOptions();

int nBandCount = srcDS->GetRasterCount();

psWarpOptions->nBandCount = nBandCount;

psWarpOptions->padfDstNoDataReal =
(double*) CPLMalloc( sizeof( double ) * nBandCount );

   double dfNoData = -.0;

   for( int b = 0;b < srcDS->GetRasterCount();b++ )
   {
psWarpOptions->padfDstNoDataReal[b] = dfNoData;
}

psWarpOptions->papszWarpOptions =
CSLSetNameValue( psWarpOptions->papszWarpOptions,
"INIT_DEST", "NO_DATA" );

wrpDS = (GDALDataset*) GDALAutoCreateWarpedVRT( srcDS, pszSrcWkt,
pszDstWkt,
GRA_NearestNeighbour,
1.0, psWarpOptions );

...

That seemed to work for me, hopefully it puts you on the right track.

kss

On Mon, Jun 10, 2013 at 6:17 PM, Jesse Crocker  wrote:
> Hello List,
> Im having some trouble with the C api, that I assume is do my failure to 
> understand some part of it.
> What I'm trying to do: Load a BSB raster file, apply a cutline to the file, 
> and warp it into a north-up projection.  Im doing additional transformations 
> to it after that, but right now I'm stuck trying to get areas outside of the 
> cutline to be transparent instead of black.
>
> An abbreviated version of what I'm doing now:
>
> sourceDataset = GDALOpen(imageFilePath.UTF8String, GA_ReadOnly );
>   GDALWarpOptions *warpOptions = GDALCreateWarpOptions();
>   OGRGeometryH clipGeometry;
> OGRErr polyStatus = OGR_G_CreateFromWkt(&pszWkt, spatialRef, 
> &clipGeometry);
> if(polyStatus == CE_None) {
>   warpOptions->hCutline = clipGeometry;
> }
>   warpedDataset = GDALAutoCreateWarpedVRT(sourceDataset,
>   NULL,
>   NULL,
>   GRA_NearestNeighbour,
>   0.0,
>   warpOptions);
>
> The source data does not have a no data value, i've tried setting one and 
> adding an entry to the color palette before calling GDALAutoCreateWarpedVRT, 
> and settings the same value in the VRT but that had no effect.
>
> Any suggestions for the right way to do this?  Am I just setting the no_data 
> value incorrectly, or is this a situation that requires a mask band?  And if 
> it does require a mask band is there an easy way to create that from a 
> cutline?
>
> Thanks,
> Jesse
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.10 JP2000 Problem/Crash

[Kyle Shannon]

Dennis,
I believe you can use Even's GDAL API Proxy to avoid crashes in third
party libraries.  See:

http://trac.osgeo.org/gdal/ticket/4979

for more info.

kss

On Wed, May 22, 2013 at 11:22 AM, Frank Warmerdam  wrote:
> Dennis,
>
> Ah.  In my experience the ECW SDK 3.3 JPEG2000 support is buggy and I was
> never really able to trace down the issues.  I would encourage you to
> consider alternatives - one possibility is the MrSID SDK's JPEG2000 support.
> If Tamas's build includes MrSID support then all you need to do is set the
> GDAL_SKIP environment variable to JP2ECW which would make GDAL skip the ECW
> based driver.   If Tamas hasn't built with MrSID then it falls to you to
> build GDAL which can be somewhat complicated.
>
> Best regards,
> Frank
>
>
>
> On Wed, May 22, 2013 at 9:42 AM, Dennis Gocke  wrote:
>>
>> I'm using the stable 1.10 build from Tamas' site.
>>
>> GDALIdentifyDriver on the file reports: "ERDAS JPEG2000 (SDK 3.x)"
>>
>> When trying to open the file I get an AccessViolationException.
>>
>> Cheers,
>> Dennis
>>
>>
>> On Wed, May 22, 2013 at 3:35 PM, Frank Warmerdam 
>> wrote:
>>>
>>> Dennis,
>>>
>>> There are several jpeg2000 drivers potentially available for gdal.  Do
>>> you know which you are using?
>>>
>>> Best regards,
>>>
>>> On May 22, 2013 5:20 AM, "Dennis Gocke"  wrote:

 Hi,

 I’ve encountered a problem with Pleiades JP2 files from Astrium, GDAL
 crashes when opening the file.

 You should be able to reproduce the the crash by downloading a sample
 dataset from their page.

 http://www.astrium-geo.com/en/23-sample-imagery

 Optical Imagery->Pleiades->Pleiades Primary Product – Bundle
 You have to fill out the form and will then receive a download link via
 email.

 The crash happens with the file
 FCGC600031035/IMG_PHR1A_MS_002/IMG_PHR1A_MS_201202250025599_SEN_PRG_FC_5847-002_R1C1.JP2

 And I have other JP2 Pleiades files where it happens too, so it’s not
 related to this single file. Both ERDAS and ArcGIS are able to open the
 file.

 If it’s not possible to open the files with GDAL, an appropriate error
 message instead of a crash would be good.

 Thanks for looking into it.
 Cheers,
 Dennis

 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>
>
>
> --
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] import error on fedora?

[Kyle Shannon]

Not a fedora guy, but you probably need the gdal-python package, try
installing python-gdal or gdal-python using yum.

kss

On Tue, Mar 26, 2013 at 11:18 AM, Chao YUE  wrote:
> Dear all,
>
> I use "yum install gdal"  to install gdal on fedora 16,
> I can see all following commands in the terminal:
>
> ychao@lsce3139:~$ gdal
> gdaladdogdal_contourgdalenhance gdalinfo
> gdal_rasterize  gdaltransform   gdalwarp
> gdalbuildvrtgdaldem gdal_grid   gdalmanage  gdaltindex
> gdal_translate
>
> However when I tried to import gdal, I get import error:
>
> In [1]: import gdal
> ---
> ImportError   Traceback (most recent call last)
>  in ()
> > 1 import gdal
>
> ImportError: No module named gdal
>
> In [2]: from osgeo import gdal
> ---
> ImportError   Traceback (most recent call last)
>  in ()
> > 1 from osgeo import gdal
>
> ImportError: No module named osgeo
>
> so what's going on here? thanks for any response.
>
> best regards,
>
> chao
> --
> ***
> Chao YUE
> Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> UMR 1572 CEA-CNRS-UVSQ
> Batiment 712 - Pe 119
> 91191 GIF Sur YVETTE Cedex
> Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
> 
>
> ___
> 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] ogr utilities -dsco

[Kyle Shannon]

Use one -dsco flag for each option:

ogr2ogr -f KML impaired_streams_2010.kml impaired_2010_streams.shp
-dsco NameField=AUID -dsco DescriptionField=REACH_DESC

On Tue, Feb 19, 2013 at 2:26 PM, David Fawcett  wrote:
> OK GDAL Devs, I give up.
>
> If I want to specify multiple -dsco key:value with OGR, what is the syntax?
>
> This works for one attribute:
>
> R:\mpca>ogr2ogr -f "KML" impaired_streams_2010.kml impaired_2010_streams.shp
> -ds
> co NameField=AUID
>
> But none of these work for two attributes:
>
> R:\mpca>ogr2ogr -f "KML" test.kml impaired_2010_streams.shp -dsco
> NameField=AUID,DescriptionField=REACH_DESC
>
> R:\mpca>ogr2ogr -f "KML" test2.kml impaired_2010_streams.shp -dsco
> NameField=AUID DescriptionField=REACH_DESC
> FAILURE: Couldn't fetch requested layer 'DescriptionField=REACH_DESC'!
>
> R:\mpca>ogr2ogr -f "KML" test2.kml impaired_2010_streams.shp -dsco
> "NameField=AUID DescriptionField=REACH_DESC"
>
> R:\mpca>ogr2ogr -f "KML" test3.kml impaired_2010_streams.shp -dsco
> NameField=AUID -dsco DescriptionField=REACH_DESC
>
> R:\mpca>ogr2ogr -f "KML" test4.kml impaired_2010_streams.shp -dsco
> "NameField=AUID,DescriptionField=REACH_DESC"
>
> Thanks,
>
> David.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal 1.10 & osgeo4w

[Kyle Shannon]

Even, the Roadmap page in the wiki shows the end of the year, I
imagine that is where the date came from.

kss

On Fri, Dec 28, 2012 at 3:41 PM, image  wrote:
> Hello,
>
> 1/I thought that gdal would released as stable version 2012/12/31 because i
> saw this information of the bottom of the following forum :
>
> http://libregis.org/2012/08/25/updating-gdal-postgis-raster-driver/
>
> 2/Would it be possible to select gdal 1.10 beta via osgeo4w soon (during
> January)?
>
>
> Regards.
>
> Laurent Celati.
>
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/gdal-1-10-osgeo4w-tp5024954p5024958.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SQLite Driver and non-spatial tables

[Kyle Shannon]

For the record, in case anyone is interested, it appears setting
SQLITE_LIST_ALL_TABLES=YES appears to allow me access to non-spatial
tables.  I didn't find any documentation on the format page though.

On Tue, Nov 13, 2012 at 1:44 PM, Kyle Shannon  wrote:

> I have a Spatialite enabled SQLite file with both spatial and non-spatial
> tables.  Since my database has a table called geometry_columns, all
> non-spatial tables are not loaded as layers.  If I don't have a
> geometry_columns OGR attempts to load geometry from all the tables, but
> still loads non-spatial tables.  Is that correct?  The behavior doesn't
> seem consistent in the two cases.  I just want to make sure I understand
> the driver's behavior.
>
> kss
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] SQLite Driver and non-spatial tables

[Kyle Shannon]

I have a Spatialite enabled SQLite file with both spatial and non-spatial  
tables.  Since my database has a table called geometry_columns, all  
non-spatial tables are not loaded as layers.  If I don't have a  
geometry_columns OGR attempts to load geometry from all the tables, but  
still loads non-spatial tables.  Is that correct?  The behavior doesn't  
seem consistent in the two cases.  I just want to make sure I understand  
the driver's behavior.


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

Re: [gdal-dev] trying to fetch the data from raster and assign it to the polygon attribute

[Kyle Shannon]

You can specify the fieldname after the layername, see the documentation:

http://gdal.org/gdal_polygonize.html

gdal_polygonize.py [-8] [-nomask] [-mask filename] raster_file [-b band]
[-q] [-f ogr_format] out_file [layer] [fieldname]

kss

On Mon, Oct 29, 2012 at 4:10 PM, Smaran Harihar wrote:

> Hi,
>
> I am a newbie in GDAL and I recently used gdal_polygonize to convert a
> raster (Tiff) to polygon. The problem is that I wish to also assign the
> pixel values to the attribute table of the polygon.
>
> Is it possible? When I converted the raster into polygon, I was only able
> to see DN as another field and it does not have the desired value as
> displayed in the pixel value.
>
> --
> Thanks & Regards
> Smaran Harihar
>
>
> ___
> 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] Removing Nodata pixels from raster

[Kyle Shannon]

Katrin,
Do you know where you valid pixels are in the image?  If so, gdal_translate
with -srcwin would work:

kyle@ubuntu:~$ gdal_translate -srcwin xoff yoff 60 100 in.tif out.tif

where xoff, yoff are the number of pixels from the image origin that your
valid region begins(pixels, lines).  See
http://gdal.org/gdal_translate.htmlfor more info.



On Thu, Oct 25, 2012 at 8:05 AM, katrin eggert
wrote:

> Greetings
> I have a Geotif with only one Layer with a size of 6000x5000 but from
> which I only have a square of 60x100 with bvalid pixels. the remaining are
> NOdata. The problem is that this Geotiff is a big file 90MB and without
> these NoData values I would have a much smaller raster.
> How can I generate a new Geotiff without these noValid values and with
> extent adjusted to the valid pixels?
> Thank you
> Regards,
> Katrin E.
>
> ___
> 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] GEOS Ver 3.3.5 and GDAL Ver 1.91

[Kyle Shannon]

Martin,
Did you by chance use cmake to build geos?  I built 1.9.1 against geos
3.3.5, but used cmake when building geos.  It appears the output files are
named differently when cmake is used.  If you did use cmake, then it looks
like you need to specify:

GEOS_LIB = $(GEOS_DIR)/lib/geos_c.lib

if normal nmake was used without cmake generated files then it appears
geos_c_i.lib is the proper lib.

kss


On Wed, Sep 5, 2012 at 2:04 PM, Martin Chapman  wrote:

> I love this user group.  Thanks Joaquim!
>
>
>
> Best regards,
>
> Martin
>
>
>
>
>
> *From:* Joaquim Luis [mailto:jl...@ualg.pt]
> *Sent:* Wednesday, September 05, 2012 2:03 PM
> *To:* Martin Chapman
> *Cc:* gdal-dev@lists.osgeo.org
>
> *Subject:* Re: [gdal-dev] GEOS Ver 3.3.5 and GDAL Ver 1.91
>
>
>
> On 05-09-2012 20:33, Martin Chapman wrote:
>
> All,
>
>
>
> I am trying to compile GDAL 1.91 with GEOS version 3.3.5 on windows 7 x64
> and the nmake.opt file does not seem to match the directory structure of
> the latest GEOS.  Am I missing something simple?  Any help is much
> appreciated.
>
>
>
> Muchos gracias,
>
>
>
> Martin
>
>
>
>
> Martin,
>
> I have built GDAL trunk recently with GEOS 3.3.5 with no problems, but I
> use a name coding for the dir where the libs are stored.
> For example, for GEOS I have in my nmake.local
>
> GEOS_DIR = C:\programs\compa_libs\geos-3.3.5\compileds
> GEOS_CFLAGS = -I$(GEOS_DIR)/$(LIB_CC)/include -DHAVE_GEOS
> GEOS_LIB = $(GEOS_DIR)/$(LIB_CC)/lib/geos_c_i.lib
>
> where $(LIB_CC) translates to
> VC10_64 or VC10_32
> depending whether I'm building 32 or 64 bits versions
> Off course, when I compiled GEOS, I stored the libs in
> $(GEOS_DIR)/$(LIB_CC)/lib and the headers in $(GEOS_DIR)/$(LIB_CC)/include
>
> Joaquim
>
>
> ___
> 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] Converting a .dat(X-Plane) file to a shapefile

[Kyle Shannon]

What are the errors?

On Thu, Aug 23, 2012 at 12:27 PM, Peter Mallen
wrote:

> Hi Everyone,
>
> ** **
>
> I am attempting to convert data from a .dat file (X-Plane data) into
> shapefiles.  Below is the ogr2ogr command I found online, but this always
> gives errors:
>
> ** **
>
> ogr2ogr apt_shapes apt.dat
>
> ** **
>
> If anyone has any experience or tips on how to correctly do this I would
> really appreciate it.
>
> ** **
>
> ** **
>
> Thank You,
>
> ** **
>
> ** **
>
> Peter Mallen
>
> ** **
>
> ___
> 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] Units of dimension variable in NetCDF is 'km'

[Kyle Shannon]

What version are you using?  I seem to remember something like this in a
ticket I filed.  I thought it was fixed in 1.9.1.

kss

On Tue, Aug 7, 2012 at 5:38 AM, Etienne Tourigny wrote:

> Hi,
>
> km units are supposed to work...
>
> Here is the code where "km" units are detected, which set the WKT
> units to 1000m.
>
> /* add units to PROJCS */
> if ( pszUnits != NULL && ! EQUAL(pszUnits,"") ) {
> if ( EQUAL(pszUnits,"m") ) {
> oSRS.SetLinearUnits( CF_UNITS_M, 1.0 );
> oSRS.SetAuthority( "PROJCS|UNIT", "EPSG", 9001 );
> }
> else if ( EQUAL(pszUnits,"km") ) {
> oSRS.SetLinearUnits( CF_UNITS_M, 1000.0 );
> oSRS.SetAuthority( "PROJCS|UNIT", "EPSG", 9001 );
> }
>
> What does the wkt actually look like?
>
> Also running gdalinfo --debug ON  can give a few hints.
>
> It would be good for you to send me a link to the file or attach it to
> a bug report (add me as cc).
>
> Etienne
>
> On Tue, Aug 7, 2012 at 6:10 AM, Anton Korosov 
> wrote:
> > Dear Etienne,
> >
> > I faced the following problem with the NetCDF driver:
> > Units of the dimension variables are 'km' and values in the SRS are in
> > meters, of course (e.g. Earth radius). Hence the calculated GeoTransform
> is
> > 1000 times less than should be and the calculate latlons are incorrect.
> > However 'units' attribute is given, besides AFAIK CF-conventions allow to
> > have 'k' (kilo) preceding 'm' (meters) in the units.
> >
> > Can you please give me a hint where to fix that in the driver so that it
> can
> > adequately interpret units of the dimensions?
> >
> > With best regards!
> > Anton
> >
> > ___
> > 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

Re: [gdal-dev] convert .tif/.tfwx/.aux.xml to a geotiff?

[Kyle Shannon]

Martin, see the -a_ullr option here:

http://gdal.org/gdal_translate.html

(or gdal_translate --help).  The option allows you to set the upper left
and lower right corners.  You probably want to set the spatial reference as
well with -a_srs:

gdal_translate -a_ullr -117.0 45.0 -116.0 44.0 -a_srs epsg:4326 in.tif
out.tif

kss

On Sat, Jun 16, 2012 at 1:46 AM, Florent JITIAUX  wrote:

> Hi Martin,
>
> if you georeference your images manually you can use gdalwarp to do it or
> set coordinates of images with gdal_translate.
>
> Florent
>
> 2012/6/15 Martin Ouellet 
>
>> Hi,
>>
>> I manually georeferenced some images in ArcGIS and at the end, I got a
>> .tfwx file and a aux.xml.
>>
>> I wish to convert them into geotiff with the georeferenced info in the
>> header:
>>
>> 1) I've renamed the .tfwx into .tfw and run a gdal_translate.  The
>> command didn't failed but the resulting image is not georeferenced at all
>>
>> Is it possible to do that perhaps using the info in the .aux.xml file?
>>
>> Thanks,
>>
>> MartinO
>>
>> ___
>> 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

Re: [gdal-dev] Reading a NetCDF file with python (not recognised as a supported dataset name

[Kyle Shannon]

Command line works fine.  I didn't have time to test well though.  I will
try to get on a windows machine and download tamas package and give it
another shot.

kss

On Fri, Jun 8, 2012 at 9:31 AM, Etienne Tourigny wrote:

> with commandline and/or python?
>
> I can do both fine using gdal-1.9.1 from osgeo4w (32bit), haven't
> tried Tamas' build yet
>
> On Fri, Jun 8, 2012 at 12:08 PM, Kyle Shannon 
> wrote:
> > Etienne, Rutger,
> > I can reproduce on windows with 32 bit 1.9 branch and 1.9.1 from Tamas'
> site.  In fact, I couldn't open any datasets.
> >
> > kss
> >
> > -Original Message-
> > From: gdal-dev-boun...@lists.osgeo.org [mailto:
> gdal-dev-boun...@lists.osgeo.org] On Behalf Of Etienne Tourigny
> > Sent: Friday, June 08, 2012 9:10 AM
> > To: Rutger
> > Cc: gdal-dev@lists.osgeo.org
> > Subject: Re: [gdal-dev] Reading a NetCDF file with python (not
> recognised as a supported dataset name
> >
> > Rutger,
> >
> > There should not be any difference when using the python bindings. If
> gdalinfo can read it the python bindings should also.
> >
> > I cannot reproduce your problem using gdal-1.9.1 under linux.  Which
> exact version are you using?
> >
> > By the way, the vrtfile in unnecessary, because GDAL's Open accepts the
> NETCDF:file.nc:variable syntax.
> >
> > Try adding this to your script and send the result back here
> gdal.SetConfigOption( 'CPL_DEBUG', 'ON' )
> >
> > also try gdal_info.exe -stats
> >
> NETCDF:LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.nc:soil_moisture_x
> > this actually reads the file contents and not just the metadata. If it
> fails then something is wrong.
> >
> > you should see
> >STATISTICS_MAXIMUM=99
> >STATISTICS_MEAN=21.746993313128
> >STATISTICS_MINIMUM=0
> >STATISTICS_STDDEV=20.100893016522
> >
> >
> > Etienne
> >
> > On Fri, Jun 8, 2012 at 9:00 AM, Rutger  wrote:
> >> Dear list,
> >>
> >> I am trying to open a NetCDF file with the Python bindings. My GDAL
> >> 1.9 build (Win32 from Tamas) shows the NetCDF driver when i run
> >> "gdalinfo --formats", so it should be possible.
> >>
> >> When using the pre-build command-line utilities all works well. But
> >> when i move to Python i get the message:
> >> /" ... does not exist in the file system, and is not recognised as a
> >> supported dataset name."/ I dont have the slightest clue about what
> >> i'm doing wrong.
> >>
> >> I have simplified the problem to 3 steps:
> >> 1. Use gdal_translate to select a subdataset and output to VRT 2. Read
> >> the VRT in Python with gdal.Open() 3. Use gdal_translate to convert
> >> the VRT to a Geotiff
> >>
> >> Step 1 & 3 work well, but 2 fails. Is there some limitation of the
> >> Python bindings regarding NetCDF? The script runs fine if i replace
> >> the NetCDF with a Geotiff file.
> >>
> >> Any help would be appreciated.
> >>
> >> An example NetCDF i used can be found at:
> >> ftp://hydro1.sci.gsfc.nasa.gov/data/s4pa/WAOB/LPRM_TMI_DY_SOILM3.001/2
> >> 012/05/
> >> ftp://hydro1.sci.gsfc.nasa.gov/data/s4pa/WAOB/LPRM_TMI_DY_SOILM3.001/2
> >> 012/05/
> >>
> >> Below is the Python script i have used for exploring the issue:
> >>
> >> import os
> >> try:
> >>from osgeo import gdal
> >> except ImportError:
> >>import gdal
> >>
> >> netcdffile =
> >>
> "NETCDF:LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.nc:soil_moisture_x"
> >> vrtfile = "LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.vrt"
> >> tiffile = "LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.tif"
> >>
> >> # 1: convert the netcdf to vrt externally (works well)
> >> os.system('gdal_translate -of "VRT" ' + netcdffile + ' ' + vrtfile)
> >>
> >> # 2: try to open the vrt in Python (fails at .ReadAsArray) dsin =
> >> gdal.Open(vrtfile)
> >>
> >> if not dsin is None:
> >>  indata = dsin.ReadAsArray(0, 0, dsin.RasterXSize, dsin.RasterYSize)
> >>
> >> # 3: convert the same vrt to a tif externally (works well)
> >> os.system('gdal_translate ' + vrtfile + ' ' + tiffile)
> >>
> >>
> >> Regards,
> >> Rutger
> >>
> >>
> >> --
> >> View this message in context:
> >> http://osgeo-org.1560.n6.nabble.com/Reading-a-NetCDF-file-with-python-
> >> not-recognised-as-a-supported-dataset-name-tp4979943.html
> >> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> >> ___
> >> gdal-dev mailing list
> >> gdal-dev@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev 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] Reading a NetCDF file with python (not recognised as a supported dataset name

[Kyle Shannon]

Etienne, Rutger,
I can reproduce on windows with 32 bit 1.9 branch and 1.9.1 from Tamas' site.  
In fact, I couldn't open any datasets.

kss

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Etienne Tourigny
Sent: Friday, June 08, 2012 9:10 AM
To: Rutger
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Reading a NetCDF file with python (not recognised as a 
supported dataset name

Rutger,

There should not be any difference when using the python bindings. If gdalinfo 
can read it the python bindings should also.

I cannot reproduce your problem using gdal-1.9.1 under linux.  Which exact 
version are you using?

By the way, the vrtfile in unnecessary, because GDAL's Open accepts the 
NETCDF:file.nc:variable syntax.

Try adding this to your script and send the result back here 
gdal.SetConfigOption( 'CPL_DEBUG', 'ON' )

also try gdal_info.exe -stats
NETCDF:LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.nc:soil_moisture_x
this actually reads the file contents and not just the metadata. If it fails 
then something is wrong.

you should see
STATISTICS_MAXIMUM=99
STATISTICS_MEAN=21.746993313128
STATISTICS_MINIMUM=0
STATISTICS_STDDEV=20.100893016522


Etienne

On Fri, Jun 8, 2012 at 9:00 AM, Rutger  wrote:
> Dear list,
>
> I am trying to open a NetCDF file with the Python bindings. My GDAL 
> 1.9 build (Win32 from Tamas) shows the NetCDF driver when i run 
> "gdalinfo --formats", so it should be possible.
>
> When using the pre-build command-line utilities all works well. But 
> when i move to Python i get the message:
> /" ... does not exist in the file system, and is not recognised as a 
> supported dataset name."/ I dont have the slightest clue about what 
> i'm doing wrong.
>
> I have simplified the problem to 3 steps:
> 1. Use gdal_translate to select a subdataset and output to VRT 2. Read 
> the VRT in Python with gdal.Open() 3. Use gdal_translate to convert 
> the VRT to a Geotiff
>
> Step 1 & 3 work well, but 2 fails. Is there some limitation of the 
> Python bindings regarding NetCDF? The script runs fine if i replace 
> the NetCDF with a Geotiff file.
>
> Any help would be appreciated.
>
> An example NetCDF i used can be found at:
> ftp://hydro1.sci.gsfc.nasa.gov/data/s4pa/WAOB/LPRM_TMI_DY_SOILM3.001/2
> 012/05/ 
> ftp://hydro1.sci.gsfc.nasa.gov/data/s4pa/WAOB/LPRM_TMI_DY_SOILM3.001/2
> 012/05/
>
> Below is the Python script i have used for exploring the issue:
>
> import os
> try:
>    from osgeo import gdal
> except ImportError:
>    import gdal
>
> netcdffile =
> "NETCDF:LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.nc:soil_moisture_x"
> vrtfile = "LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.vrt"
> tiffile = "LPRM-TMI_L3_DY_SOILM3_V001-20120411T144114Z_20120102.tif"
>
> # 1: convert the netcdf to vrt externally (works well) 
> os.system('gdal_translate -of "VRT" ' + netcdffile + ' ' + vrtfile)
>
> # 2: try to open the vrt in Python (fails at .ReadAsArray) dsin = 
> gdal.Open(vrtfile)
>
> if not dsin is None:
>  indata = dsin.ReadAsArray(0, 0, dsin.RasterXSize, dsin.RasterYSize)
>
> # 3: convert the same vrt to a tif externally (works well) 
> os.system('gdal_translate ' + vrtfile + ' ' + tiffile)
>
>
> Regards,
> Rutger
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.n6.nabble.com/Reading-a-NetCDF-file-with-python-
> not-recognised-as-a-supported-dataset-name-tp4979943.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] DODS Driver issue

[Kyle Shannon]

I am messing around with some opendap weather data and tinkering with gdal.
 Does anyone have any test data/links I can use?  I used gdalinfo to look
at this data:

http://nomads.ncdc.noaa.gov/dods/NCEP_NAM/subsets/nam_218_winds.dds

using:

kyle@ubuntu:~/Desktop$ gdalinfo
http://nomads.ncdc.noaa.gov/dods/NCEP_NAM/subsets/nam_218_winds?ugrd10m[0][y][x]
Driver: DODS/DAP 3.x servers
Files: none associated
Size is 1038, 500
Coordinate System is `'
Origin = (-153.0500011,11.949)
Pixel Size = (0.100,0.100)
Corner Coordinates:
Upper Left (-153.050, 11.950)
Lower Left (-153.050, 61.950)
Upper Right ( -49.250, 11.950)
Lower Right ( -49.250, 61.950)
Center (-101.150, 36.950)
Band 1 Block=512x128 Type=Float32, ColorInterp=Undefined
NoData Value=9.999e+20
Overviews: 519x250, 259x125, 129x62

and I noticed the origin y values are inverted.  The image 'shows' up in
the right place because the y pixel size is positive, but
adfGeoTransform[3] is wrong.  I am also not getting any data back (all
nodata) but I am not sure if that is me, or the provider.  I am looking for
a link to test the dods driver and see if this is always the case, or if
the data served by nomads is an exception.  Thanks.

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

Re: [gdal-dev] gdalwarp question

[Kyle Shannon]

Billy,
Yes, gdalwarp will use the srs from the file if one is not specified,
providing it is valid.

kss

On Wed, May 16, 2012 at 8:13 AM, Billy Newman  wrote:

> If I do not provide a source spatial reference to gdalwarp will the
> information in the geotiff be used instead?  ie. gdalwarp -t_srs
> 'EPSG:4326' input.tif output.tif?
>
> I do not have a real example because I do not have the file I am working
> with on this computer.  But an example gdalinfo would be:
>
> PROJCS["NAD27 / UTM zone 11N",
> GEOGCS["NAD27",
> DATUM["North_American_Datum_1927",
> SPHEROID["Clarke 1866",6378206.4,294.978698213901]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",0],
> PARAMETER["central_meridian",-117],
> PARAMETER["scale_factor",0.9996],
> PARAMETER["false_easting",50],
> PARAMETER["false_northing",0],
> UNIT["metre",1]]
>
> So would my above example work when trying to convert this projection to
> EPSG:4326, or do I need to specify the source spatial reference and/or
> other parameters.
>
> Thanks
> Billy
>
> ___
> gdal-dev mailing list
> gdal-dev@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: gdal_translate waits at the end of operation

[Kyle Shannon]

Kaarigar,

You can pick up new binaries tomorrow at:
gisinternals.com/sdk
I don't know at exactly what time the packages get built, but they are built 
daily.

kss

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Thursday, May 10, 2012 11:17 AM
To: kaari...@gmail.com
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Re: gdal_translate waits at the end of operation

On Thu, May 10, 2012 at 9:59 AM, Karu Kaarigar  wrote:
> Thanks, Frank. I am not familiar with the gdal development at all. But 
> I think replacing the driver binary with this new one wit your change 
> should fix the behavior locally for me?
>
> Kaarigar
> 

Kaarigar,

The XYZ driver is not built as a distinct driver.  It is just built into the 
main GDAL .so/.dll.  If you are using pre-built binaries i may be hard to 
incorporate the change.  If you are building from source, just replace the 
xyzdataset.cpp file.

In any event, you can just run with the gdal_translate you have now.  It will 
just be inefficient.

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 Software Developer 
___
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: gdal_translate waits at the end of operation

[Kyle Shannon]

More questions?  Can you convert one image into an xyz?  It sounds like you
can.  Are there no errors or warnings?

On Wed, May 9, 2012 at 5:34 PM, kaarigar  wrote:

> Here's the command line:
>
> gdal_translate -ot Float32 -of XYZ -co "COLUMN_SEPARATOR=," n40w124.tif
> n40w124.xyz
>
>
> Kyle Shannon-3 wrote
> >
> > Sounds like your doing something wrong, it shouldn't hang.  Can you share
> > your command line args or a snippet of your batch file?
> >
> > kss
> >
>
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/gdal-translate-waits-at-the-end-of-operation-tp4964258p4964307.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_translate waits at the end of operation

[Kyle Shannon]

Sounds like your doing something wrong, it shouldn't hang.  Can you share
your command line args or a snippet of your batch file?

kss

On Wed, May 9, 2012 at 5:06 PM, kaarigar  wrote:

> I hope this is the right forum to pose this question to.
>
> I am using gdal_translate on Windows 7 64 bit to batch convert a lot of
> GeoTIFF files to XYZ ASCII. (I got gdal_translate when I installed
> Geoinformatica tools, based on GDAL version 1.9Dev). However, at the end of
> each conversion gdal_translate just waits - I have to press CTRL-C to wake
> it up so that the batch file can continue to process the next command. This
> very much defeats the purpose of the command line program - because it
> forces the user to be around to press key. Is this expected - or am I
> missing something here? Any help is very much appreciated. Thanks!
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/gdal-translate-waits-at-the-end-of-operation-tp4964258.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] vsicurl

[Kyle Shannon]

Thanks.

kss

On Fri, Mar 23, 2012 at 15:06, Frank Warmerdam  wrote:

> On Fri, Mar 23, 2012 at 1:57 PM, Kyle Shannon  wrote:
> > Can the VSI*L support be added to drivers that use a third party API
> similar
> > to the way it is done in the geotiff driver?  Would that be a good
> reference
> > to add support to other drivers?
>
> Kyle,
>
> There are a number of external libraries where we are able to hook
> the IO functions for that sublibrary and route things through VSI*L.
> The GeotTIFF, MrSID, ECW and Shapefile drivers are all examples
> of this I believe.  How it exactly works depends on the IO hooking
> mechanisms provided by the external library.  Some provide no
> usable mechanism.
>
> Best regards,
> Frank
>
> > On Fri, Mar 23, 2012 at 14:33, Frank Warmerdam 
> wrote:
> >>
> >> Kyle,
> >>
> >> You need to have built GDAL with curl support and the drivers has do
> >> do all file access through VSI*L functions.
> >>
> >> Best regards,
> >> Frank
> >>
> >> On Fri, Mar 23, 2012 at 1:31 PM, Kyle Shannon  wrote:
> >> > What are the requirements for using the vsicurl handler for accessing
> >> > files?
> >> > Do drivers have to implement anything special do have curl support?
> >> >
> >> > ___
> >> > gdal-dev mailing list
> >> > gdal-dev@lists.osgeo.org
> >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >>
> >>
> >> --
> >>
> >>
> ---+--
> >> I set the clouds in motion - turn up   | Frank Warmerdam,
> >> warmer...@pobox.com
> >> light and sound - activate the windows | http://pobox.com/~warmerdam
> >> and watch the world go round - Rush| Geospatial Software Developer
> >
> >
>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] vsicurl

[Kyle Shannon]

Etienne,
I saw that under the vsizip section, but it wasn't clear to me if the same
constraints were on the vsicurl handler.

kss

On Fri, Mar 23, 2012 at 14:56, Etienne Tourigny wrote:

> Kyle,
>
> the driver(s) probably need to support "large file API"
>
> From http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip
> The fact that this new capability is implemented as virtual file
> systems imply that it will only work for GDAL drivers supporting the
> "large file API". A non-exhaustive list of such drivers is :
> The full list can be obtained by looking at the driver marked with 'v'
> when running 'gdalinfo --formats'
>
> for example, netcdf and hdf do not support /vsigzip (and probably not
> /vsicurl)
>
> Etienne
>
>
> On Fri, Mar 23, 2012 at 5:31 PM, Kyle Shannon  wrote:
> > What are the requirements for using the vsicurl handler for accessing
> files?
> > Do drivers have to implement anything special do have curl support?
> >
> > ___
> > 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] vsicurl

[Kyle Shannon]

Can the VSI*L support be added to drivers that use a third party API
similar to the way it is done in the geotiff driver?  Would that be a good
reference to add support to other drivers?

On Fri, Mar 23, 2012 at 14:33, Frank Warmerdam  wrote:

> Kyle,
>
> You need to have built GDAL with curl support and the drivers has do
> do all file access through VSI*L functions.
>
> Best regards,
> Frank
>
> On Fri, Mar 23, 2012 at 1:31 PM, Kyle Shannon  wrote:
> > What are the requirements for using the vsicurl handler for accessing
> files?
> > Do drivers have to implement anything special do have curl support?
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] vsicurl

[Kyle Shannon]

What are the requirements for using the vsicurl handler for accessing
files? Do drivers have to implement anything special do have curl support?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Motion: Contract Chaitanya as GDAL Maintainer

[Kyle Shannon]

I don't really count, but Chaitanya is very helpful.

+1

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Thursday, March 22, 2012 2:50 PM
To: gdal dev
Subject: [gdal-dev] Motion: Contract Chaitanya as GDAL Maintainer

Motion: Frank Warmerdam is authorized to negotiate a paid maintainer contract 
with Chaitanya Kumar CH for up to $5200 USD at $13USD/hr over five months, and 
would be acting as supervisor, operating under the terms of RFC 9 (GDAL Paid 
Maintainer Guidelines).

---

PSC Members,

Chaitanya has indicated he is available again to do GDAL maintenance and I 
think it would be advantageous to have his support.  He is a solid developer, 
and has continued to be active in the GDAL community since his last work as 
GDAL maintainer.

In addition to general bug fixing I am also hoping to have him do some work on 
packaging of GDAL and dependencies for things like OSGeo4W, and 
DebianGIS/UbuntuGIS/LiveDVD.

I'll start things by voting:

+1 Frank

-- 
---+
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com 
light and sound - activate the windows | http://pobox.com/~warmerdam and watch 
the world go round - Rush    | Geospatial Software Developer 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Error when compiling GDAL trunk

[Kyle Shannon]

Jean Claude,
I have a gdal test machine running Ubuntu 11.10.  I build zlib 1.2.6 and built 
and linked gdal against it no problems.  Probably doesn't help much.

kss

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jean-Claude Repetto
Sent: Thursday, March 22, 2012 8:25 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Error when compiling GDAL trunk

Le 22/03/2012 14:53, Even Rouault a écrit :
> Selon Jean-Claude Repetto:
>
>> Hello,
>>
>> Since a few weeks, I have a problem to compile GDAL trunk on one of 
>> my PCs. But it works on others, so I think there is a problem on the PC.
>> This PC runs Linux 32 bits (Gentoo), and gcc version is 4.5.3.
>>
>> The first error occur in this line :
>> typedef voidpf (ZCALLBACK *open_file_func) OF((voidpf opaque, const
>> char* filename, int mode));
>> cpl_minizip_ioapi.h:48:44: error: expected initializer before 'OF'
>>
>> Any idea of what may be wrong on my PC ?
>>
>
> I see OF is a macro defined in zconf.h of zlib. At least in zlib 
> 1.2.3, perhaps an issue with newer zlib ?

You are right : If I install zlib-1.2.6 in place of zlib-1.2.5, the error 
appears. At this time, I'm not sure if it is a problem with zlib or with 
Gentoo, I'll try to investigate.

If you have enough time, could you try zlib-1.2.6 ?

Thanks,
Jean-Claude

___
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] gdalwarp eats scale and offset

[Kyle Shannon]

If I have a dataset with a scale and offset:

kyle@ubuntu:~/Desktop$ gdalinfo test.tif
 Driver: GTiff/GeoTIFF
Files: test.tif
Size is 738, 919
Coordinate System is:
PROJCS["WGS 84 / UTM zone 12N",
...
Origin = (279635.000,4878315.000)
Pixel Size = (30.000,-30.000)
Metadata:
AREA_OR_POINT=Point
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 279635.000, 4878315.000) (113d44'58.90"W, 44d 1'29.65"N)
Lower Left ( 279635.000, 4850745.000) (113d44'17.87"W, 43d46'37.04"N)
Upper Right ( 301775.000, 4878315.000) (113d28'25.33"W, 44d 1'52.37"N)
Lower Right ( 301775.000, 4850745.000) (113d27'48.41"W, 43d46'59.57"N)
Center ( 290705.000, 4864530.000) (113d36'22.60"W, 43d54'14.96"N)
Band 1 Block=738x1 Type=Float32, ColorInterp=Gray
Offset: 1, Scale:0.1

and I warp the image:

kyle@ubuntu:~/Desktop$ gdalwarp -t_srs epsg:4326 test.tif warp.tif
Creating output file that is 901P x 800L.
Processing input file test.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.

My scale and offset disappear:

kyle@ubuntu:~/Desktop$ gdalinfo warp.tif

Driver: GTiff/GeoTIFF
Files: warp.tif
Size is 901, 800
Coordinate System is:
GEOGCS["WGS 84",
...
Origin = (-113.749693430469137,44.031215259056744)
Pixel Size = (0.000317850797006,-0.000317850797006)
Metadata:
AREA_OR_POINT=Point
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-113.7496934, 44.0312153) (113d44'58.90"W, 44d 1'52.37"N)
Lower Left (-113.7496934, 43.7769346) (113d44'58.90"W, 43d46'36.96"N)
Upper Right (-113.4633099, 44.0312153) (113d27'47.92"W, 44d 1'52.37"N)
Lower Right (-113.4633099, 43.7769346) (113d27'47.92"W, 43d46'36.96"N)
Center (-113.6065016, 43.9040749) (113d36'23.41"W, 43d54'14.67"N)
Band 1 Block=901x2 Type=Float32, ColorInterp=Gray

I couldn't find any docs on this. Is this known and/or expected? I would
think scale and offset would be transferred to the new file.

/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] Re: How to check version of ogr?

[Kyle Shannon]

Hermann,
I noticed this yesterday too, I don't think the version was updated in the 
trunk after the 1.9 branch.

kss


-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Hermann Peifer
Sent: Friday, March 16, 2012 5:25 AM
To: Jean-Claude Repetto
Cc: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Re: How to check version of ogr?

On 16/03/2012 10:20, Jean-Claude Repetto wrote:
> Le 16/03/2012 09:55, Chrishelring a écrit :
>> Hi all,
>>
>> very simple question (atleast I hope so ;). I need to check the 
>> version of the ogr library included in my mapserver configuration, 
>> but cant seem to find a way to do it. If I just enter ogr2ogr ind the 
>> shell no versionnumber is presented.
>
> ogr2ogr --version

This is not always reliable information. In my case, it says:
GDAL 1.9.0, released 2011/12/29

But what I am actually using is GDAL/OGR from trunk, as of today, revision 
24121.

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

RE: [gdal-dev] compiling with FileGeodb API 1.2

[Kyle Shannon]

I didn't reconfigure, just dumped the new libs in place of the old and it 
linked.  I get the same results as you now.

kss

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: Thursday, March 15, 2012 4:39 PM
To: gdal-dev@lists.osgeo.org
Cc: Kyle Shannon; Stefano Iacovella
Subject: Re: [gdal-dev] compiling with FileGeodb API 1.2

Le jeudi 15 mars 2012 23:24:22, Kyle Shannon a écrit :
> Stefano,
> I just built from the trunk with filegdb support and had no issues.  I 
> would make sure the 1.1 version is off your system and not anywhere 
> configure could find it, then try again.

Kyle,

I've just experienced the same issue as Stefano's. I'm not clear why it works 
for you, but ESRI did actually renamed the unix support lib, and GDAL's 
configure needs to be updated. Sigh sigh sigh

Stefano, would you mind opening a ticket about that ?

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

RE: [gdal-dev] compiling with FileGeodb API 1.2

[Kyle Shannon]

Stefano,
I just built from the trunk with filegdb support and had no issues.  I would 
make sure the 1.1 version is off your system and not anywhere configure could 
find it, then try again.

kss

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Stefano Iacovella
Sent: Thursday, March 15, 2012 3:51 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] compiling with FileGeodb API 1.2

Hello all

I downloaded the 1.2 release of ESRI FileGeoDB API to upgrade my gdal 
installation.
Previously I compiled gdal 1.9.0 with 1.1 release of ESRI API.
I'm working on ubuntu server 10.04 32 bit and of course I picked up the 32 bit 
release of the API.
I unpacked the API tarball in /usr/local/FileGDB_API_1_2 and started to 
recompile gdal as:

./configure --with-libtiff=internal --with-python --with-jpeg=internal 
--with-png=internal --with-xerces
--with-fgdb=/usr/local/FileGDB_API_1_2 --with-geos --with-pg --with-ecw=yes 
--with-curl=yes

It didn't complain about anything and terminate configuration step successfully.

Then I run make to start compiling but it stopped with error about 
libfgdblinuxrtl.so being unavailable.

I checked inside API files and found that in 1.1 release the lib folder 
contains this two files:

drwxr-xr-x 2 stefano stefano4096 2011-07-29 21:05 ./
drwxr-xr-x 8 stefano stefano4096 2011-08-03 20:12 ../
-rwxr-xr-x 1 stefano stefano  581396 2011-07-29 21:02 libfgdblinuxrtl.so* 
-rwxr-xr-x 1 stefano stefano 8999007 2011-07-29 21:05 libFileGDBAPI.so*

at release 1.2 the same folder contains:

drwxr-xr-x 2 stefano stefano4096 2012-03-13 22:37 ./
drwxr-xr-x 8 stefano stefano4096 2012-02-28 00:24 ../
-rwxr-xr-x 1 stefano stefano  592995 2012-02-24 00:09 libfgdbunixrtl.so* 
-rwxr-xr-x 1 stefano stefano 9961885 2012-02-24 00:12 libFileGDBAPI.so*

It seems to me that ESRI renamed a library. So I made a link to "create" a old 
named library

sudo ln -s /usr/local/FileGDB_API_1_2/lib/libfgdbunixrtl.so
/usr/local/FileGDB_API_1_2/lib/libfgdblinuxrtl.so

Made it the compilation and installation was successfull.
I successfully tested ogrinfo with the sample FileGeodb at 
http://trac.osgeo.org/gdal/wiki/FileGDB.

I'm not sure the library problem it is dued to somenthing wrong I did.
Is anyone experiencing something similar? Or may be something dirty remained in 
the package of ESRI

Best regards

Stefano


-
41.95581N 12.52854E


http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas
___
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] how should SpatialReference::EPSGTreatsAsLatLong work?

[Kyle Shannon]

Jachym,
Like Etienne said, 3035 is projected.  I believe 4326 is not returning true 
because the OGC (or proj or whatever is the definitive internal format) makes 
no reference to an axis and according to the docs:

'''Note that coordinate systems with an EPSG code and no axis settings will be 
assumed to not be lat/long.'''

kyle@home$ gdalsrsinfo -o proj4 epsg:4326
'+proj=longlat +datum=WGS84 +no_defs '

and wkt:

GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","632
6"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY
["EPSG","4326"]]

My best guess anyway.

kss

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Etienne Tourigny
Sent: Thursday, March 15, 2012 7:26 AM
To: Jachym Cepicky
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] how should SpatialReference::EPSGTreatsAsLatLong work?

The reference for EPSGTreatsAsLatLong  is "This method returns TRUE if EPSG 
feels this geographic coordinate system should be treated as having lat/long 
coordinate ordering."

However, EPSG 3035 is not a geographic coordinate system, but a projected one 
(Lambert Azimuthal Equal Area).

Etienne

On Thu, Mar 15, 2012 at 6:00 AM, Jachym Cepicky  
wrote:
> Hi,
>
> I'm trying to figure out, how OGRSpatialReference::EPSGTreatAsLatLong 
> is supposed to be working -> I'm not able to get any proper result.
>
> I'm playing with the python interface at this place (and assume, C-api 
> would work similar way).
>
> When I create OGRSpatialReference and import it from EPSG with the 
> code 4326, I would say, EPSGTreatAsLatLong should return True:
>
> from osgeo import osr
> sr = osr.SpatialReference()
> sr.ImportFromEPSG(4326)
> sr.EPSGTreatAsLatLong()
> 0
>
> Same applies, when trying the same with e.g. EPSG:3035
>
> sr.ImportFromEPSG(3035)
> sr.EPSGTreatAsLatLong()
> 0
>
> Both do have (accordi ng to http://epsg-registry.org/) north,east axis 
> order, so I would asssume EPSGTreatAsLatLong would return True
>
> Could anybody give me a hint, what am I doing wrong?
>
> Thanks
>
> Jachym
>
>
>
> ___
> 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] vsizip and vrt driver

[Kyle Shannon]

Hello all,
I recently built a VRT from several SRTM tiles that were zipped into
archives:

gdalbuildvrt srtm.vrt /vsizip/srtm_01_02.zip/srtm_01_02.asc
/vsizip/srtm_01_07.zip/srtm_01_07.asc /vsizip/srtm_01_02.zip/srtm_01_12.asc

Everything works fine. I changed the relativeToVRT value to "1" and try to
run gdalinfo from another path and it can't find the files. Am I missing
something? Is it not legal to use vsizip in vrt files? Thanks. Tested on
Linux and Windows.

kss

/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] compiling gdal on Ubuntu via Parallels

[Kyle Shannon]

On newer Ubuntu releases /usr/local/lib is not in the LD_LIBRARY_PATH.  Either 
set it in your login script (export 
LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH or add /usr/local/lib to 
/etc/ld.so.conf 

If you do the latter method, run sudo ldconfig after you are done and it should 
work.

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Stuart Edwards
Sent: Wednesday, February 22, 2012 9:33 AM
To: Even Rouault
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] compiling gdal on Ubuntu via Parallels


On Feb 22, 2012, at 10:16 AM, Even Rouault wrote:

> Selon Stuart Edwards :
> 
>> Hi
>> 
>> This seems to be an old problem  (see
>> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but 
>> when I try to compile GDAL 1.9.0 from source using Ubuntu 10.04 
>> through Parallels Desktop 6.0.12106 on OS X 10.6.8 (don't ask why 
>> this convoluted approach - long ESRI related story)  I get the following 
>> message during 'make':
>> 
>> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or directory.
>> 
>> and indeed,
>> 
>> ls  /usr/local/gdal/frmts/o
>> 
>> produces a listing for aaigriddataset.lo , but unlike the other files 
>> in the directory, no corresponding aaigriddataset.o
> 
> Perhaps try ./configure --without-libtool . But no promise this will 
> help

seemed to compile without problem, but then gdalinfo gives ' gedalinfo: error 
while loading shared libraries: libgdal.so: cannot open shared object file: No 
such file or directory'

thx for the help

Stu

___
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] Can RasterIO write one band at a time or must I combine my separate R,G,B buffers first?

[Kyle Shannon]

Ethan, you can fetch single bands using GDALRasterBand* poBand =
GetRasterBand(1) and use poBand->RasterIO(...).  See docs here:

http://gdal.org/classGDALRasterBand.html


/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Wed, Feb 8, 2012 at 08:39, Ethan  wrote:

> I am writing a C++ program that reads in 3 separate single band geotiffs,
> applies some math to them, then outputs a single geotiff files that
> contains
> the data from those 3 files in the bands 1,2 and 3.  I've so far set up the
> code to follow the methods from the gdal api tutorial and have read in the
> values from each of the 3 geotiffs to 3 separate buffers.  When it comes
> time to use RasterIO to write to my single output geotiff, is there any way
> to write one band at a time?  Or is there any way to use the RasterIO
> function without first combining my 3 buffers into a single buffer?  For me
> the RasterIO documentation is a little unclear when it describes:
>nBandCount  the number of bands being read or written.
>panBandMap  the list of nBandCount band numbers being
> read/written. Note
> band numbers are 1 based. This may be NULL to select the first nBandCount
> bands.
>
> Thanks in advance for any help it's much appreciated.
>
> --
> View this message in context:
> http://osgeo-org.1560.n6.nabble.com/Can-RasterIO-write-one-band-at-a-time-or-must-I-combine-my-separate-R-G-B-buffers-first-tp4376337p4376337.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] numpy array to raster

[Kyle Shannon]

Is 'myarray' full of zeros?

/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Tue, Jan 31, 2012 at 19:20, questions anon wrote:

> thanks Frank, following your instructions with:
>
> src_ds=gdal_array.OpenArray(myarray)
> dst_ds =
> gdal.GetDriverByName('GTiff').Create('E:/test/rasterise/mynewraster.tif',ncols,
> nrows, 1 ,gdal.GDT_Byte)
>  dst_ds.SetGeoTransform(geotransform)
> dst_ds.GetRasterBand(1).WriteArray(myarray)
>
> I do not receive any error messages but the tiff produced are all just
> zeros. Is there a step I am missing?
> thanks
>
>
> On Wed, Feb 1, 2012 at 12:07 PM, Frank Warmerdam wrote:
>
>> On Tue, Jan 31, 2012 at 4:38 PM, questions anon
>>  wrote:
>> > I need to output my numpy array as a raster so that someone else can
>> access
>> > the data in ArcGIS. So basically the steps I need are:
>> > read numpy array into gdal
>> > convert to raster
>> > use latitude and longitude and array size to set projection
>> >
>> > I am really struggling with gdal because I can't seem to find enough
>> > documentation about each step to understand what it is doing.
>> > Here are some of the steps I think I need:
>> >
>> > myarray=myarray
>> > #the extent and shape of my array
>> > xmin,ymin,xmax,ymax=[139.8,-39.2,150.0,-33.6]
>> > ncols,nrows=[193,106]
>> > xres=(xmax-xmin)/float(ncols)
>> > yres=(ymax-ymin)/float(nrows)
>> > geotransform=(xmin,xres,0,ymax,0, -yres)
>> >
>> > from osgeo import gdal
>> > from osgeo import gdal_array
>> >
>> > src_ds=gdal_array.OpenArray(myarray)
>> >
>> > dst_ds =
>> >
>> gdal.GetDriverByName('GTiff').Create('E:/test/rasterise/mynewraster.tif',ncols,
>> > nrows, 1 ,gdal.GDT_Byte)
>> > dst_rb = dst_ds.GetRasterBand(0)
>> > dst_ds.SetGeoTransform(geotransform)
>> > output = gdal.RasterizeLayer(dst_ds)
>>
>> Dear "Questions Anon",
>>
>> There are a variety of Python related information at:
>>
>>  http://trac.osgeo.org/gdal/wiki/GdalOgrInPython
>>
>> One serious issue with the above is that "gdal.RasterizeLayer()" is used
>> to
>> turn vector data into raster data - for instance to rasterize polygon
>> features
>> into an existing raster file.  I think you want to write your array into a
>> raster file.  I think you can just call "dst_ds.WriteArray(myarray)".
>>
>> Alternatively if that method does not exist on the dataset, you
>> can write the one band like:
>>
>>  dst_ds.GetRasterBand(1).WriteArray(myarray)
>>
>> Some of the samples referenced from the GdalOgrInPython should be
>> helpful though I understand it can be hard to know where to look.
>>
>> 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 Software Developer
>>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 1.9.0 Beta1 Released

[Kyle Shannon]

GDAL: GDALOpen(./pdf3968087808_1-1.ppm, this=0x141b070) succeeds as PNM.
GDAL: GDALClose(./pdf3968087808_1-1.ppm, this=0x141b070)
16277
GDAL: GDALClose(data/adobe_style_geospatial.pdf, this=0x1411840)
fail
line 164: bad checksum

Test Script: PDF
Succeeded: 2
Failed: 1 (0 blew exceptions)
Skipped: 0
Expected fail:0

GDAL: In GDALDestroy - unloading GDAL shared library


/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Wed, Dec 21, 2011 at 11:47, Even Rouault wrote:

> Le mercredi 21 décembre 2011 19:30:45, Kyle Shannon a écrit :
> > Even,
> >
> > I rebuilt with GEOS support
>
> ok I'll add a test for geos presence to skip the 2 tests if it is not
> available.
>
> > and I added podofo support as well, for fun.  I
> > got a failure with a bad checksum in pdf.py:
>
> Can you just run pdf.py and look at the more precise error report. I
> believe
> it is due to missing poppler-utils ( pdftoppm namely ) that is necesserary
> to
> do the rasterization . See http://gdal.org/frmt_pdf.html
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 1.9.0 Beta1 Released

[Kyle Shannon]

Even,

I rebuilt with GEOS support and I added podofo support as well, for fun.  I
got a failure with a bad checksum in pdf.py:

 Failures 
Script: ogr/ogr_gft.py
TEST: ogr_gft_write ... fail
Script: gdrivers/pdf.py
TEST: pdf_1 ... fail
line 164: bad checksum
--

Test Script: pyscripts/test_gdal_sieve.py
Succeeded: 2238
Failed: 2 (0 blew exceptions)
Skipped: 624
Expected fail:13
As GDAL_RUN_SLOW_TESTS environment variable is not defined, 20 "slow" tests
have been skipped

kss

/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



2011/12/21 Mateusz Łoskot 

> On 20 December 2011 02:21, Frank Warmerdam  wrote:
> > Folks,
> >
> > I have prepared a first cut for the 1.9.0 release (Beta 1).  Source code
> > and the autotest suite can be found at:
> >
> >  http://download.osgeo.org/gdal/gdal190b1.zip
>
> I have built it and quickly tested command line tools in action
> using Visual Studio 2010, two configurations :
> nmake /f makefile.vc MSVC_VER=1600
> nmake /f makefile.vc MSVC_VER=1600 DEBUG=1
>
> for both, WIN32 and WIN64.
> All works for me.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 1.9.0 Beta1 Released

[Kyle Shannon]

>
> - the gft failure is due to an authentication cookie to the test account
> that I
>
must renew regularly (~ 2 weeks). Not an ideal solution. I think I should
> make
>
that test to only report 'skip' if it fails. Or find a way to automate the
>
renewal.
>

Sounds good.


> - I somehow remember to have seen the 2 couchdb failures on builds where
> GDAL
>
was build without GEOS support ? Is it your case ?
>

Correct, rebuilding with GEOS support, I will rerun my tests.

Thanks Even.

kss


/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Wed, Dec 21, 2011 at 10:24, Even Rouault wrote:

> Kyle,
>
> Thanks for your report.
>
> Nothing to worry particularly about :
>
> - the gft failure is due to an authentication cookie to the test account
> that I
> must renew regularly (~ 2 weeks). Not an ideal solution. I think I should
> make
> that test to only report 'skip' if it fails. Or find a way to automate the
> renewal.
> - I somehow remember to have seen the 2 couchdb failures on builds where
> GDAL
> was build without GEOS support ? Is it your case ?
>
> Best regards,
>
> Even
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL/OGR 1.9.0 Beta1 Released

[Kyle Shannon]

I am getting 3 failed tests, fedora 16 x64:

[kyle@localhost ~]$ uname -s -r -p -i -o
Linux 3.1.0-7.fc16.x86_64 x86_64 x86_64 GNU/Linux

[kyle@localhost gdalautotest-1.9.0]$ ./configure --enable-debug
--with-python --prefix=/home/kyle/src/gdal/beta/gdal-1.9.0b1/build

...

  Failures 
Script: ogr/ogr_gft.py
TEST: ogr_gft_write ... fail
Script: ogr/ogr_couchdb.py
TEST: ogr_couchdb_SetSpatialFilter ... fail
line 235: did not get expected feature count (1)
TEST: ogr_couchdb_SetSpatialFilter ... fail
line 235: did not get expected feature count (1)
--

Test Script: pyscripts/test_gdal_sieve.py
Succeeded: 2188
Failed: 3 (0 blew exceptions)
Skipped: 673
Expected fail:13
As GDAL_RUN_SLOW_TESTS environment variable is not defined, 20 "slow" tests
have been skipped



/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Mon, Dec 19, 2011 at 19:21, Frank Warmerdam  wrote:

> Folks,
>
> I have prepared a first cut for the 1.9.0 release (Beta 1).  Source code
> and the autotest suite can be found at:
>
>  http://download.osgeo.org/gdal/gdal-1.9.0b1.tar.gz
>  http://download.osgeo.org/gdal/gdal190b1.zip
>  http://download.osgeo.org/gdal/gdalautotest-1.9.0b1.tar.gz
>
> NEWS can be found at:
>
>  http://trac.osgeo.org/gdal/wiki/Release/1.9.0-News
>
> Feedback is very welcome.  I hope to have a second beta in 3-4 days.
>
> 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 Software Developer
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL interpolation of Gtiff / ESRI polygon.shp

[Kyle Shannon]

Roland,
I believe gdal_grid takes an ogr file as input and creates a raster from a
point layer.  If you just want to resample a raster, try gdalwarp, without
the warping:

kyle@local$ gdalwarp -ts 118 188 -r cubicspline coarse.tif fine.tif

where -ts is 'target size' and -r is resampling method.  See gdalwarp
documentation for info:

http://gdal.org/gdalwarp.html

also here is the gdal_grid info:

http://gdal.org/gdal_grid.html

/**
 *
 * Kyle Shannon
 * ksshan...@gmail.com
 *
 */



On Wed, Dec 21, 2011 at 04:13, RolandB  wrote:

> Dear users,
>
> I want use gdal for some file transformation.
> Any help in solving the issue is greatly appreciated by me! It would
> be great if one of you have solved already this problem or knows how to do
> so.
>
> By gdal_rasterize I did create a Gtiff raster from a ESRI Polygon
> shapefile.
> This is successful. I have worked with the Gtiff successful later on with
> $user>: gdal_translate -of netCDF ./tmp/output.tif ./tmp/output2.nc
> Still some commands do not work. I'm looking forward for replies.
>
>
> Where is the GTiff driver in the list below???
> And what is the output layer of the Gtiff file? I tried "1", "Band1",
> "band". No file opening with any band.
>
> So here are the commands and the error messages:
>
> First:
>
> *$user>: * gdal_rasterize -a kennummer -init 0 -l Bk50_rur_wgs -te 5.93
> 50.39 6.74722 51.22886 -ts 59 94 -ot Int32 ./Input/bk50_rur_wgs.shp
> ./tmp/output.tif
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> *$user>: *gdal_grid -a invdist:power=2.0:smoothing=1.0 -ot Int32 -txe
> 50.39 51.22886 -tye 5.93 6.74722 -outsize 59 94 -l Band1
> ./tmp/output.tif ./tmp/newout.tif
> Unable to open input datasource "./tmp/output.tif".
>
> *$user>:* "gdalinfo ./tmp/output.tif"
>
> Driver: GTiff/GeoTIFF
> Files: ./tmp/output.tif
> Size is 59, 94
> Coordinate System is:
> GEOGCS["WGS 84",
>  DATUM["WGS_1984",
>  SPHEROID["WGS 84",6378137,298.257223563,
>  AUTHORITY["EPSG","7030"]],
>  AUTHORITY["EPSG","6326"]],
>  PRIMEM["Greenwich",0],
>  UNIT["degree",0.0174532925199433],
>  AUTHORITY["EPSG","4326"]]
> Origin = (5.930,51.2288597)
> Pixel Size = (0.013851186440678,-0.008924042553191)
> Metadata:
>  AREA_OR_POINT=Area
> Image Structure Metadata:
>  INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (   5.930,  51.2288600)
> Lower Left  (   5.930,  50.390)
> Upper Right (   6.7472200,  51.2288600)
> Lower Right (   6.7472200,  50.390)
> Center  (   6.3386100,  50.8094300)
> Band 1 Block=59x34 Type=Int32, ColorInterp=Gray
>
>
> *$user>: *"ogrinfo ./tmp/output.tif"
> FAILURE:
> Unable to open datasource `./tmp/output.tif' with the following drivers.
>  -> ESRI Shapefile
>  -> MapInfo File
>  -> UK .NTF
>  -> SDTS
>  -> TIGER
>  -> S57
>  -> DGN
>  -> VRT
>  -> REC
>  -> Memory
>  -> BNA
>  -> CSV
>  -> GML
>  -> GPX
>  -> KML
>  -> GeoJSON
>  -> GMT
>  -> SQLite
>  -> PostgreSQL
>  -> PCIDSK
>  -> XPlane
>  -> AVCBin
>  -> AVCE00
>  -> DXF
>  -> Geoconcept
>  -> GeoRSS
>  -> GPSTrackMaker
>  -> VFK
>  -> PGDump
>  -> GPSBabel
>  -> SUA
>  -> OpenAir
>  -> PDS
>  -> WFS
>  -> HTF
>  -> AeronavFAA
>
> *$user>:* gdal_translate -of netCDF ./tmp/output.tif ./tmp/output2.nc
> Input file size is 59, 94
>
> (This last should be done with the interpolated file, which I did not
> manage so far.)
>
> Best regards,
> Roland
>
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/GDAL-interpolation-of-Gtiff-ESRI-polygon-shp-tp7114807p7114807.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] invert option for rasterize in python bindings

[Kyle Shannon]

Is the -i (invert burn) option available through gdal.RasterizeLayer()?  I 
can't find the documentation.

Kyle Shannon
Senior Software Engineer
GCS Research
Office 406-532-3254 * Direct 406-541-3276
kshan...@gcs-research.com<mailto:kshan...@gcs-research.com> * 
www.gcs-research.com<http://www.gcs-research.com/>

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

RE: [gdal-dev] -unscale issue with multiband vrt

[Kyle Shannon]

Your correct Even.  I thought I had nodata values in the other bands, but I 
didn't, I introduce those later in processing.  Thanks again.  Good guessing.

kss

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: Wednesday, December 07, 2011 2:03 PM
To: gdal-dev@lists.osgeo.org
Cc: Kyle Shannon
Subject: Re: [gdal-dev] -unscale issue with multiband vrt

Le mercredi 07 décembre 2011 20:17:39, Kyle Shannon a écrit :

I think you are in fact exactly running in the issue of #3085.

It is difficult to know for sure without having the data under my eyes, but I'm 
going to guess one more time ;-)

So my guess it that before -unscale, your band 1 et 2 have pixels whose value 
match the nodata value of -. And they are not taken into account in the 
minimum/maximum value computation, which is appropriate.

After -unscale - that doesn't do special for nodata values - , those values of
- are multiplied by 100, hence the -00 as the new minimum value for 
band 1 and 2. For other bands the minimum value after unscale is the minimum 
value before unscale * 100.

So all in all the behaviour is just consistant for all bands, but not the one 
you expect.


> Hi All,
> I am running into an issue with unscaling a multiband raster.  I am
> creating a vrt from 5 xyz datasets.  I use the following command:
> 
> gdalbuildvrt -separate -srcnodata - mmi.vrt csv\*
> 
> 3 of the 5 rasters are of the lower 48 states of the US, the other 2 are
> only the western half.  gdalbuildvrt works good, and pads the eastern half
> of the US with nodata values of - for the western rasters.  I have to
> scale all of the bands, so I edit the vrt and add 100 to
> each VRTRasterBand
> 
> This displays correctly in gdalinfo:
> 
> C:\Users\k\Desktop\mmi_tmp\vrt_test>gdalinfo -stats -nomd mmi.vrt
> Driver: VRT/Virtual Raster
> Files: mmi.vrt
>csv\2008.WUS.Xpgv.537.2475
>csv\2008.WUS.Xpgv.537.475
>csv\UShazard.20081231.pga.10pc50
>csv\UShazard.20081231.pga.2pc50
>csv\UShazard.20081231.pga.5pc50
> Size is 1201, 509
> Coordinate System is `'
> Origin = (-125.0250010,50.024)
> Pixel Size = (0.050,-0.050)
> Corner Coordinates:
> Upper Left  (-125.025,  50.025)
> Lower Left  (-125.025,  24.575)
> Upper Right ( -64.975,  50.025)
> Lower Right ( -64.975,  24.575)
> Center  ( -95.000,  37.300)
> Band 1 Block=128x128 Type=Float32, ColorInterp=Undefined
>   Min=0.100 Max=200.000
>   Minimum=0.100, Maximum=200.000, Mean=10.363, StdDev=16.347
>   NoData Value=-
>   Offset: 0,   Scale:100
> Band 2 Block=128x128 Type=Float32, ColorInterp=Undefined
>   Min=0.100 Max=123.982
>   Minimum=0.100, Maximum=123.982, Mean=4.866, StdDev=8.152
>   NoData Value=-
>   Offset: 0,   Scale:100
> Band 3 Block=128x128 Type=Float32, ColorInterp=Undefined
>   Min=0.005 Max=1.110
>   Minimum=0.005, Maximum=1.110, Mean=0.041, StdDev=0.064
>   NoData Value=-
>   Offset: 0,   Scale:100
> Band 4 Block=128x128 Type=Float32, ColorInterp=Undefined
>   Min=0.005 Max=2.037
>   Minimum=0.005, Maximum=2.037, Mean=0.103, StdDev=0.150
>   NoData Value=-
>   Offset: 0,   Scale:100
> Band 5 Block=128x128 Type=Float32, ColorInterp=Undefined
>   Min=0.005 Max=1.346
>   Minimum=0.005, Maximum=1.346, Mean=0.063, StdDev=0.097
>   NoData Value=-
>   Offset: 0,   Scale:100
> 
> When I unscale the raster, the Full US bands do fine, but the no data value
> for the Western US Bands isn't respected and the nodata values are
> changed.  Am I missing something in my vrt?  Any thoughts.
> 
> C:\Users\k\Desktop\mmi_tmp\vrt_test>gdal_translate -unscale mmi.vrt mmi.tif
> Input file size is 1201, 509
> 0...10...20...30...40...50...60...70...80...90...100 - done.
> 
> C:\Users\k\Desktop\mmi_tmp\vrt_test>gdalinfo -nomd -stats mmi.tif
> Driver: GTiff/GeoTIFF
> Files: mmi.tif
> Size is 1201, 509
> Coordinate System is `'
> Origin = (-125.0250010,50.024)
> Pixel Size = (0.050,-0.050)
> Corner Coordinates:
> Upper Left  (-125.025,  50.025)
> Lower Left  (-125.025,  24.575)
> Upper Right ( -64.975,  50.025)
> Lower Right ( -64.975,  24.575)
> Center  ( -95.000,  37.300)
> Band 1 Block=1201x1 Type=Float32, ColorInterp=Gray
>   Minimum=-00.000, Maximum=2.000, Mean=-582357.045,
> StdDev=493551.313 NoData Value=-
> Band 2 Block=1201x1 Type=Float32, ColorInterp=Undefined
>   Minimum=-00.000, Maximum=12398.200, Mean=-582586.370,
> StdDev=493279.394 NoData Value=-
> Band 3 Block=1201x1 Type=Float32, ColorInterp=Undefined
>  

[gdal-dev] -unscale issue with multiband vrt

[Kyle Shannon]

Hi All,
I am running into an issue with unscaling a multiband raster.  I am creating a 
vrt from 5 xyz datasets.  I use the following command:

gdalbuildvrt -separate -srcnodata - mmi.vrt csv\*

3 of the 5 rasters are of the lower 48 states of the US, the other 2 are only 
the western half.  gdalbuildvrt works good, and pads the eastern half of the US 
with nodata values of - for the western rasters.  I have to scale all of 
the bands, so I edit the vrt and add 100 to each VRTRasterBand

This displays correctly in gdalinfo:

C:\Users\k\Desktop\mmi_tmp\vrt_test>gdalinfo -stats -nomd mmi.vrt
Driver: VRT/Virtual Raster
Files: mmi.vrt
   csv\2008.WUS.Xpgv.537.2475
   csv\2008.WUS.Xpgv.537.475
   csv\UShazard.20081231.pga.10pc50
   csv\UShazard.20081231.pga.2pc50
   csv\UShazard.20081231.pga.5pc50
Size is 1201, 509
Coordinate System is `'
Origin = (-125.0250010,50.024)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-125.025,  50.025)
Lower Left  (-125.025,  24.575)
Upper Right ( -64.975,  50.025)
Lower Right ( -64.975,  24.575)
Center  ( -95.000,  37.300)
Band 1 Block=128x128 Type=Float32, ColorInterp=Undefined
  Min=0.100 Max=200.000
  Minimum=0.100, Maximum=200.000, Mean=10.363, StdDev=16.347
  NoData Value=-
  Offset: 0,   Scale:100
Band 2 Block=128x128 Type=Float32, ColorInterp=Undefined
  Min=0.100 Max=123.982
  Minimum=0.100, Maximum=123.982, Mean=4.866, StdDev=8.152
  NoData Value=-
  Offset: 0,   Scale:100
Band 3 Block=128x128 Type=Float32, ColorInterp=Undefined
  Min=0.005 Max=1.110
  Minimum=0.005, Maximum=1.110, Mean=0.041, StdDev=0.064
  NoData Value=-
  Offset: 0,   Scale:100
Band 4 Block=128x128 Type=Float32, ColorInterp=Undefined
  Min=0.005 Max=2.037
  Minimum=0.005, Maximum=2.037, Mean=0.103, StdDev=0.150
  NoData Value=-
  Offset: 0,   Scale:100
Band 5 Block=128x128 Type=Float32, ColorInterp=Undefined
  Min=0.005 Max=1.346
  Minimum=0.005, Maximum=1.346, Mean=0.063, StdDev=0.097
  NoData Value=-
  Offset: 0,   Scale:100

When I unscale the raster, the Full US bands do fine, but the no data value for 
the Western US Bands isn't respected and the nodata values are changed.  Am I 
missing something in my vrt?  Any thoughts.

C:\Users\k\Desktop\mmi_tmp\vrt_test>gdal_translate -unscale mmi.vrt mmi.tif
Input file size is 1201, 509
0...10...20...30...40...50...60...70...80...90...100 - done.

C:\Users\k\Desktop\mmi_tmp\vrt_test>gdalinfo -nomd -stats mmi.tif
Driver: GTiff/GeoTIFF
Files: mmi.tif
Size is 1201, 509
Coordinate System is `'
Origin = (-125.0250010,50.024)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-125.025,  50.025)
Lower Left  (-125.025,  24.575)
Upper Right ( -64.975,  50.025)
Lower Right ( -64.975,  24.575)
Center  ( -95.000,  37.300)
Band 1 Block=1201x1 Type=Float32, ColorInterp=Gray
  Minimum=-00.000, Maximum=2.000, Mean=-582357.045, StdDev=493551.313
  NoData Value=-
Band 2 Block=1201x1 Type=Float32, ColorInterp=Undefined
  Minimum=-00.000, Maximum=12398.200, Mean=-582586.370, StdDev=493279.394
  NoData Value=-
Band 3 Block=1201x1 Type=Float32, ColorInterp=Undefined
  Minimum=0.500, Maximum=111.030, Mean=4.092, StdDev=6.447
  NoData Value=-
Band 4 Block=1201x1 Type=Float32, ColorInterp=Undefined
  Minimum=0.500, Maximum=203.720, Mean=10.284, StdDev=14.961
  NoData Value=-
Band 5 Block=1201x1 Type=Float32, ColorInterp=Undefined
  Minimum=0.500, Maximum=134.630, Mean=6.273, StdDev=9.686
  NoData Value=-



Kyle Shannon
Senior Software Engineer
GCS Research
Office 406-532-3254 * Direct 406-541-3276
kshan...@gcs-research.com<mailto:kshan...@gcs-research.com> * 
www.gcs-research.com<http://www.gcs-research.com/>

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

[gdal-dev] RE: Editing KML files using ogr_csharp.dll

[Kyle Shannon]

Can you report your gdal version and where you got it from?  Is it from 
gisinternals.com/sdk, or did you build it yourself?

From: Pouliot, Christopher (DNR) [mailto:christopher.poul...@state.mn.us]
Sent: Monday, December 05, 2011 9:04 AM
To: Kyle Shannon; gdal-dev@lists.osgeo.org
Subject: RE: Editing KML files using ogr_csharp.dll

Thanks for the response Kyle.

  I do use the CreateDataSource() to create a new KML.  But am unable to open 
an existing KML for editing using the Open() code I specified below.

Chris

From: Kyle Shannon [mailto:kshan...@gcs-research.com]
Sent: Monday, December 05, 2011 9:54 AM
To: Pouliot, Christopher (DNR); gdal-dev@lists.osgeo.org
Subject: RE: Editing KML files using ogr_csharp.dll

Chris,

I don' know OGR very well, but I see a few issues.  I also am not sure about 
the c# bindings, I believe they are pretty complete though.

'''OSGeo.OGR.Driver drv = Ogr.GetDriverByName("KML");
DataSource ds = drv.Open("c:\\temp\\mykml.kml", 1);'''

Open() opens existing files, you need to use driver->CreateDatasource() to 
create datasets.  Open() opens files for editing.  If mykml.kml exists, use 
Open().

see http://gdal.org/ogr/ogr_apitut.html for information on using OGR to 
read/write data

'''Also, when creating a KML file from scratch is there a way to map the Name 
and Description fields to my existing fields so that the Name and Description 
appear in Google Earth?'''

See http://gdal.org/ogr/drv_kml.html for this, it appears to be possible.

There is also the libkml driver: http://gdal.org/ogr/drv_libkml.html

kss

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Pouliot, Christopher 
(DNR)
Sent: Monday, December 05, 2011 7:51 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Editing KML files using ogr_csharp.dll

Hello All,

I have a C# application that uses OGR_CSHARP.DLL to read/write KML files.  I'm 
able to read from KML files fine.  I'm able to create a new KML file and write 
to it fine.  I am unable, however, to open a KML file to edit.  I'd like to be 
able to append a new layer (folder) onto an existing KML file.  I've tried both 
of the following code snippets:

//This returns NULL
OSGeo.OGR.Driver drv = Ogr.GetDriverByName("KML");
DataSource ds = drv.Open("c:\\temp\\mykml.kml", 1);


//This returns NULL
DataSource ds = Ogr.Open("c:\\temp\\mykml.kml", 1);


I'm able to use this code to edit File Geodatabases and Shapefiles but not KML.



Also, when creating a KML file from scratch is there a way to map the Name and 
Description fields to my existing fields so that the Name and Description 
appear in Google Earth?


Thanks,

Chris

Chris Pouliot
GIS Application Developer
Minnesota Department of Natural Resources
christopher.poul...@state.mn.us<mailto:christopher.poul...@state.mn.us>
(651) 259-5491


This email message is for the sole use of the intended recipient(s) and may 
contain confidential and privileged information. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply email and delete the original 
message.   
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev