[gdal-dev] RGB to PALETTE conversion

[Paulo Pires]

Hello,

I'm trying to convert RGB image to PALETTE image with PIL:

/img = Image.open(tiffile)
img = img1convert("P", palette=Image.ADAPTIVE, colors=256)
img.save(newtiffile+"_index.tif") 
img.close()/

...but, for example, the white color is 245, not 255 :(

And from CMYK to PALETTE? Is it possible? gdal option, please...

Thanks




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] compulation error in trunk

[Martin Landa]

2018-01-23 13:40 GMT+01:00 Even Rouault :
> I just committed this fix

thanks, Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] compulation error in trunk

[Even Rouault]

On mardi 23 janvier 2018 13:36:44 CET Martin Landa wrote:
> Hi,
> 
> I have problem compiling GDAL trunk on my Debian unstable machine:
> 
> gdalwarpkernel_opencl.cpp: In function '_cl_kernel*
> get_kernel(oclWarper*, char, double, double, double, double, int, int,
> int, int, cl_int*)':
> gdalwarpkernel_opencl.cpp:1278:30: error: 'numeric_limits' is not a
> member of 'std'
>  dstMinVal = std::numeric_limits::lowest();
> 
> gcc --version
> gcc (Debian 7.2.0-19) 7.2.0
> 
> ocl-icd-libopencl1/unstable,testing,now 2.2.12-1 amd64 [installed]
> 
> In my case helped adding  header into
> gdalwarpkernel_opencl.cpp. Should I fill a bug report? Ma

Martin,

I just committed this fix

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] compulation error in trunk

[Martin Landa]

Hi,

I have problem compiling GDAL trunk on my Debian unstable machine:

gdalwarpkernel_opencl.cpp: In function '_cl_kernel*
get_kernel(oclWarper*, char, double, double, double, double, int, int,
int, int, cl_int*)':
gdalwarpkernel_opencl.cpp:1278:30: error: 'numeric_limits' is not a
member of 'std'
 dstMinVal = std::numeric_limits::lowest();

gcc --version
gcc (Debian 7.2.0-19) 7.2.0

ocl-icd-libopencl1/unstable,testing,now 2.2.12-1 amd64 [installed]

In my case helped adding  header into
gdalwarpkernel_opencl.cpp. Should I fill a bug report? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Vector Tiles in OGR

[Even Rouault]

On mardi 23 janvier 2018 13:10:30 CET Jaak Laineste wrote:
> Hey,
> 
> I read the drv doc, it was not completely clear how OGR handles exactly
> multi-resolution specifics; as OGR data model does not really “support”
> multi-resolution vector in data model level AFAIK.

Indeed, there's no particular handling of multi-resolution in the MVT driver. 
Meaning it is the 
responsibility of the user to open the zoom level it is interested in.

( For the MBTiles driver, I've added a ZOOM_LEVEL_AUTO=YES open option:
"""Whether to auto-select the zoom level for vector layers according to the 
spatial filter 
extent. Only for display purpose. Defaults to NO""")

> 
> I guess it works in this way:
> a) if you set Z= option, e.g. Z=10, then it takes data for zoom 10.

No, X, Y, Z open options are only useful if you point to a single .pbf / .mvt 
file whose path + 
name doesn't contain any hint on the tile coordinate.

To point to a tileset at a particular zoom level, you need to open 
"directory/{zlevel}"

> b) in other cases it extracts data for all zooms, which means with typical
> multi-zoom/resolution tileset you end up with up to N (=number of zoom
> levels) geometries per object. If geometries would have generated field for
> tile address (xyz) then consumer can decide which copy to be used,
> otherwise it may become quite unusable mess.

No, only one zoom level is opened. See above

> 
> p.s. there is no geometry merging across tiles, right?

Yep, that's what i meant with
"""Note: When opening a zoom level of a tileset, the driver will make no effort 
of stiching 
together geometries for features that overlap several tiles."""

> I imagine this to be
> useful either based on coordinate connections, and/or unique object id
> field.

Geometry merging could potentially be done, but it was left aside for now, 
because it can 
involve huge processing time. Imagine in the worst case, you have a single 
polygon covering 
the whole world at zoom level 15: to read it, you will need to merge the 2^30 
tiles ...
So geometry merging should probably be an option not enabled by default, and 
used 
together with reasonable spatial filter.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Map Algebra revisited

[Alex HighViz]

Hi Ari,

Even if the development of the code for RFC62 has turned out to be more complex 
than initially envisioned, I think it remains a good diagnosis of functionality 
that is missing in GDAL. The use of multiprocessing in  Perl is very 
interesting, however I don't think it addresses the issues you originally 
raised in RFC62. If only, because it is not C++.

I think there is scope for a more abstract interface on top of GDALRasterBand 
that makes it easier to write algorithms on raster data in C++. It would 
benefit users of GDAL (I suppose especially research oriented users). It might 
also benefit GDAL itself, because the issues of data access and algorithm can 
be better separated. For instance, the implementation of the Euclidean distance 
transform in gdalproximity.cpp or the raster statistics computation in 
gdalrasterband.cpp could both benefit from such conceptual tidying up. Having a 
clearer separation of data access and algorithm might even illuminate the path 
towards parallel processing for those and other tasks.

Kind regards, Alex
--
Alex Hagen-Zanker
Blink Raster: https://github.com/ahhz/raster


From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma
Sent: 23 January 2018 08:25
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Map Algebra revisited


Alex,

