round this problem I am more then willing to lend my expertise.
Thanks,
Blake Thompson
On Wed, Feb 14, 2018 at 10:53 AM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Even Rouault wrote:
>
> > Perhaps you could play with the SIMPLIFICATION and
> SIMPL
and check
them in on occasion (such as after big changes or before releases)
- Optimize the style for reading now for writing of the code
- If you want to be really strict you can have style checked as part of
testing (I am not personally a huge fan of this).
Thanks,
Blake Thompson
On Fri, May 5,
ions. This was especially true when I
was writing 2.0 of the specification as I tried to limit what would be
considered even the most common uses of vector tiles.
Thanks,
Blake Thompson
On Mon, Feb 1, 2016 at 4:27 PM, Stefan Keller wrote:
> Hi Ben
>
> Thanks for explaining -
Even,
He is correct that MBTiles can store vector tiles. I know this is done in
https://github.com/mapbox/tippecanoe . I believe there is talk about
updating the MBTiles Spec as well.
Thanks,
Blake Thompson
On Tue, Jan 5, 2016 at 2:21 PM, Even Rouault
wrote:
> Le mardi 05 janvier 2016 19
time to do this properly.
If you have any questions specifically about Mapnik Vector Tile or the
Mapbox Vector Tile Specification feel free to ask me. I would note that you
guys will want to update your vector tiles once the V2 specification
changes are into Mapnik-Vector-Tile.
Thanks,
Blake Tho
u see the same problem with hCOAMutex?
> > It would be good if i could say: give me per dataset cache, open this
> dataset
> > with no locking. Unless the global cache provides its operations with
> less
> > sleeping.
> >
> > Regards.
> > Jacek Tomaka
> >
Even and Andre,
> I want to start off by saying a big thanks to Blake for taking his time
> > to tackle what can only be a very difficult problem.
> > From what I can observe, the current discussion seems to be around the
> > boundary of who should be responsible for ensuring thread safety around
Even,
> Yeah, that why was I suggested the reverse ;-) But an automatic renaming
> should be doable.
> Another danger of keeping IReadBlock and making it now responsible of
> ensuring
> its thread safety is for out-of-tree drivers that wouldn't realize they
> need
> to change something as code wou
Even,
The naming is perhaps not well choosen, but the documentation of the
> contract
> of this API should make it clear on what an implementation should do and
> what
> it should not do.
>
Perhaps it should be reversed? IReadBlock and IReadBlock_not_thread_safe?
(would obviously require lots of
Even,
On Fri, Aug 22, 2014 at 1:33 PM, Even Rouault
wrote:
>
>
> Note: after re-reading, I realize that I misread your above sentence as "it
> will work to translate multiple datasets in a parallel way with a *per-
> dataset* cache").
>
> So, even if you didn't write it, I'm afraid that people wi
Even,
> This might be a problem in practice since the amount of cache might grow
> quickly. By default a VRT will open simultaneously up to
> GDAL_MAX_DATASET_POOL_SIZE (whose default is 100, but can be changed at
> runtime with the config option) source datasets.
> If you do a gdal_translate of
Kurt,
>
> With a 2 week old baby, my brain has been soggy.
>
Congrats!
>
> I do see the 3 threads here:
> http://lists.osgeo.org/pipermail/gdal-dev/2014-August/thread.html
>
> The asan/msan/tsan tools are
>
> asan - address sanitizer - https://code.google.com/p/address-sanitizer/
> msan - memor
Kurt,
On Fri, Aug 22, 2014 at 9:07 AM, Kurt Schwehr wrote:
> I've got threading issues on my list of things to investigate with GDAL.
> I've been running MSAN on GDAL lately and want to get TSAN going too. I'm
> out on leave this month, but hope to get more into this stuff (testing,
> threadin
Jeff,
Thanks Blake for the detailed response. I did not realize that I did not do
> a reply all in my previous email I sent.
>
Not an issue, glad you guys are interested in my changes.
>
> --> I thought that this was not possible using current trunk GDAL because
> of the global cache. At least t
Robert,
> I agree - from reading it seems like the major improvement is shifting
> away from a global, locking cache to a per-dataset cache. (ah. has been
> edited since you read it?)
>
Yes, I updated the RFC some yesterday after the email from Jeff Lacoste. He
forgot to hit reply all so it ende
should still be
faster then the current configuration.
TLDR; There are benefits in my design outside of just a non global cache
for datasets.
Blake Thompson
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Even,
I am not yet a commiter on SVN, but I agree with Tamas that allowing any
commiters would be a great. I personally think listing supporting companies
with an opensource project is a great way to build more support and trust
in the project.
Thanks,
Blake
On Wed, Aug 20, 2014 at 3:51 PM, Ta
Even,
Thank you very much for response to this, your helping me understand all of
this stuff has been very valuable.
I'm not sure the ratio gain/effort to make dataset methods "a bit more"
> thread
> safe is high enough. Very few drivers can be made fully thread-safe, and
> fully
> parallelized (
I wanted to call to everyone's attention the work I have been doing in an
attempt to make it possible for more portions of GDAL to be thread safe and
improve speed in multi-threaded environments. I have put a RFC up here:
http://trac.osgeo.org/gdal/wiki/rfc47_dataset_caching
Originally my work fo
19 matches
Mail list logo
