Re: [gdal-dev] Gdaltransform hangs sometimes after being idle

[Jukka Rahkonen]

Rahkonen Jukka (MML  maanmittauslaitos.fi> writes:

> 
> Hi,
> 
> I can reproduce now. GDAL is 64-bit 2.1-dev from
http://download.gisinternals.com/sdk/downloads/release-1600-x64-gdal-mapserver.zip

Sorry, after further tests the problem with closing the program still
happens only occasionally. Quite often I can see a "R6016 not enough space
for thread data". It may something similar than in this thread:


http://stackoverflow.com/questions/21127460/resolving-error-r6016-not-enough-space-for-thread-data

Conclusions from that thread:
"This turned out to be caused by calling CreateThread rather than _beginthread."
"You have to call TlsAlloc in DllMain if the Windows version is Vista or
higher."

I think I will stop my investigations because this in not at all a critical
issue for me.

-Jukka-

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

Re: [gdal-dev] GDAL testing

[Dmitry Baryshnikov]

Hi Kurt,

During code sprint in Korea (FOSS4G 2015) I plan to play with new 
approach of CMake fro GDAL. The one of experiments will be try to use 
CTest. As I plan restructure the sources tree, I can try to integrate 
you work on autotest2 and CTest. Also we can try to create new test 
directory structure more compatible for test and sources tree (this is 
about you wrote: Probably should move python code to also match the C++ 
tree.  e.g.  tiff_read_test.py -> 
autotest2/py/frmts/gtiff/tiff_read_test.py).

How can get you tests? What do I need to use autotest2?

Best regards,
Dmitry

05.09.2015 20:37, Kurt Schwehr пишет:

(Subject change to focus on testing)

Hi all,

First off... what GDAL has with autotest, travis-ci and coverity is 
awesome!


Thoughts / discussion more than welcome!

For my production work, I'm not able to use the autotest python code 
because of its non-unittest architecture.  So... I started creating 
python unittest and C++ gunit based tests.  I use autotest2 in 
Google's internal continuous integration system in our main code 
base.  I'm using Google's build system... I've got nothing started for 
running the C++ tests outside of Google.


Apologies for not even getting out at least samples of autotest2 for 
folks to inspect and comment on.  My intention is to put what I have 
in a git repo and the to start discussions as to what (if anything) 
GDAL community wants to do with autotest2.I was hoping to get a 
lot more coverage and get GDAL 2.x.x support, but that will have to 
come later. It's only 14K lines at this point (optimistically 2-3% 
done), but it has been a huge help for me especially with in upgrading 
versions of gdal and catching bugs in support libs & development 
toolchains.


The tests are more focused on test isolation than autotest.  This 
allows for a lot more parallelism in testing.  e.g.  It's fair game to 
run all tests at the same time on the same machine.


find . -name \*.py | xargs wc -l | tail -1
 10684 total

find . -name \*.cc -o -name \*.h | xargs wc -l | tail -1
  3734 total

Where GDAL's autotest is 204K lines:

find . -name \*.py | xargs wc -l | tail -1
  193994 total
find . -name \*.c\* -o -name \*.h | xargs wc -l | tail -1
   10471 total

Here are some samples:

C++ tests use  C++11, gunit, google logging, gflags:  (Hoping for 
C++14 soon.. e.g. make_unique)
- autotest2/cpp/port/cpl_conv_test.cc 
 (Yes, this is 
massively boring code)
- autotest2/cpp/ogr/ogrpoint_test.cc 

- autotest2/cpp/ogr/ogrsf_frmts/geojson/geojson_test.cc 



Python pretty much follows the autotest layout, but with util files in 
the same directory.  Assumes python 2.7 or >= 3.4 (have not tried py3 yet)
- autotest2/gcore/gcore_util.py 

- autotest2/gdrivers/gdrivers_util.py 

- autotest2/gdrivers/tiff_read_test.py 
 (I'm leading 
towards moving driver tests in gcore to gdrivers)
- autotest2/ogr/geojson_test.py 



Probably should move python code to also match the C++ tree.  e.g.

tiff_read_test.py -> autotest2/py/frmts/gtiff/tiff_read_test.py

I'm (mostly) following Google's style guides.  Public versions here: 
C++  
Python 


All C++ should be formatted with "clang-format --style=Google"

What does autotest2 not do?

Would like to eventually do (unsorted):
- Test error handling on a range of corrupt data sources
- Fuzz testing, ASAN/MSAN/TSAN/Valgrind/Heap checks  (I've done some 
MSAN & heap checkers by hand)

- Performance testing - time and memory usage
- Test the C API at the C level
- Test platforms other than Linux (MS Win*, Mac OSX, Android, iOS, 
other embedded oses, BSD*, Solaris, HPUX, etc)

- Have more detailed language binding tests for java, ruby, perl, php
- Coverage checking
- Test parallel processing and multithreading
- Test networking (I need to think through isolation)
- Test multiple configurations (e.g. all drivers and features enables 
vrs minimal build).

- Check which system calls are used by each driver for read and for write
- Check i18n support.
- Check distribution packaging
- Validating that the given build options result in the expect 
available features


Probably out of scope:
- Test for support from older platforms & C++ older than C++11
- Actual sandbox checks
- Test other bindings to GDAL's C or C++ API such as Fiona & Shapely
- Integration tests (e.g. GRASS, QGIS, mapserv, GeoDjango, etc).
- ABI compatibility checks
- Older versions of dependent libs e.g. netcdf/hdf4/5, kakadu, 
openjpeg, etc.


-kurt
Engineer at Google

Re: [gdal-dev] tiled vector map

[Ahmet Temiz]

Thank you Jukka for your interest.

In my system, I intend to do that, specifically for our huge road map.

regards

On Sat, Sep 5, 2015 at 9:47 PM, Jukka Rahkonen <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Ahmet Temiz  gmail.com> writes:
>
> >
> >
> > hello
> >
> > Is it possible to create tiled vector map with ogr ?
>
> It depends on what you mean with tiled vector maps. Do you mean for example
> something from this list http://wiki.openstreetmap.org/wiki/Vector_tiles
> or
> do you plan to develop your own system?
>
> -Jukka Rahkonen-
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Ahmet Temiz
Jeoloji Müh.
Afet ve Acil Durum Yönetimi Başkanlığı
Bilgi İşlem  Dairesi Başkanlığı-CBS Grubu




Ahmet Temiz
Geological Eng.
Information Systems - GIS Group
Disaster and Emergency Management
of Presidency
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev