It is set at the time of dataset creation and cannot be changed without
creating a new dataset. Check which drivers allow you to set a tiled layout
on disk.
THK
http://www.keittlab.org/
On Wed, Aug 24, 2016 at 6:44 AM, BRUNEL Samuel <
samuel.bru...@thalesgroup.com> wrote:
> Hi,
>
> It's easy to
http://www.keittlab.org/
On Wed, Aug 17, 2016 at 3:26 PM, James Ramm wrote:
> Hi,
> I wasn't talking about MapReduce per se (although this would also be very
> interesting), but rather the 'classic' functional programming functions of
> 'map' and 'reduce'.
>
> A 'map' function essentially takes
On Fri, May 6, 2016 at 2:47 PM, Kurt Schwehr wrote:
> For stack ranking, see the "alternatives" section of this (and I did not
> include my preferred std::vector solution in the list):
That seems like a reasonable solution. The function/method call interface
is where I would begin substituting
http://www.keittlab.org/
On Fri, May 6, 2016 at 2:47 PM, Mateusz Loskot wrote:
> On 6 May 2016 at 21:55, Kurt Schwehr wrote:
> > My belief is that for this particular proposal, we should not have the
> > C++11/14 discussion unless the best overall solution requires a newer
> > version of C++.
http://www.keittlab.org/
On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr wrote:
> I was not intending for C++11 to be a big part of the discussion as it is
> a much more complicated topic, but I do appreciate the discussion. I
> picked the stack + memset -> std::vector(nSize, initialValue) to do f
http://www.keittlab.org/
On Tue, Sep 1, 2015 at 8:34 AM, Even Rouault
wrote:
> Folks,
>
> I'd wish we can find a solution that satisfy all parties. Here's another
> iteration for a possible proposition.
>
> * C API:
>
> Principles :
> - dataset objects can be passed
> - the option structure is o
On Mon, Mar 30, 2015 at 7:14 AM, Newcomb, Doug wrote:
> +1
>
> The utilities are used by a lot of folks who cannot have compilers loaded
> on their computers for security reasons.
>
> Doug
>
> On Sat, Mar 28, 2015 at 6:06 AM, Damian Dixon
> wrote:
>
>> There are a lot of GIS specialists and geog
I'm looking for a version of libgdal1h or libgdal1-dev compiled with
debugging symbols. Anyone know of a source?
THK
--
http://www.keittlab.org/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
I was trying to recall the details of the RasterIO function and notice that
the previous documentation is gone. This seems to have happened in the
transition to the v2 interface. Is there a plan to maintain the C API
documentation?
(I was going to look up the handling of no-data values, scale and
On Fri, Mar 28, 2014 at 3:24 PM, Mateusz Łoskot wrote:
> On 28 March 2014 21:04, Tim Keitt wrote:
> > Something to consider is writing an interface that wraps the old code.
> > Modern generic approaches make this easy.
> >
> > Perhaps evaluate the Generic Image Li
Something to consider is writing an interface that wraps the old code.
Modern generic approaches make this easy.
Perhaps evaluate the Generic Image Library and Boost Geometry as candidates?
THK
On Fri, Mar 28, 2014 at 3:24 AM, Even Rouault
wrote:
> Dmitriy,
>
> It is not at all my intention to
On Thu, Mar 27, 2014 at 4:26 PM, Jonathan Greenberg wrote:
> GDALers:
>
> What is the most efficient way, given a "reference raster", and an
> arbitrary raster (we'll call it "unsynced") synced together to allow
> them to be stacked: the output of this should be the unsynced raster
> with the same
On Wed, Feb 26, 2014 at 3:02 PM, Even Rouault
wrote:
> Tim,
>
> > When I extract a feature from a layer, what issues arise with the
> lifetime
> > of the feature and the layer? If I keep the layer alive, will the feature
> > continue to be valid?
>
> Yes, feature objects (at least at C++ objects,
When I extract a feature from a layer, what issues arise with the lifetime
of the feature and the layer? If I keep the layer alive, will the feature
continue to be valid?
If I clone a feature, is it now standalone or does it still depend on the
layer/datasource in anyway?
I see the note about des
On Thu, Feb 13, 2014 at 3:20 PM, Even Rouault
wrote:
> Le jeudi 13 février 2014 22:17:40, Tim Keitt a écrit :
> > On Thu, Feb 13, 2014 at 12:55 PM, Tim Keitt wrote:
> > > I've been updating my R bindings to GDAL/OGR. The repo is at
> > > https://github.com/thk
On Fri, Feb 14, 2014 at 3:06 AM, Roger Bivand wrote:
> https://stat.ethz.ch/pipermail/r-sig-geo/2014-February/020409.html
>
> summarised as points and questions to Tim:
>
> Your choice of Rcpp is one that the extension of R to include reference
> classes recently, provoked by Rcpp, makes possible
On Thu, Feb 13, 2014 at 12:55 PM, Tim Keitt wrote:
> I've been updating my R bindings to GDAL/OGR. The repo is at
> https://github.com/thk686/rgdal2.
>
> There is still lots to do and this might make a good GSOC project.
>
In case there is any confusion (I've received
I've been updating my R bindings to GDAL/OGR. The repo is at
https://github.com/thk686/rgdal2.
There is still lots to do and this might make a good GSOC project.
THK
--
http://www.keittlab.org/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http:/
On Fri, Feb 7, 2014 at 11:10 AM, Kshitij Kansal wrote:
> This means that the final product as a result of this product will also be
> bounded by the above licences. It can not go into GDAL's main distribution
> but can be used as a separate utility of GDAL for non-commercial uses only.
> Basicall
On Tue, Dec 10, 2013 at 12:44 PM, Even Rouault wrote:
> Le mardi 10 décembre 2013 16:48:31, Ivan Lucena a écrit :
> > Hi Even,
> >
> > > From: even.roua...@mines-paris.org
> > > To: gdal-dev@lists.osgeo.org
> > > Subject: Re: [gdal-dev] Default GeoTransform for MEM driver
> > > Date: Mon, 9 Dec 2
On Mon, Dec 9, 2013 at 1:54 PM, Even Rouault
wrote:
> Le lundi 09 décembre 2013 18:08:19, Ivan Lucena a écrit :
> > The other problem with that documentation is the return code. CE_Failue
> > means that the driver does not support it and/or that the dataset doesn't
> > have it.
>
> The current beh
diff type setup.)
THK
On Sun, Dec 8, 2013 at 11:27 PM, Jukka Rahkonen
wrote:
> Tim Keitt gmail.com> writes:
>
> >
> > I notice that the "MEM" driver returns {0, 1, 0, 0, 0, -1} by default. Is
> this a bug or do some formats flip the vertical axis? If so, what
I notice that the "MEM" driver returns {0, 1, 0, 0, 0, -1} by default. Is
this a bug or do some formats flip the vertical axis? If so, what is the
convention for detecting and handling "south up" formats in code?
THK
--
Timothy H. Keitt
http://www.keittlab.org/
__
drawing order...
THK
On Wed, Oct 30, 2013 at 12:54 AM, Jukka Rahkonen
wrote:
> Tim Keitt utexas.edu> writes:
>
> >
> >
> > OK. Now I have my PEN styles loaded in the table. The KML driver is still
> writing only red. Anyone how to get KML to use the OGR_STYLE column?
>
OK. Now I have my PEN styles loaded in the table. The KML driver is still
writing only red. Anyone how to get KML to use the OGR_STYLE column?
THK
On Tue, Oct 29, 2013 at 8:57 PM, Tim Keitt wrote:
> Thanks. I had seen that, but did not realize it was saying to write these
> string
Thanks. I had seen that, but did not realize it was saying to write these
string into a column in the database.
THK
On Tue, Oct 29, 2013 at 5:10 PM, Jukka Rahkonen
wrote:
> Tim Keitt utexas.edu> writes:
>
> >
> > I'd like to set the color of line segments individua
I'd like to set the color of line segments individually according to a
field in KML output. Is that possible? Seem it only outputs red. I can
change that globally, but not easily for many line segments.
Looking at the driver code, there is some code there to handle colors. I
have no idea how to at
On Mon, Jan 14, 2013 at 2:47 AM, Jukka Rahkonen
wrote:
> Kennedy, Paul fugro.com.au> writes:
>
> >
> >
> > Hi
> > Simultaneous writers would be a better long term solution as we often
> improve
> the raster following initial creation. This improvement may well be a
> filter run
> on a sub region
On Tue, Oct 9, 2012 at 11:07 AM, Chris Barker wrote:
> On Sun, Oct 7, 2012 at 8:33 PM, Tim Keitt wrote:
>
>>> cool! though I"m a little confused as to how this fits with OGR.
>>
>> OGR is used for i/o.
>>
>
> I see -- so you've written something l
On Fri, Oct 5, 2012 at 11:11 AM, Chris Barker wrote:
> On Thu, Oct 4, 2012 at 6:31 PM, Tim Keitt wrote:
>> Just letting folks know that we've released an OGR wrapper for the
>> Triangle library. It would be great if folks could test it. I could
>> also use some h
Just letting folks know that we've released an OGR wrapper for the
Triangle library. It would be great if folks could test it. I could
also use some help improving the OGR bits.
Cheers,
THK
https://bitbucket.org/keittlab/meshpoly
--
Timothy H. Keitt
http://www.keittlab.org/
-
> The opinions I express are my own and are not representative of the
> official policy of the U.S.Fish and Wildlife Service or Dept. of the
> Interior. Life is too short for undocumented, proprietary data formats.
>
>
> *Tim Keitt *
> Sent by: gdal-
If you need complete control, and your data are not too massive in
number, I have had good results pushing pixel coordinates as points
into postgis and then using spatial queries to aggregate in various
ways (eg averages a hexagonal grid). It seems round-about, but it
works. I've actually done it o
Maybe someone over here knows the answer?
THK
-- Forwarded message --
From: Tim Keitt
Date: Tue, Aug 24, 2010 at 7:41 PM
Subject: Question on valid shapefiles
To: qgis-developer
I am using OGR to write output from an application. The first few
lines from 'ogrinfo -a
I made my first foray into OGR today and want to be sure I understand
the following code from the tutorial.
In particular, I am wondering why the feature is created and destroyed
in each loop. Could one instead create a single feature object and
simply update its x and y values repeatedly? Clearly
On Sun, Aug 22, 2010 at 1:21 AM, Tim Keitt wrote:
> On Sat, Aug 21, 2010 at 7:41 PM, Frank Warmerdam wrote:
>> Tim Keitt wrote:
>>>
>>> How about:
>>
>> Tim,
>>
>> I don't really like! I think instead it would be better to have
>
On Sat, Aug 21, 2010 at 7:41 PM, Frank Warmerdam wrote:
> Tim Keitt wrote:
>>
>> How about:
>
> Tim,
>
> I don't really like! I think instead it would be better to have
> a method/function to copy a variety of types of metadata - possibly
> taking some
Oops. This would have to be made a non-member function so a different
driver could be specified.
THK
On Sat, Aug 21, 2010 at 7:24 PM, Tim Keitt wrote:
> How about:
>
> //
> /*
on( poSrcDS->GetProjectionRef() );
}
poDstDS->SetMetadata( poSrcDS->GetMetadata() );
return poDstDS;
}
On Sat, Aug 21, 2010 at 7:14 PM, Tim Keitt wrote:
> OK. I found the source. Yes, that is fairly straightforward to copy and
> modify.
>
> It seems making a co
OK. I found the source. Yes, that is fairly straightforward to copy and modify.
It seems making a copy without propagating the raster bands would be
very common operation. Would it make sense to introduce a new function
to GDAL? ShallowCopy?
THK
On Sat, Aug 21, 2010 at 7:05 PM, Tim Keitt wrote
modifying GDALDriver::DefaultCreateCopy()
>
> On Sat, Aug 21, 2010 at 9:51 PM, Tim Keitt wrote:
>>
>> I am writing a utility that takes a raster as input and outputs a
>> raster with all attributes the same, except that I only want one
>> output band and I want to s
I am writing a utility that takes a raster as input and outputs a
raster with all attributes the same, except that I only want one
output band and I want to specify its type independent of the data
type in the input file. Is there a function that creates a copy of a
dataset (or creates a virtual da
Oops. Sorry folks. It works after a small bug fix in the algorithm.
THK
On Tue, May 18, 2010 at 11:40 AM, Frank Warmerdam wrote:
> Tim Keitt wrote:
>>
>> I have some GDAL code that does:
>>
>> open input dataset
>> create copy to output dataset
>> clos
I have some GDAL code that does:
open input dataset
create copy to output dataset
close input dataset
get raster band from output
call RasterIO(GF_Read,...) on band
update buffer in place
call RasterIO(GF_Write,...) on band
close output dataset
exit
The program runs, but the output dataset contai
44 matches
Mail list logo
