id viewshed from this data by passing in a -cc of
roughly 3.6 (Earth diameter / Moon diameter)? Some comments in the algorithm's
source code make this seem reasonable, but I would like to confirm that this is
the only correction I would need to make.
Thank yo
Ok, yes, thank you, the code in the trunk made a huge difference. I
appreciated it!
On Thu, Mar 22, 2018 at 3:21 AM, Even Rouault
wrote:
> Kevin,
>
> > I've been working on some large GeoPackage files that have a lot of
> layers.
> > One in particular has over 5000 la
't sure who to submit it to. There are
also several other places in GDAL where queries to sqlite_master can be
optimized, so I wanted to talk about it before I waste time refactoring
other code. Is this a patch the maintainers would be interested in
integrating?
--
Kevin Bentley
Cognitics, In
ve to think a little more about what the right calculation
should be in the case of a positive matrix determinant. If Taylor
Brown doesn't respond to this thread within a few days, I'll try to
put together a patch myself that incorporates all of this.
--
Kevin B. McCarty
__
y
rare. But it seems clear to me that some change to elements [0] and
[3] of this sort is needed in that (obscure) case.
> I've just left a message to the original author of ENVI rotation read
> support in:
>
> https://github.com/OS
it here.
Best regards, and many thanks for your work,
--
Kevin B. McCarty
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
.tif)
directly from the GDB file (COUNTRY_ROAD.gdb).
I have tried to use this cmd but failed.
gdal_rasterize -burn 1 -where "ROAD_ID < 100" -l State_ROAD
*COUNTRY_ROAD.gdb* State_ROAD *road1.tif*
I seek your generous help and suggestions.
Tha
Another excellent suggestion!
Merci Even.
From: Even Rouault [even.roua...@mines-paris.org]
Sent: Friday, December 07, 2012 9:55 AM
To: Kevin F Webb
Cc: Homme Zwaagstra; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] v1.9.2 throws ERROR 4 exception
temdata02/kfw4/modis_landcov\
er/tiles/MCD12Q1.A2011001.h33v07.051.2012264183744.hdf' not recognised as a
supported file form\
at.
From: Homme Zwaagstra [h...@geodata.soton.ac.uk]
Sent: Friday, December 07, 2012 5:57 AM
To: Kevin F Webb
Cc: gdal-dev@l
mines-paris.org]
Sent: Thursday, December 06, 2012 1:53 PM
To: Kevin F Webb
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] v1.9.2 throws ERROR 4 exception, v1.6.1 does not
Le jeudi 06 décembre 2012 19:48:34, Kevin F Webb a écrit :
> attached
>
> Thanks Even!
Your file works me for both
Hi folks,
I have a curious situation with v1.9.2 generating ERROR 4 exceptions on an HDF4
file, and v1.6.1 does not (same machine, same HDF4 library, same HDF file, both
versions compiled today). The output below demonstrates the conundrum.
Any ideas?
KFW
[kfw4@columba ~]$ file
/mnt/stemdat
I ran into a small limitation of rgb2pct.py when processing the
http://www.glcf.umd.edu/data/landcover/data.shtml 1km AVHRR landcover data set.
Essentially the data is structured such that there is a single color channel in
which each pixel has a value between 0 - 14. Where 0 is water and 1-4 ar
iacove...@gmail.com]
Sent: Tuesday, March 20, 2012 2:04 PM
To: Netherton, Kevin J FLNR:EX
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] python filegdb problems
Did you run ogrinfo arc10geodb.gdb on a shell?
Does it show the layers inside the fileGDB or it throws some error?
Stefano
2
Hello
I'm trying to get the python bindings to the ogr library working with esri file
geodatabase (filegdb) support. I am using the latest version of ms4w package
that includes gdal/ogr 1.9.
I have created a esri file geodatabase driver, then from that created a data
source, but am unable to
the line with
the grid and keep the intersected cells
- result: assemble resulting cells and export
Not being a spatial expert, I'm not sure though this is the good way. Could
you have a look and perhaps give me a few hints?
Thanks a lot!
Kevin
___
-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com]
Sent: Thursday, July 29, 2010 4:35 PM
To: Kevin F Webb
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Memory leak from GDALRasterIO
Kevin F Webb wrote:
>
> I am experiencing a memory leak from looped ca
Good day!
I am experiencing a memory leak from looped calls to GDALRasterIO(). It may be
something I am doing improperly
because I use/call RasterIO() in a C++ program that runs leak free.
I "migrated" the C++ code to the GDAL C API so that I can integrate some really
old C code downstream
GDAL_CACHEMAX 200 -wm 200 -wo SKIP_NOSOURCE=YES -r bilinear -multi
input_ice.tif output_ice.tif
it is working now but the speed is very slow - likely this will take 12
hours... Any way to speed up or am I wrong in selecting the parameters? Many
thanks.
Kevin
GDAL_CACHEMAX 200 -wm 200 -wo SKIP_NOSOURCE=YES -r bilinear -multi
input_ice.tif output_ice.tif
it is working now but the speed is very slow - likely this will take 12
hours... Any way to speed up or am I wrong selecting those parameters?
Thanks.
Kevin
Has someone already documented the performance difference between x32 and
x64 versions of the FWTools / gdal? Improvement by how much? Many thanks.
Kevin
On Thu, Jun 3, 2010 at 1:39 AM, John Mitchell wrote:
> Does anyone have built/compiled 64 bit versions of either FWTools or gdal
&g
dded a while ago:
* Revision 1.28 2005/06/08 19:38:14 fwarmerdam
* protect PROJ.4 use with a mutex
Thanks!
Kevin Bentley
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
nothing happened since then. Is there something else I
should do or are there someone I should get in touch with?
Ticket opened: http://trac.osgeo.org/gdal/ticket/3376
Thank you,
Kevin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http
s a geolocation fields, data fields and swatch
attributes.
when I read the data in the data fields, I use GetMetadata( "SUBDATASETS" ).
but I do not know how to read the data in the geolocation fields.
can anyone help me?
best regards.
Kevin Lin
bjlin...@gmail.
w other NITF viewer
opens the file or not.
I haven't deal with JPEG format much before. So any suggestion on what
might went wrong, or anything else I can try is greatly appreciated.
-Kevin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
know if this is ok.
-Kevin Chiou
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
amp;product=uniconvertor
In conclusion, it's possible to use Uniconvertor to parse CGM data into
a usable form. Moreover, since Uniconvertor supports multiple vector
formats, you can use the approach I described to convert other vector
graphics formats into an OGR dataset.
-Kevin
The Python wrapper trims white spaces
when GetMetadata() is called, which is not desired for NITF TRE data. I
found the problem in the wrapper code and updated it.
Do I just have to open a GDAL Trac ticket and attach the fix?
Thank you,
Kevin Chiou
__
build instructions?
Thanks
Kevin F.
Kevin Faschoway
Web Developer
DBx GEOMATICS inc.
37 Boul. St-Joseph, 2e étage
Gatineau, Québec, CANADA J8Y 3V8
Tel : 819.772.2000 + 23
Fax : 819.772.2001
Email: kfascho...@dbxgeomatics.com
Website : www.dbxgeomatic
At 12:46 PM 12/22/2008, Ragi Y. Burhum wrote:
Date: Mon, 22 Dec 2008 09:37:15 -0500
From: Kevin Webb <<mailto:k...@cornell.edu>k...@cornell.edu>
Subject: [gdal-dev] OGR and GEOS
To: <mailto:gdal-dev@lists.osgeo.org>gdal-dev@lists.osgeo.org
Message-ID:
<<mailto:6.2.1.
At 11:07 AM 12/22/2008, Frank Warmerdam wrote:
Kevin Webb wrote:
Greetings!
The documentation for the OGRGeometry class mentions the GEOS library in
a few of the
method definitions, but I wonder if there is a "stronger" OGR dependency
on the GEOS
library than the documentatio
Greetings!
The documentation for the OGRGeometry class mentions the GEOS library in a
few of the
method definitions, but I wonder if there is a "stronger" OGR dependency on
the GEOS
library than the documentation suggests. Perhaps GEOS should be a required
library.
I had done some processing
31 matches
Mail list logo
