Hi all,
I finally got the problem: there was a mistake within my ld.so.conf.d file
that linked the libgdal into the system.
For the record, my mistake was to put the full path to the file:
$ cat /etc/ld.so.conf.d/gdal.conf
/usr/local/lib/libgdal.so.1
I resolved the problem by modifying /etc/l
Dear GDAL gurus,
I'm using GDAL bindings with R through the rgdal package
[http://cran.r-project.org/web/packages/rgdal/index.html]. After I built the
last stable GDAL from source, I'm unfortunately unable to reinstall this
package in R. The rgdal compilation stops and says:
During compilation:
On Mon, Jul 19, 2010 at 3:46 PM, Frank Warmerdam wrote:
>
> Would GetFeature() still return a feature with a full vector of
> fields, but those not desired just being left in the null state?
> If so, I think such an approach would be reasonable. However, it will
> require an RFC process to update
Hi folks, I'm trying to use GDAL in a dll we're writing so that we can forgo
using ENVI to open our data files. I'm able to determine the image data
dimensions and acquire access to the data by doing something like the
following:
// Read file:
GDALDataset *fileData = (GDALDataset*
On Mon, Jul 19, 2010 at 7:54 PM, Frank Warmerdam wrote:
> Martin Dobias wrote:
>> One note to avoid confusion: the suggestion I've made above relates
>> only to shapefile driver in OGR and doesn't impose any changes to the
>> API. The suggested patch reuses OGRShape instances which are passed
>> b
On Mon, Jul 19, 2010 at 10:54 AM, Frank Warmerdam wrote:
> Ragi Burhum wrote:
>
>> Would it make sense instead of implementing a SetDesiredFields(..) to
>> implement a SetSubFields(string fieldnames) where the function
>> takes a comma delimited list of subfields and then those are parsed by the
>
Gregory, Matthew wrote:
Hi all,
Is there a way to set a 'snap' coordinate for a target dataset in gdalwarp
without having to know the target extent? For example, if I wanted my
target dataset to have extent corners that were a multiple of my cellsize, I
could specify (0.0, 0.0) as my snap coord
Ragi Burhum wrote:
Would it make sense instead of implementing a SetDesiredFields(..) to
implement a SetSubFields(string fieldnames) where the function
takes a comma delimited list of subfields and then those are parsed by
the shapefile driver to find out which field values to fetch? That way,
On Mon, Jul 19, 2010 at 6:50 PM, Ragi Burhum wrote:
>> >> 1. allow users of OGR library set which fields they really need. Most
>> >> of time is wasted by fetching all the attributes, but typically none
>> >> or just one attribute is necessary when rendering. For that, I've
>> >> added the followi
>
> Date: Mon, 19 Jul 2010 16:34:40 +0200
> From: Martin Dobias
> Subject: Re: [gdal-dev] Optimizing access to shapefiles
> To: Frank Warmerdam
> Cc: gdal-dev@lists.osgeo.org
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Frank
>
> On Mon, Jul 19, 2010 at 3:46 PM, F
Hi all,
Is there a way to set a 'snap' coordinate for a target dataset in gdalwarp
without having to know the target extent? For example, if I wanted my target
dataset to have extent corners that were a multiple of my cellsize, I could
specify (0.0, 0.0) as my snap coordinate. In Arc, this is
Nathan,
OGRSFDriver::CopyDataSource() may help you. You won't have all the fancy
options ogr2ogr provides but you will be able to create a copy of the
shapefile.
On Mon, Jul 19, 2010 at 8:16 PM, nlraley wrote:
>
> I hope I'm posting in the right group.
>
> I am trying to use the conversion capab
I hope I'm posting in the right group.
I am trying to use the conversion capabilities of ogr2ogr to convert a
shapefile to kml format so I can basically have a user select a shp file and
automatically convert it without having them go to the command prompt and
type out the commands or any of that
Hi Frank
On Mon, Jul 19, 2010 at 3:46 PM, Frank Warmerdam wrote:
>> 1. allow users of OGR library set which fields they really need. Most
>> of time is wasted by fetching all the attributes, but typically none
>> or just one attribute is necessary when rendering. For that, I've
>> added the follo
Martin Dobias wrote:
Hi,
in order to speed up rendering in QGIS as a part of my GSoC project,
I've took some time to profile reading of shapefiles in OGR. From the
results I'd like to suggest some changes that significantly contribute
to the speed of data retrieval. On a test shapefile of a road
Martin,
These changes look quite promising. Please add two tickets at
http://trac.osgeo.org/gdal/newticket , one for each topic, and attach the
patch.
On Mon, Jul 19, 2010 at 5:38 PM, Martin Dobias wrote:
> Hi,
>
> in order to speed up rendering in QGIS as a part of my GSoC project,
> I've took
Hi,
in order to speed up rendering in QGIS as a part of my GSoC project,
I've took some time to profile reading of shapefiles in OGR. From the
results I'd like to suggest some changes that significantly contribute
to the speed of data retrieval. On a test shapefile of a road network
(about 100 tho
Dear All,
as a step towards a solution where the output is to Oracle, I have just
submitted enhancement ticket 3690. This describes edits to ogrocidatasource and
ogrocitablelayer to enable the creation of non-spatial tables (ie omitting the
geomentry column) if a geometry type of wkbNone i
18 matches
Mail list logo
