Even suggestions worked for me,
I am working on code that can ease the process of doing that
https://github.com/satellogic/telluric/blob/get_tile_aligned/telluric/georaster.py#L1344
I will update when it is done
After working with that I realized that now I have a new question. How
deep(low) to
Hi guys,
I am working on a tileserver use case on top of cogs.
I want to find a cache mechanism to my architecture.
The tile-server architecture is several python processes(gunicorn) running
on several VMs.
I understand how GDAL caches the curl blocks or the raster using
intra-process caching,
>
> In the first two cases (without OLCCurveGeometries set) I see
> curveToLineString is being called when there are curves in the data, but
> not on every result page (again curves are relatively rare in the dataset).
ok, then replace the call to OGRMemLayer::SetFeature() with
OGRMemLayer::ISet
On Mon, Jun 25, 2018 at 4:14 PM, Even Rouault
mailto:even.roua...@spatialys.com>> wrote:
> > If my memories are right, you only need to set it for write
support. So
> > shouldn't be needed there.
>
> All I know is that without it set, the curved geometries were
linearized
Hi,
Following a discussion with 'velix' on IRC who pointed to me the pigz utility
( https://zlib.net/pigz/ ) that does multi-threaded compression of gzip files,
I've committed in GDAL master a similar mechanism in the /vsigzip/ and
/vsizip/ virtual file systems. If you set GDAL_NUM_THREADS to a va
Andreas;
Thank you for your suggestion.
How would this workflow handle
*
multiple import operations spread over time into the same database
and schema? The first import will yield a number of tables
depending on data. The second import will need to determine which
tables alre
Andreas;
Thank you for your suggestion.
How would this workflow handle
*
multiple import operations spread over time into the same database and schema?
The first import will yield a number of tables depending on data. The second
import will need to determine which tables already contain a tr
