+1
Tamas
2013/6/12 Frank Warmerdam
> Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
>
> ---
>
> Wolf would like to work on OGR GME support with me, and the easiest place
> to collaborate would be in GDAL SVN. Wolf has been a long time contributor
> to GRASS and I would review his
I was hacking gdal2tiles a bit by running pnqnq of a base tile
immediately after creating it (I want to be able to run partial updates
on a TMS which has been pngnq optimised). No problem with that, but
updating the overview tiles produces issues. It does
writeraster(..,readraster()) on
+1
Daniel
On 13-06-12 5:09 PM, Frank Warmerdam wrote:
Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
---
Wolf would like to work on OGR GME support with me, and the easiest
place to collaborate would be in GDAL SVN. Wolf has been a long time
contributor to GRASS and I would revie
Hi all. I agree to the RFC-3 and agree to following it. Sorry about the
empty email before...
--Wolf on Android
The usual disclaimer about phones goes here.
On 13 Jun 2013 00:12, "Mutlu Ozdogan" wrote:
> I concur
>
> On 6/12/13 4:09 PM, Frank Warmerdam wrote:
>
> Motion: Extend GDAL/OGR commi
--Wolf on Android
The usual disclaimer about phones goes here.
On 13 Jun 2013 00:12, "Mutlu Ozdogan" wrote:
> I concur
>
> On 6/12/13 4:09 PM, Frank Warmerdam wrote:
>
> Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
>
> ---
>
> Wolf would like to work on OGR GME support with me, a
I concur
On 6/12/13 4:09 PM, Frank Warmerdam wrote:
Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
---
Wolf would like to work on OGR GME support with me, and the easiest
place to collaborate would be in GDAL SVN. Wolf has been a long time
contributor to GRASS and I would review
Even,
Sorry, after I left work I realised that I had forgotten to reply to the last
part of your mail.
"I've pushed a fix in the dev version so that the progress bar appears in the
second case (SQL with 0 resulting rows)."
Thank you so much! It's brilliant that you were able to get a fix for th
On Jun 12, 2013, at 4:16 PM, Even Rouault wrote:
> Le mercredi 12 juin 2013 23:09:33, Frank Warmerdam a écrit :
>> Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
>
> +1 Even
+1 Howard
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http
Le mercredi 12 juin 2013 23:09:33, Frank Warmerdam a écrit :
> Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
+1 Even
>
> Best regards,
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
Motion: Extend GDAL/OGR commit access to Wolf Bergenheim.
---
Wolf would like to work on OGR GME support with me, and the easiest place
to collaborate would be in GDAL SVN. Wolf has been a long time contributor
to GRASS and I would review his early GDAL commits.
I'll start the voting with:
+1
Le mercredi 12 juin 2013 21:05:42, Graeme B. Bell a écrit :
> Even,
>
> Thank you for your very kind explanation of a probable origin for the bug
> I've described.
>
> Regardless of the point in the GDAL infrastructure that the bug is occuring
> at, it appears that gdal_rasterize (as a whole) is
Even,
Thank you for your very kind explanation of a probable origin for the bug I've
described.
Regardless of the point in the GDAL infrastructure that the bug is occuring at,
it appears that gdal_rasterize (as a whole) is prone to unpredictably writing
data values in places where there is no
Le mercredi 12 juin 2013 19:58:20, Graeme B. Bell a écrit :
> Also:
>
> (using -init 255 will produce a TIFF with suitable nodata values in the
> second scenario I described, as a workaround.
>
> However, gdal_rasterize still does not produce correct command line output
> in this situation, and a
Program version:
gdal_rasterize --version
GDAL 1.10.0, released 2013/04/24
Apologies for spreading the information across 3 emails.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Also:
(using -init 255 will produce a TIFF with suitable nodata values in the second
scenario I described, as a workaround.
However, gdal_rasterize still does not produce correct command line output in
this situation, and also it should not be necessary for users to manually add a
-init optio
Summary:
I noticed that gdal_rasterize invents data values instead of burning nodata
values, incorrectly, in what is probably a common situation - a valid query
returning geometry columns but zero polygon rows.
Command line output suggests that nothing is being done, yet a GeoTIFF with
data
Dear List,
I would like to reproject METOP SST data (satellite data which are swath
data granules stored in the netcdf file) with GDAL geolocation arrays.
I have run the followings commands using Gdal 1.6.0:
1. Here I extract the subsetdata. The same command is used for latitude and
longitud
17 matches
Mail list logo
