On 23 June 2015 at 16:02, Even Rouault wrote:
> Luca,
>
Hi Even,
>>
>> I'm writing a function to cycle inside the feature and update a column
>> of attribute table, if I print the feature with DumpReadable() I can
>> see the right attributes but when the script finish the final
>> shapefile has
Hi All,
I have a geotiff file like:
[] ~/work/oceandata/test$ gdalinfo A2015173174000.L0_LAC.L2_OC.tif -noct
Driver: GTiff/GeoTIFF
Files: A2015173174000.L0_LAC.L2_OC.tif
A2015173174000.L0_LAC.L2_OC.tif.aux.xml
Size is 2433, 1727
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
Kor,
I'm half surprised this ended up being broken. At the time of
https://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification, it still worked
apparently but I might have accidentaly broken it later.
Anyway I was wondering if it was worth fixing that? as it might be a continuing
maintenance
Dennis,
I believe this would be good material for a ticket, if there isn't one already
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/list
Dear all,
I may have found an issue in the build scripts of gdal 2.0.0. Building
gdal without ogr on Linux fails on my machine:
./configure --without-ogr
make -j8
I attached the output of configure and copied the snippets from the
build output detailing the errors below.
When I change --wi
On 2015-06-23 10:06 AM, Even Rouault wrote:
Le vendredi 19 juin 2015 09:52:30, Even Rouault a écrit :
Hi,
As no points have been raised on the RFC:
Motion : I move to adopt RFC 26: GDAL Block Cache Improvements
https://trac.osgeo.org/gdal/wiki/rfc26_blockcache
Starting with my +1
Hi,
Just
Hi guys,
following the discussion
http://thread.gmane.org/gmane.comp.gis.gdal.devel/40628 I did some tests
with a pleiades dataset.
First of all, Astrium’s very own tool (which now vanished from their page)
to convert the pleiades RPC*.XML to _RPC.TXT did not change SAMP_OFF and
LINE_OFF accord
Le vendredi 19 juin 2015 09:52:30, Even Rouault a écrit :
> Hi,
>
> As no points have been raised on the RFC:
>
> Motion : I move to adopt RFC 26: GDAL Block Cache Improvements
>
> https://trac.osgeo.org/gdal/wiki/rfc26_blockcache
>
> Starting with my +1
Hi,
Just a reminder this motion is sti
Luca,
>
> I'm writing a function to cycle inside the feature and update a column
> of attribute table, if I print the feature with DumpReadable() I can
> see the right attributes but when the script finish the final
> shapefile has no attribute table, any idea?
>
> This is the relevant part of c
Sorry wrong link. This is the dimap pleiades test dataset:
https://drive.google.com/file/d/0B_pKTK9WcAW4RktQUEE2bzVDdGM/view?usp=sharing
On Tue, Jun 23, 2015 at 3:43 PM, Dennis Gocke wrote:
> Hi guys,
>
>
>
> following the discussion
> http://thread.gmane.org/gmane.comp.gis.gdal.devel/40628 I d
Hi devs,
I'm writing a function to cycle inside the feature and update a column
of attribute table, if I print the feature with DumpReadable() I can
see the right attributes but when the script finish the final
shapefile has no attribute table, any idea?
This is the relevant part of code
feature
Hello,
now, for Layer.GetName() I need to use:
Encoding.UTF8.GetString(Encoding.Default.GetBytes(layer.GetName()));
to have correct characters.
Is it a subject of this issue?
Ivo.
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-OGR-C-wrapper-and-UTF8-tp5044
Even, Ray, thanks for the answers
22.06.2015 23:28, Ray Gardener пишет:
The functions are to allow mapping between logical and physical pixel
values. This is very common in e.g. elevation DEMs.
Applying them is done by the calling code. At least, I haven't seen
any routines in GDAL that
woul
13 matches
Mail list logo