Thanks for the information. I wrote the RFC and I wrote the C++ add-on that's 
linked to the RFC. However, in the end I run out of time with that code. Later 
also Mario Roy took up the challenge of multiprocessing raster operations with 
Perl GDAL and got good results(1).

Perhaps the appropriate thing would be to start a GDAL raster 
processing/algebra page on the GDAL Wiki and write there about solutions. The 
RFC should direct to that page.

Best,

Ari

1) https://gist.github.com/marioroy

Alex HighViz kirjoitti 22.01.2018 klo 17:40:

Dear all,



I would like to re-open an older discussion. At several points in the last year 
there has been a discussion of raster algebra / map algebra functionality on 
this list. There still is an associated RFC by Ari Jolma 
(https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra).



The reason to re-open the discussion is that I have recently submitted a C++ 
library  called Blink Raster to OSGeo to be considered as a Community project. 
The project is hosted on Github (https://github.com/ahhz/raster ). Note that 
there is already quite some documentation, including main concepts, functions 
and examples.



Blink Raster meets the requirements specified in RFC62:



>  "The implementation should be data type aware. This may mean code written 
> with templates. "

The main expected  use of the library is where the user knows the datatype, and 
specifies it in a template.



> "The implementation should be parallel processing friendly. "

The  implementation uses expression templates to specify operations on rasters 
that are lazily evaluated. The interface facilitates evaluating the expression 
templates only for subrasters. It is therefore a solution that should works 
well with the split-and-merge approach to parallel processing.



> " The implementation should allow a relatively easy to use C++ / C API. This 
> may mean interface, which does not use templates. "

The interface with templates is pretty simple. However, at a performance cost, 
it is also possible to apply map algebra operations without specifying the data 
type.



> "The implementation should allow arbitrary functions on cell values. I.e., be 
> extensible by the user."

The implementation allows arbitrary functions on cell values

> "The implementation should allow focal methods. I.e., methods, where the 
> value of a cell depends on its neighborhood."

The implementation offers square and circular moving window methods for 
neighbourhoods of pixels and edges (adjacent pixel pairs). This is also 
extendable by the user and it is relatively straightforward to write your own 
statistic to be applied in a moving window. This was my original motivation for 
this library: to be able to easily write efficient moving window based 
indicators of landscape patterns.



With apologies for re-opening a discussion that is only sideways related to 
GDAL as well as the self-promotion. Since in the end this is about a C++ 
geo-data abstraction library, I felt it was appropriate.



I would appreciate any feedback and ideas for the library. I would also be 
interested to hear if you think this library addresses a GDAL need.



With kind regards, Alex



p.s. I had to resend this email from a second email address, due to the 
following:  https://trac.osgeo.org/osgeo/ticket/2087



--

Alex Hagen-Zanker







___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org

Re: [gdal-dev] Map Algebra revisited

[Ari Jolma]

Alex,

Thanks for the information. I wrote the RFC and I wrote the C++ add-on 
that's linked to the RFC. However, in the end I run out of time with 
that code. Later also Mario Roy took up the challenge of multiprocessing 
raster operations with Perl GDAL and got good results(1).


Perhaps the appropriate thing would be to start a GDAL raster 
processing/algebra page on the GDAL Wiki and write there about 
solutions. The RFC should direct to that page.


Best,

Ari

1) https://gist.github.com/marioroy


Alex HighViz kirjoitti 22.01.2018 klo 17:40:


Dear all,

I would like to re-open an older discussion. At several points in the 
last year there has been a discussion of raster algebra / map algebra 
functionality on this list. There still is an associated RFC by Ari 
Jolma (https://trac.osgeo.org/gdal/wiki/rfc62_raster_algebra).


The reason to re-open the discussion is that I have recently submitted 
a C++ library  called Blink Raster to OSGeo to be considered as a 
Community project. The project is hosted on Github 
(https://github.com/ahhz/raster ). Note that there is already quite 
some documentation, including main concepts, functions and examples.


Blink Raster meets the requirements specified in RFC62:

>  "The implementation should be data type aware. This may mean code 
written with templates. "


The main expected  use of the library is where the user knows the 
datatype, and specifies it in a template.


> "The implementation should be parallel processing friendly. "

The  implementation uses expression templates to specify operations on 
rasters that are lazily evaluated. The interface facilitates 
evaluating the expression templates only for subrasters. It is 
therefore a solution that should works well with the split-and-merge 
approach to parallel processing.


> " The implementation should allow a relatively easy to use C++ / C 
API. This may mean interface, which does not use templates. "


The interface with templates is pretty simple. However, at a 
performance cost, it is also possible to apply map algebra operations 
without specifying the data type.


> "The implementation should allow arbitrary functions on cell values. 
I.e., be extensible by the user."


The implementation allows arbitrary functions on cell values

> "The implementation should allow focal methods. I.e., methods, where 
the value of a cell depends on its neighborhood."


The implementation offers square and circular moving window methods 
for neighbourhoods of pixels and edges (adjacent pixel pairs). This is 
also extendable by the user and it is relatively straightforward to 
write your own statistic to be applied in a moving window. This was my 
original motivation for this library: to be able to easily write 
efficient moving window based indicators of landscape patterns.


With apologies for re-opening a discussion that is only sideways 
related to GDAL as well as the self-promotion. Since in the end this 
is about a C++ geo-data abstraction library, I felt it was appropriate.


I would appreciate any feedback and ideas for the library. I would 
also be interested to hear if you think this library addresses a GDAL 
need.


With kind regards, Alex

p.s. I had to resend this email from a second email address, due to 
the following: https://trac.osgeo.org/osgeo/ticket/2087


--

Alex Hagen-Zanker



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev