Re: [gdal-dev] Create a network

[Dmitry Baryshnikov]

Hi,

In case of polylines (i.e. road segments, single layer) - each polyline 
is vertex and edge is pure virtual (so it identifier is -1).


There are different cases, for example:

1. Water network with pipes (vertices) and edges (valves)

2. Road network - each road segment is vertex, edges are virtual

3. Product supply chain - warehouses, shops are vertices, edges may be 
virtual or real roads.


Best regards,
Dmitry

19.08.2020 14:38, marto salata пишет:

Thank you very much for your fast reply.
regarding step 2, i have a polyline shapefile, how to get the vertices 
required in step 3 so i can connect them.
i know the gfid in the imported shapefile, but from where i can get 
the vertices?


On Wed, Aug 19, 2020 at 11:25 AM Dmitry Baryshnikov 
mailto:bishop@gmail.com>> wrote:


Hi,

You need to follow these steps:

1. Create empty network

> gnmmanage.exe create -f GNMFile -t_srs "EPSG:4326" -dsco
"net_name=my_network_1" C:\tmp\gnmnetwork

2. Load your data

> gnmmanage.exe import lines.shp -l lines C:\tmp\gnmnetwork

Repeat for all your layers

3. Connect features to create network. Features identifiers set
while importing your spatial data. Use ogrinfo to check them.

> gnmmanage.exe connect 1 2 -1 C:\tmp\gnmnetwork

4. Perform shortest path using Dijkstra

> gnmanalyse.exe dijkstra 1 2 -ds shortestpath.shp -f "ESRI
Shapefile" -l shortestpath C:\tmp\gnmnetwork


Some links:

* https://trac.osgeo.org/gdal/wiki/geography_network_support

* https://nextgis.com/blog/gnm/ <https://nextgis.com/blog/gnm/>

* http://gsoc2014gnm.blogspot.com/

Best regards,
 Dmitry

19.08.2020 07:31, marto salata пишет:

dear GDAL team,
how  i can create a network using gnmmanage.exe from a polyline
shapefile, so i can perform a dijkstra with gnmanalyse.exe

best regards

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

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto: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

Re: [gdal-dev] Create a network

[Dmitry Baryshnikov]

Hi,

You need to follow these steps:

1. Create empty network

> gnmmanage.exe create -f GNMFile -t_srs "EPSG:4326" -dsco 
"net_name=my_network_1" C:\tmp\gnmnetwork


2. Load your data

> gnmmanage.exe import lines.shp -l lines C:\tmp\gnmnetwork

Repeat for all your layers

3. Connect features to create network. Features identifiers set while 
importing your spatial data. Use ogrinfo to check them.


> gnmmanage.exe connect 1 2 -1 C:\tmp\gnmnetwork

4. Perform shortest path using Dijkstra

> gnmanalyse.exe dijkstra 1 2 -ds shortestpath.shp -f "ESRI Shapefile" 
-l shortestpath C:\tmp\gnmnetwork



Some links:

* https://trac.osgeo.org/gdal/wiki/geography_network_support

* https://nextgis.com/blog/gnm/ 

* http://gsoc2014gnm.blogspot.com/

Best regards,
Dmitry

19.08.2020 07:31, marto salata пишет:

dear GDAL team,
how  i can create a network using gnmmanage.exe from a polyline 
shapefile, so i can perform a dijkstra with gnmanalyse.exe


best regards

___
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

Re: [gdal-dev] gdal_merge.py not executing or found

[Dmitry Baryshnikov]

Hi Jeremy,

You can install QGIS with GDAL and python bindings using alternative 
installer by NextGIS (http://nextgis.com/nextgis-qgis/).


GDAL python bindings working, gdal_merge also included.

This is previous QGIS LTR release 2.18.25, but with fresh GDAL 2.3.2 and 
other libraries. This installation should not affect you current QGIS 
install, but I'm not sure about the opposite.


Best regards,
Dmitry

07.11.2018 17:55, Jeremy Salerno пишет:

Thanks for the help Even.

Is there a simple way to check if the python bindings are installed? I
installed GDAL through the QGIS installer. I tried running gdal_merge.py
after downloading the file from github and have had no success.

--

Jeremy A. Salerno

Weston Geophysical Corp.
181 Bedford St. Suite #1
Lexington, MA. 02420
jsale...@westongeo.com



*www.westongeophysical.com* 



On Wed, Nov 7, 2018 at 9:28 AM Even Rouault 
wrote:


Jeremy,


I cannot even find the gdal_merge.py file in
/Library/Frameworks/GDAL.framework/Versions/Current/Programs/ or anywhere
else in the gdal framework directory.

Should be reported to the creator of the package. I believe this is
William Kyngesburye (CC'ed) but I'm not completely sure.



I looked to see if I could install
the .py file separately but can't find any installation options on the

GDAL

website.

You can always download the script from

https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/scripts/gdal_merge.py

(assuming that the GDAL Python bindings are installed)

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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Twenty years of GDAL !

[Dmitry Baryshnikov]

Happy birthday GDAL!

Best regards,
Dmitry

18.10.2018 4:51, Even Rouault пишет:

Hi,

I nearly missed it [1] (actually I'm already on the 18th here, but let's 
consider
Canadian time so still on the 17th), but exactly 20 years go on Oct 17th 1998,
Frank Warmerdam committed for the first time in the CSV repository.

'''
commit 149db916aafcbee9bb64572fafda83441c94a552
Author: Frank Warmerdam 
Date:   Sat Oct 17 19:24:36 1998 +

 Initial implementation.
 
 
 git-svn-id: https://svn.osgeo.org/gdal/trunk@2 f0d54148-0727-0410-94bb-9a71ac55c965

'''

https://github.com/OSGeo/gdal/commit/149db916aafcbee9bb64572fafda83441c94a552

169 lines for a first version of the virtual I/O layer...

Since then,
* 39075 commits have been added on top of it,
* 159 raster drivers
* 96 vector drivers [2]
* by 161 committers (actually there are more contributors, here just counting
   the ones who have directly authored a CVS, SVN or git commit),
* adding 7110 files in the repository, for a grand total of
* 2.192 millions lines in 3745 files with extensions c, cpp, h, hh, hpp, py,
   html, java, cs, i, pl, vc, sh, bat, dox, ac, GNUmakefile (80 MB) (all the 
text files)
   so an average of 300 lines per day added
* 64 releases
* 6287 tickets closed
* 49097 messages posted on gdal-dev
* more than 100 software proudly mentionning using it

Happy birthday and long life to GDAL and its commmnity of contributors, either
by code, documentation, testing, packaging, reports, ... !

Even

[1] thanks to Robert Coup for reminding me a few days ago about the approaching 
date !
[2] you'll note that 155 + 96 = 255, but I don't think there's a
 Byte limitation for the number of drivers ...



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

Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi,

I changed CPLJSONObject/CPLJSONArray  methods string parameters to 
std::string and merged last trunk changes.


Still leave 3 methods with const char* to simplify code because 
according to standard conversion sequence, methods with input (const 
char*, const char*) parameters executes method with signature 
(std:;string&, bool):


   Add("key", "value") --> Add(std::string osName, bool bValue)
   Set("key", "value") --> Set(std::string osName, bool bValue)

See notes in pull request 
(https://github.com/OSGeo/gdal/pull/282#issuecomment-355766795).

I'm ready to merge current pull request into the trunk.

Best regards,
Dmitry

05.01.2018 23:43, Kurt Schwehr пишет:

My preference (and not speaking for the gdal community) for C++ classes
would be:

1. replace const char * -> const std::string &
2. replace CPLString -> std::string

std::string GetString(const std::string , const std::string
 = "") const;

This is where it would be good to get input from others.

I base the above on maximizing safety while trying to let the compiler do
its best job at optimizing.  Then in about 2022, we can see about
std::string_view :(

On Fri, Jan 5, 2018 at 12:26 PM, Dmitry Baryshnikov <bishop@gmail.com>
wrote:


Hi Kurt,

Can you explain what should be done in PR?

Do you mean to replace all const char* to?

1. const char* -> const CPLString &

const char *GetString(const char *pszName, const char *pszDefault = "")
const; ->

CPLString GetString(const CPLString , const CPLString  =
"") const;

or

2. const char* -> const std::string &

const char *GetString(const char *pszName, const char *pszDefault = "")
const; ->

std::string GetString(const std::string , const std::string
 = "") const;

or?

Best regards,
 Dmitry

05.01.2018 18:54, Kurt Schwehr пишет:

+1 for wrapping the old C code in some cleaner abstractions!

But +10 for switching to a from the ground up C++ JSON library unless there
are clear reasons for a core C library (I don't think there are)

If we are talking about this kind of code, there are several things that
have bugged me in general about GDAL for a long time.

* Passing char *psz yada all over the place in pure C++ code.  A const
std::string is usually not a noticeable expense and is a lot safer
* CPLString when std::string will do just fine.  And we can write free
functions to operate on strings.  I'm generally bothered by subclassing of
std::string as CPLString.  After reading large amounts of C++ code, I think
it adds more confusion than it ever helps over having clean free
functions.  Interop and analysis with CPLString's is no fun.
https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies <s...@mapbox.com> 
<s...@mapbox.com> wrote:


Hi Dmitry,

I scanned the PR and it seems reasonable to me. I'm barely a C++
programmer at all and it's clear to me, more clear than before. That said,
I'm not a fan of wrapping things that could be replaced. Have you looked
into whether a more performant C++ JSON library could be used? I haven't
run the benchmarks, but json-c compares pretty poorly to others 
inhttps://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov <bishop@gmail.com> 
<bishop@gmail.com>
wrote:


Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request https://github.com/OSGeo/gdal/
pull/282

I created a thin wrapper around the json-c library which wide using in
GDAL.

This is C++ interface which hides C memory management and provides nice
API. The web or disk json documents reading chunk by chunk with progress
indication also added.

In future, the json-c can be easily switch to something other without
breaking the existing code.

The CPLJSONDocument/CPLJSONObject/CPLJSONArray usage examples can be
found in frmts/pds driver and c++ unit test in autotest/cpp/test_cpl.cpp.

Is this ready to merge into the trunk? Any objections?

Best regards,
 Dmitry


___
gdal-dev mailing 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Sean Gillies

___
gdal-dev mailing 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev








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

Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi Kurt,

Can you explain what should be done in PR?

Do you mean to replace all const char* to?

1. const char* -> const CPLString &

   const char *GetString(const char *pszName, const char *pszDefault =
   "") const; ->

   CPLString GetString(const CPLString , const CPLString
= "") const;

or

2. const char* -> const std::string &

   const char *GetString(const char *pszName, const char *pszDefault =
   "") const; ->

   std::string GetString(const std::string , const std::string
= "") const;

or?

Best regards,
Dmitry

05.01.2018 18:54, Kurt Schwehr пишет:

+1 for wrapping the old C code in some cleaner abstractions!

But +10 for switching to a from the ground up C++ JSON library unless there
are clear reasons for a core C library (I don't think there are)

If we are talking about this kind of code, there are several things that
have bugged me in general about GDAL for a long time.

* Passing char *psz yada all over the place in pure C++ code.  A const
std::string is usually not a noticeable expense and is a lot safer
* CPLString when std::string will do just fine.  And we can write free
functions to operate on strings.  I'm generally bothered by subclassing of
std::string as CPLString.  After reading large amounts of C++ code, I think
it adds more confusion than it ever helps over having clean free
functions.  Interop and analysis with CPLString's is no fun.

https://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies <s...@mapbox.com> wrote:


Hi Dmitry,

I scanned the PR and it seems reasonable to me. I'm barely a C++
programmer at all and it's clear to me, more clear than before. That said,
I'm not a fan of wrapping things that could be replaced. Have you looked
into whether a more performant C++ JSON library could be used? I haven't
run the benchmarks, but json-c compares pretty poorly to others in
https://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov <bishop@gmail.com>
wrote:


Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request https://github.com/OSGeo/gdal/
pull/282

I created a thin wrapper around the json-c library which wide using in
GDAL.

This is C++ interface which hides C memory management and provides nice
API. The web or disk json documents reading chunk by chunk with progress
indication also added.

In future, the json-c can be easily switch to something other without
breaking the existing code.

The CPLJSONDocument/CPLJSONObject/CPLJSONArray usage examples can be
found in frmts/pds driver and c++ unit test in autotest/cpp/test_cpl.cpp.

Is this ready to merge into the trunk? Any objections?

Best regards,
 Dmitry


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




--
Sean Gillies

___
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

Re: [gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi Sean,

First of all I agreed with Kurt. Json-c is GDAL internal library and had 
inspected by fuzzer.


Also json-c widely used in GDAL:

gdal/gcore
gdal/ogr/ogrsf_frmts/carto
gdal/ogr/ogrsf_frmts/amigocloud
gdal/ogr/ogrsf_frmts/cloudant
gdal/ogr/ogrsf_frmts/plscenes
gdal/ogr/ogrsf_frmts/geojson
gdal/ogr/ogrsf_frmts/gmlas
gdal/ogr/ogrsf_frmts/elastic
gdal/ogr/ogrsf_frmts/couchdb
gdal/ogr
gdal/frmts/rda
gdal/frmts/arg
gdal/frmts/mbtiles
gdal/frmts/plmosaic
gdal/frmts/pds

It's big work to replace json-c in all code smoothly.

Best regards,
Dmitry

05.01.2018 19:05, Kurt Schwehr пишет:

I think the more important factors than speed for a C++ lib are: security,
stability, maintainability, and memory usage (low stack usage and
constrainable heap).

I really don't want to have us go through yet more piles of fuzzer bugs for
a library we depend on.  It would be nice to have that already done well by
the lib.

On Fri, Jan 5, 2018 at 7:54 AM, Kurt Schwehr <schw...@gmail.com> wrote:


+1 for wrapping the old C code in some cleaner abstractions!

But +10 for switching to a from the ground up C++ JSON library unless
there are clear reasons for a core C library (I don't think there are)

If we are talking about this kind of code, there are several things that
have bugged me in general about GDAL for a long time.

* Passing char *psz yada all over the place in pure C++ code.  A const
std::string is usually not a noticeable expense and is a lot safer
* CPLString when std::string will do just fine.  And we can write free
functions to operate on strings.  I'm generally bothered by subclassing of
std::string as CPLString.  After reading large amounts of C++ code, I think
it adds more confusion than it ever helps over having clean free
functions.  Interop and analysis with CPLString's is no fun.
   https://stackoverflow.com/questions/6006860/why-should-
one-not-derive-from-c-std-string-class

-kurt

On Fri, Jan 5, 2018 at 7:44 AM, Sean Gillies <s...@mapbox.com> wrote:


Hi Dmitry,

I scanned the PR and it seems reasonable to me. I'm barely a C++
programmer at all and it's clear to me, more clear than before. That said,
I'm not a fan of wrapping things that could be replaced. Have you looked
into whether a more performant C++ JSON library could be used? I haven't
run the benchmarks, but json-c compares pretty poorly to others in
https://github.com/miloyip/nativejson-benchmark.


On Wed, Jan 3, 2018 at 12:04 PM, Dmitry Baryshnikov <bishop@gmail.com

wrote:
Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request https://github.com/OSGeo/gdal/
pull/282

I created a thin wrapper around the json-c library which wide using in
GDAL.

This is C++ interface which hides C memory management and provides nice
API. The web or disk json documents reading chunk by chunk with progress
indication also added.

In future, the json-c can be easily switch to something other without
breaking the existing code.

The CPLJSONDocument/CPLJSONObject/CPLJSONArray usage examples can be
found in frmts/pds driver and c++ unit test in autotest/cpp/test_cpl.cpp.

Is this ready to merge into the trunk? Any objections?

Best regards,
 Dmitry




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

[gdal-dev] CPLJSONDocument

[Dmitry Baryshnikov]

Hi everybody,

Happy new year and lot of success in 2018!

I would like to discuss my pull request 
https://github.com/OSGeo/gdal/pull/282


I created a thin wrapper around the json-c library which wide using in GDAL.

This is C++ interface which hides C memory management and provides nice 
API. The web or disk json documents reading chunk by chunk with progress 
indication also added.


In future, the json-c can be easily switch to something other without 
breaking the existing code.


The CPLJSONDocument/CPLJSONObject/CPLJSONArray usage examples can be 
found in frmts/pds driver and c++ unit test in autotest/cpp/test_cpl.cpp.


Is this ready to merge into the trunk? Any objections?

Best regards,
Dmitry


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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Hi Kurt,

In future I will try to write more detailed commit messages, and of 
course, will point to the osgeo/gdal pull request on github.


By the way this situation shows the one more reason to switch to github, 
as Even proposed.


Best regards,
Dmitry

21.12.2017 16:57, Kurt Schwehr пишет:

Dmitry,

Thank you for doing https://trac.osgeo.org/gdal/changeset/41095

Sorry, I didn't know about the pull request.  I get spammed by github
notifications and have yet to figure out how make the 99.99% I don't care
about go away. :|

I think commits should always reference relevant issues and pull requests.
The commit message here https://trac.osgeo.org/gdal/changeset/41086 was not
particularly useful.  In reading that patch, I assumed that this was a code
brand new to GDAL.  I filter out the changes for drivers that I don't use
and the diffs never go through my repo (0.8M lines locally versus 1.8M in
svn).  The description for r41085 never mentions migrating code from wms to
port or the pr.


On Wed, Dec 20, 2017 at 1:58 PM, Dmitry Baryshnikov <bishop@gmail.com>
wrote:


Hi Ari,

The pull request and discussion can be found here:
https://github.com/OSGeo/gdal/pull/280

I cannot imagine that this improvements will affect something else. MD5
used for cache paths initially, I only added some improvements for WMS
cache size limits, expire time and split cache per dataset base (i.e. to
delete cached files when dataset deletes).

What about your idea about common caching classes/functions - this is
topic to discuss.

Best regards,
 Dmitry

21.12.2017 0:32, Ari Jolma пишет:

My comments on this:

1) The MD5 function seems to be needed only(?) for the WMS cache and
probably also WFS. To me that highlights the need for some integration work
regarding caching in GDAL. I also implemented yet another caching code for
the WCS (without MD5). Looking at my $HOME/.gdal I see also gmlas_xsd_cache
and srs_cache.

2) This discussion thread also highlights the need to go towards more pull
request style development at least for bigger changes.

Ari


Kurt Schwehr kirjoitti 21.12.2017 klo 02:56:

Dmitry,

Statements like this indicate a world of trouble:


I'm not sure that Python produce the same hash than cvs_MD5*.
Also I'm not sure what in future they will be the same.

If you remove the swig and python stuff, move the CPLMD5String to
cpl_md5.{cpp,h}, and follow Even's suggestions, I will be much happier with
the change.  A C++ test would be good too.  I'll be happy to do a quick fix
up of a few things that I see in the md5 code once it is to that point.  I
do think it is a good thing that there be md5 support in port along with
the existing sha{1,256} code.

I see what you are saying about the OGRGeometry::exportTo{json,kml,gml},
but that doesn't (to me) support your argument.  My personal opinion is
that GDAL would have been stronger if those had separate and not been a
part of OGRGeometry.

If there is a critical difference between CPLMD5String or a language and
use case where md5 support in that language from GDAL is really required,
you need to first document that issue.

On Wed, Dec 20, 2017 at 7:46 AM, Dmitry Baryshnikov <bishop@gmail.com
<mailto:bishop@gmail.com> <bishop@gmail.com>> wrote:

 Just the note that CPLMD5String not only for Python, but any other
 API clients: C/C++, Java, Perl, etc.

 But, I agree, it can be easily removed.

 Best regards,
 Dmitry

 20.12.2017 18 <tel:20.12.2017%2018> <20.12.2017%2018>:35, Even
Rouault пишет:

 And why are you exposing this to python?  Python has
 md5 hashing

 already

 built in.

 I'm not sure that Python produce the same hash than cvs_MD5*.

 I do hope they return the same thing. MD5 is a standardized
 algorithm:
 https://tools.ietf.org/html/rfc1321
 <https://tools.ietf.org/html/rfc1321>
<https://tools.ietf.org/html/rfc1321>

 I'm not sure we really need to expose it our CPL MD5 through
 Python.


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




--
--
http://schwehr.org


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





___
gdal-dev mailing 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev



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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Hi Ari,

The pull request and discussion can be found here: 
https://github.com/OSGeo/gdal/pull/280


I cannot imagine that this improvements will affect something else. MD5 
used for cache paths initially, I only added some improvements for WMS 
cache size limits, expire time and split cache per dataset base (i.e. to 
delete cached files when dataset deletes).


What about your idea about common caching classes/functions - this is 
topic to discuss.


Best regards,
Dmitry

21.12.2017 0:32, Ari Jolma пишет:

My comments on this:

1) The MD5 function seems to be needed only(?) for the WMS cache and 
probably also WFS. To me that highlights the need for some integration 
work regarding caching in GDAL. I also implemented yet another caching 
code for the WCS (without MD5). Looking at my $HOME/.gdal I see also 
gmlas_xsd_cache and srs_cache.


2) This discussion thread also highlights the need to go towards more 
pull request style development at least for bigger changes.


Ari


Kurt Schwehr kirjoitti 21.12.2017 klo 02:56:

Dmitry,

Statements like this indicate a world of trouble:

> I'm not sure that Python produce the same hash than cvs_MD5*.
> Also I'm not sure what in future they will be the same.

If you remove the swig and python stuff, move the CPLMD5String to 
cpl_md5.{cpp,h}, and follow Even's suggestions, I will be much 
happier with the change.  A C++ test would be good too. I'll be happy 
to do a quick fix up of a few things that I see in the md5 code once 
it is to that point.  I do think it is a good thing that there be md5 
support in port along with the existing sha{1,256} code.


I see what you are saying about 
the OGRGeometry::exportTo{json,kml,gml}, but that doesn't (to me) 
support your argument.  My personal opinion is that GDAL would have 
been stronger if those had separate and not been a part of OGRGeometry.


If there is a critical difference between CPLMD5String or a language 
and use case where md5 support in that language from GDAL is really 
required, you need to first document that issue.


On Wed, Dec 20, 2017 at 7:46 AM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


    Just the note that CPLMD5String not only for Python, but any other
    API clients: C/C++, Java, Perl, etc.

    But, I agree, it can be easily removed.

    Best regards,
        Dmitry

    20.12.2017 18 <tel:20.12.2017%2018>:35, Even Rouault пишет:

    And why are you exposing this to python?  Python has
    md5 hashing

    already

    built in.

    I'm not sure that Python produce the same hash than 
cvs_MD5*.


    I do hope they return the same thing. MD5 is a standardized
    algorithm:
    https://tools.ietf.org/html/rfc1321
    <https://tools.ietf.org/html/rfc1321>

    I'm not sure we really need to expose it our CPL MD5 through
    Python.


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




--
--
http://schwehr.org


___
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


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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Just the note that CPLMD5String not only for Python, but any other API 
clients: C/C++, Java, Perl, etc.


But, I agree, it can be easily removed.

Best regards,
Dmitry

20.12.2017 18:35, Even Rouault пишет:

And why are you exposing this to python?  Python has md5 hashing

already

built in.

I'm not sure that Python produce the same hash than cvs_MD5*.

I do hope they return the same thing. MD5 is a standardized algorithm:
https://tools.ietf.org/html/rfc1321

I'm not sure we really need to expose it our CPL MD5 through Python.



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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Just the note that CPLMD5String not only for Python, but any other API 
clients: C/C++, Java, Perl, etc.


But, I agree, it can be easily removed.

Best regards,
Dmitry

20.12.2017 18:35, Even Rouault пишет:

And why are you exposing this to python?  Python has md5 hashing

already

built in.

I'm not sure that Python produce the same hash than cvs_MD5*.

I do hope they return the same thing. MD5 is a standardized algorithm:
https://tools.ietf.org/html/rfc1321

I'm not sure we really need to expose it our CPL MD5 through Python.



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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

Will answer in letter body

20.12.2017 17:39, Kurt Schwehr пишет:

My personal opinion...

It was not in fact in the core of GDAL for all users.  My primary
environment does not include the WMS *driver*.  My take is that only the
memory and gtiff raster drivers are really required for GDAL (vector, I'm
not so sure).

What do you mean by the same or similar for generic and geojson?  And
because something isn't great elsewhere, that does not mean we want to
introduce more similar code that is hard to impossible to opt out of.

For example we have such method - char * OGRGeometry::exportToJson() const

In this method executed OGR_G_ExportToJson from 
ogr/ogrsf_frmts/geojson/ogrgeojsonwriter.cpp


So the core OGR using some code from GeoJSON driver.

The same way I can move md5 back to WMS and use it from port function 
CPLMD5String.


But I think ogr and gdal must use port (and port shouldn't depends on 
org or gcore, etc.),
also drivers can use ogr or gdal, but ogr and gdal shouldn't depends on 
some driver.


This is only my opinion.


Dmitry's question about a reasonable solution is a good one (if you buy my
being seriously uncomfortable with cvs_MD5*).  Possibilities include:

- Make everything from md5.cpp and md5.h be internal to md5.cpp (aka static
or inline) and move CPLMD5String to md5.{cpp,h} at least keeping the
trouble localize
- Refactor md5 to be cleaner
- Reimplement md5 hashing for gdal
- Find some other code that is license compatible that is cleaner

And why are you exposing this to python?  Python has md5 hashing already
built in.

I'm not sure that Python produce the same hash than cvs_MD5*.
Also I'm not sure what in future they will be the same.
Finally not only Python use CPLMD5String - any program utilizing API may 
need the hash formed the same way as WMS/WFS does.


Can others please weigh in?

On Wed, Dec 20, 2017 at 6:25 AM, Dmitry Baryshnikov <bishop@gmail.com>
wrote:


In fact it was part of core of GDAL but hidden in WMS driver folder. The
same or similar is in:

1. ogr/ogrsf_frmts/generic

2. ogr/ogrsf_frmts/geojson

What solution can be suitable here (I mean md5 case)?


Best regards,
 Dmitry

20.12.2017 17:19, Kurt Schwehr пишет:


I have not looked in the wms code much, but my comment was not about
adding
an external dependency. It is about code quality in the core of GDAL.

On Dec 20, 2017 6:07 AM, "Dmitry Baryshnikov" <bishop@gmail.com>
wrote:

Hi Kurt.

The md5.cpp and md5.h were in frmst/wms driver folder. As I see from
header this files are not initially from GDAL project.

I moved this files to port with minimum changes - only macros for
suppress
Doxygen parsing.

The motivation of this moving was:

1. md5 functions used in several drivers (WMS and WFS) and may be others
in future.

2. need API function to get the same md5 hash as used in WMS for
autotesting functionality.

3. downloading area of interest into the WMS file based cache by external
programs. May be some other utilization.

I think ideally the OpenSSL MD5 functions must be using. But this will be
one more dependency. Do we need it?


Best regards,
  Dmitry

20.12.2017 16:43, Kurt Schwehr пишет:

Hi all,

Can we discuss cvs_MD5* from https://trac.osgeo.org/gdal/changeset/41086
?

I very much appreciate the work that bishop is doing and I hate to slow
down a contributor

I am really worried about code like this going into GDAL, especially into
port/

But my worries are:

- this in no way conforms to other code in GDAL
- has the potential to collide with other code that imports this code
- it has a very awkward C style
- the commit message did not point to where it came from (at least it's
not
hard to guess)
- the file naming is different than (most) of the rest of the directory
- and...

Yes, we have other libraries included, but it seems like a road we don't
want to go down

-kurt




___
gdal-dev mailing listgdal-dev@lists.osgeo.orghttps://
lists.osgeo.org/mailman/listinfo/gdal-dev



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






Best regards,
Dmitry

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

Re: [gdal-dev] port/md5 cvs_MD5*

[Dmitry Baryshnikov]

In fact it was part of core of GDAL but hidden in WMS driver folder. The 
same or similar is in:


1. ogr/ogrsf_frmts/generic

2. ogr/ogrsf_frmts/geojson

What solution can be suitable here (I mean md5 case)?


Best regards,
Dmitry

20.12.2017 17:19, Kurt Schwehr пишет:

I have not looked in the wms code much, but my comment was not about adding
an external dependency. It is about code quality in the core of GDAL.

On Dec 20, 2017 6:07 AM, "Dmitry Baryshnikov" <bishop@gmail.com> wrote:


Hi Kurt.

The md5.cpp and md5.h were in frmst/wms driver folder. As I see from
header this files are not initially from GDAL project.

I moved this files to port with minimum changes - only macros for suppress
Doxygen parsing.

The motivation of this moving was:

1. md5 functions used in several drivers (WMS and WFS) and may be others
in future.

2. need API function to get the same md5 hash as used in WMS for
autotesting functionality.

3. downloading area of interest into the WMS file based cache by external
programs. May be some other utilization.

I think ideally the OpenSSL MD5 functions must be using. But this will be
one more dependency. Do we need it?


Best regards,
 Dmitry

20.12.2017 16:43, Kurt Schwehr пишет:

Hi all,

Can we discuss cvs_MD5* from https://trac.osgeo.org/gdal/changeset/41086 ?

I very much appreciate the work that bishop is doing and I hate to slow
down a contributor

I am really worried about code like this going into GDAL, especially into
port/

But my worries are:

- this in no way conforms to other code in GDAL
- has the potential to collide with other code that imports this code
- it has a very awkward C style
- the commit message did not point to where it came from (at least it's not
hard to guess)
- the file naming is different than (most) of the rest of the directory
- and...

Yes, we have other libraries included, but it seems like a road we don't
want to go down

-kurt




___
gdal-dev mailing 
listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev



___
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

Re: [gdal-dev] Cannot build for iOS due to GUInt64 error

[Dmitry Baryshnikov]

Hi Nik,

You may try alternative build scenario using CMake.

1.  Install XCode command line tools if already not done this 
(https://www.embarcadero.com/starthere/xe5/mobdevsetup/ios/en/installing_the_commandline_tools.html) 
and CMake (https://cmake.org/download/)



2. In terminal execute commands:

> git clone --depth 1 https://github.com/nextgis-borsch/lib_gdal.git
> cd lib_gdal
> mkdir build
> cd build
> cmake -G"Unix Makefiles" -DBUILD_TARGET_PLATFORM=IOS 
-DCMAKE_INSTALL_PREFIX=install -DCMAKE_BUILD_TYPE=Release 
-DENABLE_BITCODE=OFF -DIOS_ARCH=arm64 -DIOS_PLATFORM=OS -DENABLE_NEON=ON 
-DCMAKE_TOOLCHAIN_FILE=../cmake/ios.toolchain.cmake -DWITH_JSONC=ON 
-DWITH_JSONC_EXTERNAL=ON -DWITH_TIFF=ON -DWITH_TIFF_EXTERNAL=ON 
-DWITH_GeoTIFF=ON -DWITH_GeoTIFF_EXTERNAL=ON -DOSX_FRAMEWORK=ON 
-DENABLE_GIF=OFF -DENABLE_CAD=OFF -DENABLE_PNG=OFF -DGDAL_BUILD_APPS=OFF 
-DGDAL_BUILD_DOCS=OFF -DWITH_PYTHON=OFF ..


Some flags description:
-DIOS_ARCH maybe armv7, armv7s, arm64, i386 or x86_64
-DIOS_PLATFORM maybe IOS or SIMULATOR

After configuring you will see summary about GDAL build or error 
message. I expect everything will be fine.


Run this command to build GDAL:

> cmake --build . -- -j 4

May be this need to rerun twice as dependency may not build on first run.

You may build GDAL for several architectures and create fat library 
using lipo -create command (I rewrite OpenCV py script to automate 
creating my own fat iOS library which use GDAL - 
https://github.com/nextgis/nextgis_datastore/blob/master/opt/ios/build_framework.py)



This is minimal build of GDAL. If you need some drivers which not build 
by listed command let me know - I'll help to modify command line options.


Best regards,
Dmitry

13.11.2017 23:30, Nik Sands пишет:

Hi Even,

If I include the -Wall option, then I do get just the one warning.  Here’s the 
command line I’m using, which is based on similar command lines from the make 
output…


$ /Applications/Xcode.app/Contents/Developer/usr/bin/gcc -o conftest -arch 
arm64 -pipe -Os -gdwarf-2 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.1.sdk
 -Wno-implicit-function-declaration -fembed-bitcode -mno-thumb -Wall  -arch 
arm64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.1.sdk
 conftest.c -ldl
conftest.c:1:24: warning: unused variable 'off' [-Wunused-variable]
int main() { long long off=0; }
^
1 warning generated.
$
——

I made the change you suggested to acinclude.m4 and then ran autoconf.  Then I 
attempted to build GDAL again, but got the same error:

--
geotiff.cpp:7653:13: error: unknown type name 'GUInt64'
 typedef GUInt64 WordType;
 ^
1 error generated.
make[2]: *** [../o/geotiff.lo] Error 1
make[1]: *** [gtiff-install-obj] Error 2
make: *** [frmts-target] Error 2
--

I have to admit that I’m a very small-time developer and I’m somewhat out of my 
depth here, so forgive me if I sound like I don’t understand some of this stuff.

Cheers,
Nik.


On 12 Nov 2017, at 11:22 pm, Even Rouault  wrote:

On dimanche 12 novembre 2017 19:50:47 CET Nik Sands wrote:

Hi Even,

Thanks for your reply.  You are correct as usual.  Your ‘cc’ test produced
no errors,
  
And no warnings as well ?

Weird, since this is the test that is used to dected long long presence
See m4/acinclude.m4
  
Do you run configure with CCFLAGS defined ? For example, if CCFLAGS="-Wall", then the test will throw a warning that will make it fail.

I'm not sure why we use CCFLAGS in that file, whereas CFLAGS is used everywhere 
else.
  
What if you change in m4/acinclude.m4

   echo 'int main() { long long off=0; }' >> conftest.c
to
   echo 'int main() { long long off=0; (void)off; return 0; }' > conftest.c
  
and run autoconf to regenerate configure ?
  
Even
  
--

Spatialys - Geospatial professional services
http://www.spatialys.com 


NIK SANDS
Line Tamer | Time Traveller | Space Cadet




___
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

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Even,

31.10.17 1:14, Even Rouault пишет:

Hi,

Trying to sum up my thoughts on this topic and answering to various points 
raised in this
discussion thread:

- I believe a relevant question to ask to ourselves would be: "imagine that 
GDAL would come
without any build system at all, what is the one that we would add" ? Ok, 
that's a bit silly to
turn the question like that, a more realistic one would be "imagine you're 
going to create a
software that will rule over the world, for the 20 next years and beyond, and 
should run on
all reasonable platforms, which build system would we use? If the answer is clearly 
"cmake",
then it is worth examining if there is not a path that would lead us to that 
point.
Similar question: is it an effort that will make GDAL development a bit easier 
for new
contributors?

This is clearly for me long ago and this is CMake.


- Must be reasonably friendly for GDAL developers, and for GDAL users (users 
here = people
building GDAL, but not actively hacking into its sources). As a user of cmake 
on Linux (and
marginally on Windows), my experiences are rather good.
Again want to point about illogical structure of source codes where we 
have some drivers in root folder (frmts)  and other drivers are deeper 
in the sources tree (ogr/ogrsf_frmts). And also we have raster drivers 
in ogrsf_frmts - like gpkg, cad (yes I know that they are raster-vector 
drivers) and vector drivers are in raster folder frmts, etc.


- the selling points I'd see with cmake would be the possibility of having 
ultimately a single
build system, instead of the 2 ones we have. + solving the current lack of 
dependency
tracking (speaking here about the mecanism that cause a change in a .h file to 
make the
.c/.cpp files that depend on it to be automatically rebuilt). We could add that 
by using
automake instead of our home-made GNUmakefile's, but doesn't feel like that's 
worth the
effort by itself.
A nice side effect could also be the opportunity to drop some cruft that has 
accumulated
over years in the current build systems (supporting ancient library versions 
that no longer
make sense)

+ 1


- If we added cmake support in trunk, I think this would only make sense if 
(all conditions to
be met)
*  we have at least a couple of "champions" to support the effort, and 
with an
agreement on how to use cmake as a in-tree build solution. Regarding Borsch, I 
think Dmitry
and his team did an impressive work, although I think that for GDAL we would 
want a more
"traditional" way of using cmake (in-tree, no particular requirents regarding 
how the
dependencies should be made). I'd hope that part of the work done on Borsch (or 
at the very
least good ideas and the lessons learnt) could be ported back to such a more 
traditional way
(and in a way where that would still be useful for Borsch. Possible win-win ?)
Using the find_anyproject function from Borsch (which is a wrapper 
around find_package) instead of find_package this is the only one 
requirements for successfully used in Borsch without any hacks (can be 
discussed to get win-win). Any others, like conventions about install 
paths, versions, naming etc. are optional and can be discussed too.

* growing it from an experimental status to the recommended build 
system, once
its completely mature. I'd expect that to require a transition over one or two 
release cycles
(one reason for that delay would be that systems ship with a recent enough 
version of cmake
regarding the minimum we would require)
* ultimately removing autoconf + nmake support. Clearly we don't want to
support 3 different build systems for the next 20 years.

- Thinking that if there's an agreement to give it a try, the next OSGeo code 
sprint ( https://
wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018 ) could be the opportunity to boost 
(no pun
intended) the effort

- I'm puzzled about some of you having apparently completely different feeback 
regarding
CMake on the same platform (MacOS). I don't owe a Mac, so I've no informed 
opinion on this.
But I see that a software, with a complexity similar to GDAL, like QGIS uses 
CMake and it
builds on Linux, Windows and MacOSX

- There wasn't much discussion about support for more exotic targets, like 
cross-compiling
for Windows with mingw compiler hosted on Linux. But openjpeg for example has 
Travis-CI
targets doing that, so this is at least achievable for a simple library.

- I've no fundamental objection to cmake... nor fundamental enthousiasm for it 
or mastering
of it (could say the same about autoconf/automake or nmake. Build systems are 
boring
subjects, aren't they ?)

Even

PS: for Ari, try ./configure --enanble-debug for builds with -g and without -O2 
;-)



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I working on CMake for GDAL for a long time and ready and willing to 
take part in this work. But it is 

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Mateusz,

If really "there is no plan or even will for such switch in GDAL" I 
think nothing to discuss here.


The ticket #7080 should be closed and let's continue to live with 
current developing approach.


Which solution, my or Hiroshi, will more popular show the time.

Best regards,
Dmitry

30.10.17 12:24, Mateusz Loskot пишет:

On 30 October 2017 at 10:06, Dmitry Baryshnikov <bishop@gmail.com> wrote:

Also there is one big problem for me in #7080 - this is third build system
additionally to GNUMakefile, makefile.vc.  And now CMakeLists.txt must be
supported too. Three files which must be synced each other with and taking
into consideration the upper scripts, it's awful!

Dmitry,

This issue is orthogonal to actual CMake challenge.
If core developers of a project X do not agree to switch to a new
build configuration Y,
then any initiative to develop setup for Y will live in a side car.

AFAIU, there is no plan or even will for such switch in GDAL.
Similar situation is with GEOS.

Finally, developing configuration for Y build system by completely
revolutionising structure of project X is a terrible thing to do in terms
of potential switch to Y. IOW, the bigger and deeper a revolution, the less
chance to get acceptance by core developers, also psychologically.

Best regards,


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

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Alexander,

CMake scripts from #7080 have no logic presented in current building 
system (make/autoconf): there are several mandatory drivers, the 
optional drivers, and drivers depends from other drivers.


Also there is one big problem for me in #7080 - this is third build 
system additionally to GNUMakefile, makefile.vc.  And now CMakeLists.txt 
must be supported too. Three files which must be synced each other with 
and taking into consideration the upper scripts, it's awful!



That about your questions:

1. Now it is not supported. This is really limitations what should gone. 
It can be easily fixed. I thinking on this direction - may be somehow 
like in Carthage project was done (https://github.com/Carthage/Carthage).


2. Here we have 2 cases: 1 - cmaked dependency (we only remove current 
build system with own CMake not touching the original sources), 2 - wrap 
current build system by CMake (see how it is done for Qt4 - 
https://github.com/nextgis-borsch/lib_qt4)


3. This should not be the problem of upstream developers. It may be 
developed some script which periodically get sources and put them to 
cmaked repositories, build and run tests to report if everything is OK. 
Here we can achieve synced releases and developer branches with our owns 
prepared repositories.


4. What about option to get all needed dependencies from github 
(WITH_EXTERNAL) - yes we need own prepared repositories. Theoretical 
there is the mechanism to make direct clone from any repository 
(https://cmake.org/cmake/help/v3.8/module/ExternalProject.html) but 
there are several problems here:


1. Original repository may not support needed platforms (usually Mac OS, 
Android, iOS and Windows) or static/dynamic library builds.


2. No way to uniformly transfer building options to dependency builds.

3. Install paths of original projects may vary and this may be a problem 
in install target of main project. In current solution upper project 
installs all dependency dynamic libraries in it "install" target in 
uniform way.


To solve this problems I choose more simple way to have own prepared 
repositories (again, just like in Carthage approach).



Finally, thanks for your concrete questions!

Best regards,
Dmitry

30.10.17 10:00, Alexander Bruy пишет:

Hi Dmitry,

thanks for explanation. I see that there is an option to use system libraries.
Maybe I'm wrong, but this is also possible with current build system and
CMake scripts from #7080. There is an option to build deps by myself and
use them to build GDAL, but again this is also possible with current build
system and CMake scripts from #7080.

I agree that automatic fetching of missed dependencies is nice feature. And
can simplify live in some cases. But there are questions:

1. what if dependency hosted on BitBucket, SourceForge or any self-hosted
VCS and not in your repository?
2. what if dependency use build system different from CMake?
3. what if upstream does not want/does not see abny benefits in moving to
GitHub and/or switching to CMake?

Correct me if I'm wrong, but most of the borsh's benefits require
changes not only
in GDAL, but also in all upstream projects, as well as infrastructure
changes for
them. Or why you maintain forks for every lib needed by GDAL in your repository?
If everything is fine and flexible why not use upstream projects directly?

2017-10-29 15:39 GMT+02:00 Dmitry Baryshnikov <bishop@gmail.com>:

1. Build gdal with all dependencies getting them from github
(WITH_EXTERNAL). Preferable for Windows

2. Build gdal using the system libraries. Preferable for Linux

3. Build gdal using the dependency libraries build by user (out of source)
and registered in CMake package registry. This is I use now. This script
help me to clone all libraries, build them and register them in CMake
package registry
(https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134).

My opinion is that different options is much flexible and suits for many
scenarios as very limited solution from
https://trac.osgeo.org/gdal/ticket/7080.


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

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Hiroshi,

I think that anyhow the current logic of makefile mast be transfer to 
CMake. See the 
https://github.com/OSGeo/gdal/blob/trunk/gdal/configure.ac or how I did 
it in lib_gdal repository. This logic is rather complicated!


About vagrant:

$ vagrant up
bash: vagrant: command not found

Vagrant is not documented dependency and I don't understand how it will 
help me in may building environment and what additional benefits vagrant 
provide to me in compare with autoconf?


I'm sure all steps in any environment, as Mateusz Łoskot wrote, should be:

git clone .../gdal
mkdir build
cd build
cmake ..
apps/gdalinfo --version


Best regards,
Dmitry

29.10.17 17:27, Hiroshi Miura пишет:

Hi Dmitry,

On 2017年10月29日 07:21, Dmitry Baryshnikov wrote:

Hi Hiroshi,

I tried to test you solution:


Thank you for testing and sharing your experience.
It is working in progress status. And it is based on different policy with your 
solution.
  
Now I don't write document about a policy and how-to.


In current script assumes 'configuration has a priority over dependency 
libraries'
So when user/developer ON the driver, user/developer should install libraries 
on their own.

I have not done every dependencies  clean yet, but I've been improved.
You can  use vagrant script that prepares  environment to pass the build.

$ vagrant up

I've tested with LXC container environment on Linux.

The QHULL is not mandatory for GDAL build and should not stop configuring at 
that moment.


It is hard work for me to determine which driver is mandatory and which is 
optional.  Also I need to  determine which driver should be  ON in default.
It would be a simple rule that driver which does not require 3rd party library 
is ON in default. Otherwise optional.

Every your feedback is valuable to improve script. It would be good PoC 
activity to know  which approach is preferable  for GDAL dev community.
I think your solution is to jump to highest level.  My trial is to realize an 
intermediate step from current source tree.


Hiroshi






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

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Kurt,

And how to deal with non Linux builds like Windows MSVC, mac OS XCode etc.?

Best regards,
Dmitry

29.10.17 17:17, Kurt Schwehr пишет:

While autoconf isn't pretty, it has done me the least amount of harm of any
of the major build systems.  Without patches for the downstream packagers
and CI (travis/appveyor), I would be -1.  e.g. debian/ubuntu,
redhat/centos, macport/brew/fink, and others

With those patches, I'm -0.

BTW, It's not unreasonable to have separate build systems.  It's work, but
very doable.  I maintain a bazel build environment.  I have to notice add
or deletes of files in upstream, but it's been working for more than a
decade.

On Sat, Oct 28, 2017 at 11:11 PM, Alexander Bruy <alexander.b...@gmail.com>
wrote:


While I'm not GDAL developer or regular contributor (submitted only
few patches),
but still often build GDAL trunk on WIndows and Linux, and less often on
Mac.

Personally I think that solution proposed in
https://trac.osgeo.org/gdal/ticket/7080
is more preferable. It does not require *all* dependencies to be build
with cmake,
it does not require maintaining forks with special directory structure for
*all*
dependencies, it plays well with conventions/packages provided on all
systems
out of the box. Maybe borsch is good for in-house use when all stack
is build from
scratch but it is not suitable for real-world use cases.

Of course, #7080 is not ideal, there are some issues, but as I understand
the
work is not over and most (if not all) issues can be solved.

Just my 2c.

2017-10-28 0:06 GMT+03:00 Dmitry Baryshnikov <bishop@gmail.com>:

Hi,

As Even said it make sense to move discussion from this ticket
(https://trac.osgeo.org/gdal/ticket/7080) to the list.

First of all I would like to make small introduction to Borsch project.

Here

it is some useful links:

* Borsch repository: https://github.com/nextgis-borsch/borsch

* Presentation on FOSS4G 2016:
http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-

presentation.pdf

* GDAL repository adapted for Borsch:
https://github.com/nextgis-borsch/lib_gdal

Shortly speaking Borsch is 3 CMake scripts which add ability to include
dependence library in one line of code.

It looks like:

find_anyproject(TIFF REQUIRED)

Certainly developer can add additional parameter to configure dependency

in

find_anyproject function.

Inside  find_anyproject work 2 cases:

1. First of all (by default, but can be overridden) CMake searches host
system for dependency library (headers and lib files). This is usual

CMake

find_package (https://cmake.org/cmake/help/

v3.0/command/find_package.html)

with some additional logic to try different options for hard cases (like
Qt).

2. If library not found, find_anyproject can get the sources or prebuild
library from github.

So the GDAL or any other library can be build the normal way, but

developer

have additional features to configure build all libraries with one

compiler

and one set of compiler/linker settings (with some limits). Such way we

can

have rather complicated scenarios to build GDAL and dependencies.

Here it is several examples of benefits of this approach:

1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library

for

iOS as *.framework and for Android as *.so (arm7, arm64, i386, x86_64
architecture). I build all dependencies include GDAL statically and link

in

one fat library. The all code that do it:
https://github.com/nextgis/nextgis_datastore/blob/master/

cmake/extlib.cmake#L118-L236

By the way the library also builds on Linux and Mac OS (Windows under
development) and CMake try to use existed in host system libraries. If

CMake

find GDAL in host system it will use it and all (-DENABLE_PLSCENES=OFF

... )

will be ignored as it already build with another parameters.

2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa:
https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules

3. Build QGIS
(https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149

),

PostGIS
(https://github.com/nextgis-borsch/postgis/blob/master/

CMakeLists.txt#L165),

Formbuilder
(https://github.com/nextgis/formbuilder/blob/master/cmake/

extlib.cmake#L53-L173)

This is main Borsch features.


There are some additional conventions like:

 * I modify all libraries included into Borsch repository to install

on

unix-like paths. For Linux this is usual, for Windows and Mac OS this

let us

to use Qt installer framework an install software mach similar like on
Linux. This is about target "install" which is vary on different

libraries

(CMake has it own conventions about it). This is not mandatory for Borsch
itself but useful. CMake can register installed libraries in system
repository to simplify find them in find_package function.

 * CMake get library version from sources in all libraries included

into

Borsch (if applicable, otherwise set it in CMake script). This is

necessary

if exact ver

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Alexander,

Please read carefully that I wrote before. There are 3 options:

   1. Build gdal with all dependencies getting them from github
   (WITH_EXTERNAL). Preferable for Windows

   2. Build gdal using the system libraries. Preferable for Linux

   3. Build gdal using the dependency libraries build by user (out of
   source) and registered in CMake package registry. This is I use now.
   This script help me to clone all libraries, build them and register
   them in CMake package registry
   (https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134).



Again, this is the options which one can choose. So if building 
everything from scratch not suits you - just select another option. I 
introduce presets (now there is only one for option 1 - 
https://github.com/nextgis-borsch/lib_gdal/issues/14) and this can be 
expanded for different scenarios. If you need full control on build just 
provide command line options to CMake and get what you need.


My fast code review solution of Hiroshi shows that it very far from 
working solution and need much work that already done in lib_gdal from 
Borsch.


My opinion is that different options is much flexible and suits for many 
scenarios as very limited solution from 
https://trac.osgeo.org/gdal/ticket/7080.


Best regards,
Dmitry

29.10.17 9:11, Alexander Bruy пишет:

While I'm not GDAL developer or regular contributor (submitted only
few patches),
but still often build GDAL trunk on WIndows and Linux, and less often on Mac.

Personally I think that solution proposed in
https://trac.osgeo.org/gdal/ticket/7080
is more preferable. It does not require *all* dependencies to be build
with cmake,
it does not require maintaining forks with special directory structure for *all*
dependencies, it plays well with conventions/packages provided on all systems
out of the box. Maybe borsch is good for in-house use when all stack
is build from
scratch but it is not suitable for real-world use cases.

Of course, #7080 is not ideal, there are some issues, but as I understand the
work is not over and most (if not all) issues can be solved.

Just my 2c.

2017-10-28 0:06 GMT+03:00 Dmitry Baryshnikov <bishop@gmail.com>:

Hi,

As Even said it make sense to move discussion from this ticket
(https://trac.osgeo.org/gdal/ticket/7080) to the list.

First of all I would like to make small introduction to Borsch project. Here
it is some useful links:

* Borsch repository: https://github.com/nextgis-borsch/borsch

* Presentation on FOSS4G 2016:
http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf

* GDAL repository adapted for Borsch:
https://github.com/nextgis-borsch/lib_gdal

Shortly speaking Borsch is 3 CMake scripts which add ability to include
dependence library in one line of code.

It looks like:

find_anyproject(TIFF REQUIRED)

Certainly developer can add additional parameter to configure dependency in
find_anyproject function.

Inside  find_anyproject work 2 cases:

1. First of all (by default, but can be overridden) CMake searches host
system for dependency library (headers and lib files). This is usual CMake
find_package (https://cmake.org/cmake/help/v3.0/command/find_package.html)
with some additional logic to try different options for hard cases (like
Qt).

2. If library not found, find_anyproject can get the sources or prebuild
library from github.

So the GDAL or any other library can be build the normal way, but developer
have additional features to configure build all libraries with one compiler
and one set of compiler/linker settings (with some limits). Such way we can
have rather complicated scenarios to build GDAL and dependencies.

Here it is several examples of benefits of this approach:

1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library for
iOS as *.framework and for Android as *.so (arm7, arm64, i386, x86_64
architecture). I build all dependencies include GDAL statically and link in
one fat library. The all code that do it:
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236

By the way the library also builds on Linux and Mac OS (Windows under
development) and CMake try to use existed in host system libraries. If CMake
find GDAL in host system it will use it and all (-DENABLE_PLSCENES=OFF ... )
will be ignored as it already build with another parameters.

2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa:
https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules

3. Build QGIS
(https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149),
PostGIS
(https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165),
Formbuilder
(https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173)

This is main Borsch features.


There are some additional conventions like:

 * I modify all libraries included into Borsch repository to install on
unix-like paths. For Linux this is usual, for Windows and 

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi John,

The CMake don't required complete restructure the GDAL project. But I 
think this changes needed to fit new classes inheritance introduced in 
GDAL 2.0. And new sources structure more closer to CMake needs.


Also I would like to note that I have only positive experience with 
CMake, especially 3.x (where many things made simpler).


For iOS builds I wrap CMake into the XCode project and used it via 
Carthage (see 
https://github.com/nextgis/nextgis_datastore/tree/master/opt/ios). This 
is not just GDAL, but an example how GDAL can be wrap too.


Best regards,
Dmitry

28.10.17 22:29, John Daniel пишет:

I have my own build system for GDAL and its dependencies. It uses whatever 
build system each project uses. CMake is, by far, the most problematic. 
Luckily, I can still use the original autotools-based KML.

If I understand correctly, CMake is going to require a complete restructuring 
of the project and a complete dependency on CMake for all dependencies. Can 
anyone explain how this would improve anything?

With the KML project and others, I have found CMake to be the most complicated 
and most problematic build system. When there is a problem, I'm helpless to 
resolve it on my own. The people who made the CMake scripts are equally 
helpless because they use a different platform. I build on a Mac with Xcode and 
target both macOS and iOS. Are the maintainers of the GDAL CMake build scripts 
going to have access to same beta versions of all the above that I am using?

I'm not an active member of the mailing list. I've been on different projects 
the past couple of years but was looking forward to working on GDAL-based 
projects full time next year. CMake will shut me out of the community entirely. 
I simply don't have time to master CMake just to build projects that had never 
required a similar level of mastery of autotools. Instead, I will be forced to 
stay on the last working version I have. I won't be able to contribute any 
fixes I make or new features like my boost replacement for GEOS and Spatialite.

If some people like CMake and it works on their platforms, great. Then let 
people choose what build tools they want and what they can support on their own 
platforms.

John Daniel
Etresoft, Inc.

Sent from my iPhone

On Oct 27, 2017, at 5:06 PM, Dmitry Baryshnikov 
<bishop@gmail.com<mailto:bishop@gmail.com>> wrote:


Hi,

As Even said it make sense to move discussion from this ticket 
(https://trac.osgeo.org/gdal/ticket/7080) to the list.

First of all I would like to make small introduction to Borsch project. Here it 
is some useful links:

* Borsch repository: https://github.com/nextgis-borsch/borsch

* Presentation on FOSS4G 2016: 
http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf

* GDAL repository adapted for Borsch: https://github.com/nextgis-borsch/lib_gdal

Shortly speaking Borsch is 3 CMake scripts which add ability to include 
dependence library in one line of code.

It looks like:

find_anyproject(TIFF REQUIRED)

Certainly developer can add additional parameter to configure dependency in 
find_anyproject function.

Inside  find_anyproject work 2 cases:

1. First of all (by default, but can be overridden) CMake searches host system 
for dependency library (headers and lib files). This is usual CMake 
find_package (https://cmake.org/cmake/help/v3.0/command/find_package.html) with 
some additional logic to try different options for hard cases (like Qt).

2. If library not found, find_anyproject can get the sources or prebuild 
library from github.

So the GDAL or any other library can be build the normal way, but developer 
have additional features to configure build all libraries with one compiler and 
one set of compiler/linker settings (with some limits). Such way we can have 
rather complicated scenarios to build GDAL and dependencies.

Here it is several examples of benefits of this approach:

1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library for iOS 
as *.framework and for Android as *.so (arm7, arm64, i386, x86_64 
architecture). I build all dependencies include GDAL statically and link in one 
fat library. The all code that do it: 
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236

By the way the library also builds on Linux and Mac OS (Windows under 
development) and CMake try to use existed in host system libraries. If CMake 
find GDAL in host system it will use it and all (-DENABLE_PLSCENES=OFF ... ) 
will be ignored as it already build with another parameters.

2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa: 
https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules

3. Build QGIS 
(https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149), 
PostGIS 
(https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165), 
Formbuilder 
(https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173)

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Brad.

Yes you are right. Just do this steps:

|git clone https://github.com/nextgis-borsch/lib_gdal.git gdal cd gdal 
mkdir build cd build cmake .. cmake --build .|


Some discussion was in this ticket 
(https://github.com/nextgis-borsch/lib_gdal/issues/13).


There are 3 scenarios supported by lib_gdal now:

1. Build gdal with all dependencies getting them from github 
(WITH_EXTERNAL). Preferable for Windows


2. Build gdal using the system libraries. Preferable for Linux

3. Build gdal using the dependency libraries build by user (out of 
source) and registered in CMake package registry. This is I use now. 
This script help me to clone all libraries, build them and register them 
in CMake package registry 
(https://github.com/nextgis-borsch/borsch/blob/master/opt/tools.py#L134).


Best regards,
Dmitry

29.10.17 2:39, br...@frogmouth.net пишет:

Is there a way to invoke that “do all the dependency work for me” 
(`find_anyproject`) from the cmake command line?

So if I clone your lib_gdal repo, it could build GDAL and any required 
dependencies?

Brad

  



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

Re: [gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Hiroshi,

I tried to test you solution:

   $ git clone --depth 1 https://github.com/miurahr/gdal.git

   $ cd gdal/

   $ mkdir build

   $ cd build

   $ cmake ..

   -- The C compiler identification is AppleClang 9.0.0.938

   [ Skipped ...]

   CMake Error at
   
/Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137
   (message):
  Could NOT find QHULL (missing: QHULL_LIBRARY QHULL_INCLUDE_DIR)
   Call Stack (most recent call first):
   
/Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
   (_FPHSA_FAILURE_MESSAGE)
  cmake/FindQHULL.cmake:41 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  gdal/alg/CMakeLists.txt:139 (find_package)


   -- Configuring incomplete, errors occurred!


The QHULL is not mandatory for GDAL build and should not stop 
configuring at that moment.



Fast review you solution:

1 Don't see Python 2/3 support (CMake will choose default Python). How 
to configure to build Python 2 or Python 3 bindings? Don't see Python 
bindings install steps.


2. Loose some drivers (for example GPKG) as of result manually added 
here 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/CMakeLists.txt) 
- in compare of my idea automatically add drivers 
(https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt)


3. In GML driver you add EXPAT and Xerces simultaneously - as I remember 
this options are mutually exclusive (may be I'm wrong here)


4. There are mandatory drivers which may be disabled in your solution 
(GeoJSON, ESRI Shape, Map Info ...)


5. There are  drivers which cannot be disabled in your solution but this 
option must be (ilwis, r, til, saga, couchdb ...)


6. Again dependency problems. For example plscene, plmosaic depends on 
CURL, but there is no check if CURL is found 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/plscenes/CMakeLists.txt). 
Rasterlite ans OSM drivers depends on SQLite, ...


7. Self driver dependency - for example mbtiles depends on GPKG and also 
on SQLite but no checks exist 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/frmts/mbtiles/CMakeLists.txt) 



8. A lot of command line utilities not build - gdamanage, gdalenhance, 
gnmmanage, gdalsrsinfo ...)


9. Your make system checks via configure.cmake in port directory 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/port/CMakeLists.txt#L32) 
as the result you hides the variables set by CMake from other parts of 
build (ogr, frmts, apps, etc).


10. Hardcoded paths - for example 
https://github.com/miurahr/gdal/blob/compile_with_cmake/CMakeLists.txt#L38


11. No summary output after configure.

12. Install paths on Windows are strange 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/CMakeLists.txt#L207-L224). 
It mast be some logic (as in my solution) or let CMake choose the right 
paths.



I would like to note that my solution 
(https://github.com/nextgis-borsch/lib_gdal) successfully builds on 
Windows (MSVC), Ubuntu, Mac OS, Android, iOS (in our build environment). 
Also for last two OS you need the special toolchains and dependency must 
support them too.  All check for dependencies are present in already 
cmaked drives, all command line utilities build, also bindings and 
pythons scripts installs in right places. It rather configurable via 
command line options or CMake GUI.



Best regards,
Dmitry

28.10.17 17:52, Hiroshi Miura пишет:

Hi,

Dmitry, Thank you for starting the thread.
I'm Hiroshi, a newbie as user and dev of GDAL. I'm OSM mapper.

On 2017/10/28 06:06, Dmitry Baryshnikov wrote:

As Even said it make sense to move discussion from this ticket 
(https://trac.osgeo.org/gdal/ticket/7080) to the list.


The ticket (https://trac.osgeo.org/gdal/ticket/7080) is my proposal.
I put it because there are significant improvements in CMake ecosystem in 
recent days.

-  CMake support in Visual Studio 2017.
   
(https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/)
   VS17 bundles CMake 3.9 into their tool chains.
   It helps editing code and debugging a C/C++ project with CMake.

- JetBrains CLion only supports CMake.
    CLion appeared in 2014.   Current CLion 2017.2 bundles CMake 3.8.


When I made a small contribution for GML driver recently,
I had a frustration to make changes on GDAL source tree.
If changing code and  unit test cycle become speedy, it would be better.

It is because I want to improve a development experience using C/C++ IDE.
After short research, I reached a conclusion to use CMake with GDAL source tree,
and work with CLion IDE on my Linux laptop.


Finally:

Find the link to page with the CMake in GDAL discussion - 
https://trac.osgeo.org/gdal/wiki/CMake


Wiki news point https://github.com/aashish24/gdal-svn/tree/cmake4gdal  as a  
repository.

I tried it and catch up current GDAL  tree.
Unfortunately I didn't

[gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi,

As Even said it make sense to move discussion from this ticket 
(https://trac.osgeo.org/gdal/ticket/7080) to the list.


First of all I would like to make small introduction to Borsch project. 
Here it is some useful links:


   * Borsch repository: https://github.com/nextgis-borsch/borsch

   * Presentation on FOSS4G 2016:
   http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh-presentation.pdf

   * GDAL repository adapted for Borsch:
   https://github.com/nextgis-borsch/lib_gdal

Shortly speaking Borsch is 3 CMake scripts which add ability to include 
dependence library in one line of code.


It looks like:

find_anyproject(TIFF REQUIRED)

Certainly developer can add additional parameter to configure dependency 
in find_anyproject function.


Inside  find_anyproject work 2 cases:

1. First of all (by default, but can be overridden) CMake searches host 
system for dependency library (headers and lib files). This is usual 
CMake find_package 
(https://cmake.org/cmake/help/v3.0/command/find_package.html) with some 
additional logic to try different options for hard cases (like Qt).


2. If library not found, find_anyproject can get the sources or prebuild 
library from github.


So the GDAL or any other library can be build the normal way, but 
developer have additional features to configure build all libraries with 
one compiler and one set of compiler/linker settings (with some limits). 
Such way we can have rather complicated scenarios to build GDAL and 
dependencies.


Here it is several examples of benefits of this approach:

1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library 
for iOS as *.framework and for Android as *.so (arm7, arm64, i386, 
x86_64 architecture). I build all dependencies include GDAL statically 
and link in one fat library. The all code that do it: 
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L118-L236


By the way the library also builds on Linux and Mac OS (Windows under 
development) and CMake try to use existed in host system libraries. If 
CMake find GDAL in host system it will use it and all 
(-DENABLE_PLSCENES=OFF ... ) will be ignored as it already build with 
another parameters.


2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa: 
https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules


3. Build QGIS 
(https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149), 
PostGIS 
(https://github.com/nextgis-borsch/postgis/blob/master/CMakeLists.txt#L165), 
Formbuilder 
(https://github.com/nextgis/formbuilder/blob/master/cmake/extlib.cmake#L53-L173)


This is main Borsch features.


There are some additional conventions like:

    * I modify all libraries included into Borsch repository to install 
on unix-like paths. For Linux this is usual, for Windows and Mac OS this 
let us to use Qt installer framework an install software mach similar 
like on Linux. This is about target "install" which is vary on different 
libraries (CMake has it own conventions about it). This is not mandatory 
for Borsch itself but useful. CMake can register installed libraries in 
system repository to simplify find them in find_package function.


    * CMake get library version from sources in all libraries included 
into Borsch (if applicable, otherwise set it in CMake script). This is 
necessary if exact version of library needed. This is not mandatory. One 
more benefit during building process we can see dependency library 
version in console.


    * We modify all libraries included into Borsch repository to find 
dependencies using find_anyproject. It is simple to use libraries from 
our borsch repository, but developer can fork them or use any other 
sources and build systems to have dependency library in it's host system.


One can see this is all very flexible.


What about GDAL.

1. After unification GDALDataset and OGRDatasource current sources tree 
is not fit for this new logic of GDAL classes. I rearranged sources more 
closer to GDAL classes and CMake needs. Main changes are moving raster 
and vector drivers inside drivers folder 
(https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers).This 
simplify situation where different drivers need the same dependency 
library (libpg, libsqlite, etc.). Also there are several raster/vector 
drivers which need a separate directory but now presented in ogr or 
frmts directories. There are some bad decisions I made - for example I 
moved unit tests into separate repository - this was a mistake. We will 
return unit tests back to GDAL repository.


An example of cmake friendly way see 
https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt. 
The driver developer must only create new folder and put CMakeLists.txt 
file into it. The upper CMake script will find new driver and add it to 
GDAL build. In common cases no need to modify upper CMake scripts.


2. I remove third-party code from drivers folders (TIFF, GeoTIF, 

Re: [gdal-dev] Time in GDAL

[Dmitry Baryshnikov]

Hi,

For some imagery metadata the Acquisition date and time is the center of 
scene (end timestamp minus start). Also for one-shot camera there is 
only the one moment there the imagery was captured.


I believe that this 3 parameters (SATELLITEID, CLOUDCOVER, 
ACQUISITIONDATETIME) are common for any satellite/aerial imagery.


The many other parameters from imagery metadata also exported to 
GDALDataset metadata domain "", but they are not common to any 
satellite/aerial imagery and may vary from Provider/Satellite/Camera etc.


For example for DigitalGlobe satellite imagery the full metadata looks like:

$ gdalinfo -mdd all 14SEP05095603-P2AS-053903708010_01_P001.TIL
Driver: TIL/EarthWatch .TIL
Files: 14SEP05095603-P2AS-053903708010_01_P001.TIL
   ./14SEP05095603-P2AS-053903708010_01_P001.TIF
   14SEP05095603-P2AS-053903708010_01_P001.IMD
   14SEP05095603-P2AS-053903708010_01_P001.RPB
   14SEP05095603-P2AS-053903708010_01_P001.XML
Size is 5656, 6538
Coordinate System is:
PROJCS["WGS 84 / UTM zone 33N",
    GEOGCS["WGS 84",
    DATUM["WGS_1984",
    SPHEROID["WGS 84",6378137,298.257223563,
    AUTHORITY["EPSG","7030"]],
    AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",15],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",50],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
    AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32633"]]
Origin = (297822.399916459980886,4640476.78810514808)
Pixel Size = (0.400,-0.400)
Metadata:
  METADATATYPE=DG
Metadata (IMD):
  bandId="P"
  BAND_P.absCalFactor=5.273360e-02
  BAND_P.effectiveBandwidth=2.846000e-01
  BAND_P.LLHAE=91.66
  BAND_P.LLLat=41.86684502
  BAND_P.LLLon=12.56391718
  BAND_P.LRHAE=91.66
  BAND_P.LRLat=41.86741975
  BAND_P.LRLon=12.59114917
  BAND_P.TDILevel=48
  BAND_P.ULHAE=91.66
  BAND_P.ULLat=41.89037482
  BAND_P.ULLon=12.56302285
  BAND_P.URHAE=91.66
  BAND_P.URLat=41.89095002
  BAND_P.URLon=12.59026482
  bitsPerPixel=16
  compressionType="None"
  generationTime=2014-09-30T18:42:14.00Z
  imageDescriptor="ORStandard2A"
  IMAGE_1.attitudeKnowledgeSrc="R"
  IMAGE_1.avgLineRate=2.04
  IMAGE_1.CatId="1040010001338D00"
  IMAGE_1.cloudCover=0.027
  IMAGE_1.colUncertainty=10.60
  IMAGE_1.exposureDuration=0.5000
  IMAGE_1.firstLineTime=2014-09-05T09:56:03.000901Z
  IMAGE_1.maxCollectedColGSD=0.322
  IMAGE_1.maxCollectedRowGSD=0.328
  IMAGE_1.maxCrossTrackViewAngle=-3.0
  IMAGE_1.maxInTrackViewAngle=-13.4
  IMAGE_1.maxOffNadirViewAngle=13.7
  IMAGE_1.maxSatAz=203.5
  IMAGE_1.maxSatEl=74.9
  IMAGE_1.maxSunAz=150.3
  IMAGE_1.maxSunEl=51.6
  IMAGE_1.meanCollectedColGSD=0.322
  IMAGE_1.meanCollectedGSD=0.325
  IMAGE_1.meanCollectedRowGSD=0.328
  IMAGE_1.meanCrossTrackViewAngle=-3.1
  IMAGE_1.meanInTrackViewAngle=-13.4
  IMAGE_1.meanOffNadirViewAngle=13.7
  IMAGE_1.meanSatAz=203.4
  IMAGE_1.meanSatEl=74.7
  IMAGE_1.meanSunAz=150.3
  IMAGE_1.meanSunEl=51.6
  IMAGE_1.minCollectedColGSD=0.321
  IMAGE_1.minCollectedRowGSD=0.328
  IMAGE_1.minCrossTrackViewAngle=-3.1
  IMAGE_1.minInTrackViewAngle=-13.4
  IMAGE_1.minOffNadirViewAngle=13.7
  IMAGE_1.minSatAz=203.3
  IMAGE_1.minSatEl=74.6
  IMAGE_1.minSunAz=150.3
  IMAGE_1.minSunEl=51.6
  IMAGE_1.mode="FullSwath"
  IMAGE_1.PNIIRS=5.3
  IMAGE_1.positionKnowledgeSrc="R"
  IMAGE_1.resamplingKernel="MTF"
  IMAGE_1.revNumber=337
  IMAGE_1.rowUncertainty=22.29
  IMAGE_1.satId="WV03"
  IMAGE_1.scanDirection="Forward"
  MAP_PROJECTED_PRODUCT.colSpacing=0.40
  MAP_PROJECTED_PRODUCT.datumName="WE"
  MAP_PROJECTED_PRODUCT.datumOffset=(0.000,0.000,0.000)
  MAP_PROJECTED_PRODUCT.DEMCorrection="Base Elevation"
MAP_PROJECTED_PRODUCT.earliestAcqTime=2014-09-05T09:56:03.952766Z
  MAP_PROJECTED_PRODUCT.inverseFlattening=298.257223563
  MAP_PROJECTED_PRODUCT.latestAcqTime=2014-09-05T09:56:03.952766Z
  MAP_PROJECTED_PRODUCT.LLH=91.66
  MAP_PROJECTED_PRODUCT.LLX=297822.59991669
  MAP_PROJECTED_PRODUCT.LLY=4637861.7881
  MAP_PROJECTED_PRODUCT.LRH=91.66
  MAP_PROJECTED_PRODUCT.LRX=300084.59992299
  MAP_PROJECTED_PRODUCT.LRY=4637861.7884
  MAP_PROJECTED_PRODUCT.mapHemi="N"
  MAP_PROJECTED_PRODUCT.mapProjCode=1
  MAP_PROJECTED_PRODUCT.mapProjName="UTM"
MAP_PROJECTED_PRODUCT.mapProjParam=(0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0)
  MAP_PROJECTED_PRODUCT.mapZone=33
  MAP_PROJECTED_PRODUCT.numGCP=0
  MAP_PROJECTED_PRODUCT.orientationAngle=0.0
  MAP_PROJECTED_PRODUCT.originX=297822.59991646
  MAP_PROJECTED_PRODUCT.originY=4640476.5881
  MAP_PROJECTED_PRODUCT.productGSD=0.40
  MAP_PROJECTED_PRODUCT.productUnits="M"
  MAP_PROJECTED_PRODUCT.rowSpacing=0.40
  

Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption

[Dmitry Baryshnikov]

Hi,

I'm not a PSC member, but like to note the great work Kurt has done on 
C++11 compilation mode.


I strongly support this RFC.

Best regards,
Dmitry

06.09.17 19:14, Kurt Schwehr пишет:

Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by
the PSC on RFC68: C++11 compilation mode.

The draft is here:

  https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11

-Kurt



Hi Even,
The new SDK-s have now been added.
Best regards,
Tamas
2017-08-29 15:18 GMT+02:00 Tamas Szekeres :

Hi Even,
Yes, I'm planning to include msvc2015/2017 versions shortly.
Best regards,
Tamas
2017. aug. 14. dátummal, 19:02 időpontban Even Rouault <
even.roua...@spatialys.com> írta:

Hi Tamas,
Unless I'm mistaken your gisinternals.com builds don't include MSVC

2015 currently. Right ? Do you have any plans to do so ? Currently the
GDAL
AppVeyor target uses SDKSs from gisinternals to do builds with a

number of


third-party libraries.

Even

This is a call for discussion on RFC68 to set C++11 to be the

minimum


C++

language version for GDAL trunk. I've drafted the RFC based on

work by


Mateusz.
https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
There was initial discussions back in January of this year:

https://lists.osgeo.org/pipermail/gdal-dev/2017January/thread.html#45786


Cheers,
-kurt
Engineer at Google



___
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

Re: [gdal-dev] How to drop a raster layer from GeoPackage?

[Dmitry Baryshnikov]

Is it the bug of gdalmanage that this utility cannot delete raster layer 
from geopackage?


Best regards,
Dmitry

22.08.17 12:49, Even Rouault пишет:


On mardi 22 août 2017 09:42:40 CEST Rahkonen Jukka (MML) wrote:

> Hi,

>

> There is an interesting question in gis.stackexchange about how to 
remove a


> raster layer from GeoPackage

> 
https://gis.stackexchange.com/questions/252782/remove-a-raster-from-geopack


> age.

>

> I had a try and gdalmanage did not have any effect on the GeoPackage

> database but the workflow with ogrinfo works for me. Are there any other

> alternatives?

The manual ogrinfo way is the only one using GDAL utilities.

We should probably extend the -sql "DELLAYER:" syntax to work with 
raster tables as well. Actually I see we currently also catch "DROP 
TABLE " to drop the table and remove links in other tables in the 
vector case (so with th same effect as DELLAYER:x). Would you mind 
creating an enhancement ticket about that ?


There's ongoing work on the QGIS side (dev version only I guess) to 
offer in the DBManager a way to delete raster layers (issuing the SQL 
requests under the hood)


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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL build without big tiff support

[Dmitry Baryshnikov]

Hi,

it seem to me there is misprint here:

https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/gtiff/geotiff.cpp#L16195
instead of

> else if( nCompression == COMPRESSION_JPEG

should be

> else if( l_nCompression == COMPRESSION_JPEG


Without this fix I get such error in build without BIG TIFF Support: 
error C2597: illegal reference to non-static member 
'GTiffDataset::nCompression'


--
Best regards,
Dmitry

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

Re: [gdal-dev] Building GDAL on linux with minimal drivers

[Dmitry Baryshnikov]

Hi Gane,

You can try to use Cmake build of GDAL 
(https://github.com/nextgis-borsch/lib_gdal).


It can be configured via CMake-gui or command line.

This is an example of minimal static build of GDAL - 
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake#L94-L175


Best regards,
Dmitry

29.03.17 12:17, Gane R пишет:

Hi all,

I am looking for building gdal with minimal set of drivers like gdal 
with geotiff, jpg, png and sqlite gpkg


so it should do basic warp geotiff and work with geopkg raster. I 
don't need OGR part I need the core, alg and raster tif, gpkg, jpg and 
png alone is enought.

the problem is I get a fat static lib. I want to reduce its size.

I tried to follow the post 
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixWithMinimizedDrivers It 
seems it is old.


When I build i get error during building the apps like gdalinfo, 
gdalwarp 


Any suggestions

my ogr/ogrsf_frmts/GNUmakefile  is
like

include ../../GDALmake.opt

SUBDIRS-yes:= \
generic rec shape

SUBDIRS-$(HAVE_DODS)+= dods
SUBDIRS-$(HAVE_DWGDIRECT) += dxfdwg
SUBDIRS-$(HAVE_FME)+= fme
SUBDIRS-$(HAVE_GRASS)+= grass
SUBDIRS-$(HAVE_IDB)+= idb

I get the following error

/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined 
reference to `TABINDFile::~TABINDFile()'
/home/user/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined 
reference to `TABINDFile::FindNext(int, unsigned char*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_object_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Open(char const, char const, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateField(OGRFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_to_file'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`MITABSpatialRef2CoordSys(OGRSpatialReference*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_tokener_free'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int64'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_string'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetFeatureCount(int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_array_add'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_object'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_ExtendPosition(double, double, double, double, double*, 
double*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::SetNextByIndex(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::CreateGeomField(OGRGeomFieldDefn*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ResetReading()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::ICreateFeature(OGRFeature*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRXPlane_Distance(double, double, double, double)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::AddEntry(int, unsigned char*, int)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_put'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`json_object_new_double_with_precision'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::TestCapability(char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::DeleteFeature(long long)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_new_int'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::Close()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_get_type'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::GetNextFeature()'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`OGRMemLayer::OGRMemLayer(char const, OGRSpatialReference, 
OGRwkbGeometryType)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`TABINDFile::BuildKey(int, char const*)'
/home/user/x64/gdal-2.1.0/.libs/libgdal.so: undefined reference to 
`gdal_json_object_from_file'


Thanks
Gane


___
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

Re: [gdal-dev] shortest path or networks in GDAL

[Dmitry Baryshnikov]

Hi Djordje,

Default build of GNM in GDAL was enabled recently. I think this build is 
not available by GISInternals.


Try our (NextGIS) own build of GDAL from here: http://nextgis.com/borsch/

Best regards,
Dmitry

15.12.16 3:04, Djordje Spasic пишет:
I am wondering if it is possible to perform the shortest path or 
network analysis in Windows version of GDAL 
?
I googled and found gnmanalyse page on GDAL website, which seems to be 
able to do that:

http://www.gdal.org/gnmanalyse.html

But is this gnmanalyse functionality available only through GDAL 
C#/python binaries?


I can not access it directly by running GDAL Windows .exe files?

Thank you for the reply.


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


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

Re: [gdal-dev] CAD (DWG) Driver

[Dmitry Baryshnikov]

Hi Nigel,

Thank you for information. I think enhancing OpenCAD library with 
support of additional DWG versions is right way. I'll study your code.



Best regards,
Dmitry

21.11.16 13:10, Nigel Westbury пишет:

The DWG driver contribution is much appreciated.  It currently supports older 
versions of files up to R1015 (AutoCAD 2000).  The DWG format was relatively 
straight forward up to that version.  In 2004 the format became rather more 
complex, including simple xor encryption and LZ77 compression of most of the 
records.  In 2007 the format became considerably more complex again, including 
Reed-Solomon encoding.  In 2010 the format became simpler again, going back to 
a format more similar to the 2004 format.  Our experience here at 1Spatial is 
that customers are on versions 2010 or 2013.  I have not received a DWG file 
from an earlier version from a customer.  Therefore we have implemented a 
library for reading versions 2010 and later 
(https://github.com/westbury/dwg-lib).  This has been implemented in Java and 
could readily be ported to C or otherwise compiled to a DLL, though as it is 
currently under active development this would need some thought to avoid 
maintaining two copies.  Alternatively we could leave it in Java and call it 
much as the GDAL GeoMedia driver does for Jackcess.   We have put the code 
under the MIT licence so that it would be available to GDAL.  The work was 
implemented by reference to the Open Design Specification for .dwg files 
Version 5.3.  We do plan on limited writing too, but probably updates to 
certain elements only, no support for outputting a complete DWG file from 
scratch.

Nigel Westbury

-Original Message-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of 
gdal-dev-requ...@lists.osgeo.org
Sent: 19 November 2016 19:49
To: gdal-dev@lists.osgeo.org
Subject: gdal-dev Digest, Vol 150, Issue 33

Send gdal-dev mailing list submissions to
gdal-dev@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/gdal-dev
or, via email, send a message with subject or body 'help' to
gdal-dev-requ...@lists.osgeo.org

You can reach the person managing the list at
gdal-dev-ow...@lists.osgeo.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of gdal-dev digest..."


Today's Topics:

1. Re: CAD (DWG) Driver (Even Rouault)
2. Re: CAD (DWG) Driver (Kurt Schwehr)
3. Re: CAD (DWG) Driver (Even Rouault)
4. Re: CAD (DWG) Driver (Dmitry Baryshnikov)
5. Re: identifying the fields from the .osm file (Djordje Spasic)


--

Message: 1
Date: Sat, 19 Nov 2016 17:49:25 +0100
From: Even Rouault <even.roua...@spatialys.com>
To: Dmitry Baryshnikov <bishop@gmail.com>, schw...@gmail.com,
gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] CAD (DWG) Driver
Message-ID: <7873061.FYxrsrM0Qa@even-i700>
Content-Type: text/plain; charset="us-ascii"

On samedi 19 novembre 2016 19:34:02 CET Dmitry Baryshnikov wrote:

Hi Even,

The big_endian test now is ok. But osx crash at the exiting of python
after all test finished successfully.

This is error message:

libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: mutex lock failed: Invalid argument
./gdal/ci/travis/osx/script.sh: line 13: 56363 Abort trap: 6
python run_all.py

I find out that this may be the result of resources free order:
https://github.com/dmlc/mxnet/issues/309
https://github.com/google/benchmark/issues/52

No idea why this occurred then C++11 used. I'll try to use osx CI test
disabling the CAD driver to exclude this possible issue.


Hum, I think this might be indeed an issue with resource free order between the 
GDALDestroy() destructor function (in gcore/gdaldllmain.cpp) and the static 
C++11 mutex Kurt introduced in
https://github.com/OSGeo/gdal/commit/a9b947d6850d496f09e668f4cd148826d45d9fa9

If this mutex gets destroyed before GDALDestroy() is called, then things might 
indeed crash.

I think we should remove this static C++11 mutex. Kurt ?

(Another option would be to remove the library destructor function. I've the 
feeling they cause more harm than good.)

--
Spatialys - Geospatial professional services http://www.spatialys.com


--

Message: 2
Date: Sat, 19 Nov 2016 10:06:26 -0800
From: Kurt Schwehr <schw...@gmail.com>
To: Even Rouault <even.roua...@spatialys.com>
Cc: Dmitry Baryshnikov <bishop@gmail.com>, gdal dev
<gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] CAD (DWG) Driver
Message-ID:

Re: [gdal-dev] CAD (DWG) Driver

[Dmitry Baryshnikov]

I commented out the C++11 mutex in gdaldrivermanager.cpp 
<https://github.com/OSGeo/gdal/pull/164/commits/d1449e2eb5a85a6ec2520ad77ee579015fe14197#diff-e3e90e0089f1b70ddf36ebe89a73a733> 
- this helps. OSX CI test passed successfully.


https://travis-ci.org/OSGeo/gdal/jobs/177297023

Best regards,
Dmitry

19.11.16 21:24, Even Rouault пишет:

On samedi 19 novembre 2016 10:06:26 CET Kurt Schwehr wrote:

I'm really not sure.

Not sure that the crash mentionned by Dmitry is related to that ? It looks
like a really good canditate to me. That's the only C++11 mutex in GDAL, with
2  other ones in the GeoTIFF driver (and those are likely not triggered at
process termination)


You can certainly try removing that C++11 mutex.  It was added based on the
comment at that point in the code.  We'll just have to keep an eye out for
possible occasional flakes.  If that's the case, we'll need to carefully
work through the logic and try to figure out a solution that works for
everything.

I doubt we will see flakes related to that. The mutex was added to prevent
races in GDALDestroyDriverManager(), but I'm not aware of code in GDAL and its
utilities that would call it from several threads. And the function has always
been documented as thread-unsafe.


+1 for getting the driver into the tree.  It will be easier to make
additional changes to either it or GDAL with it in the same tree.

On Sat, Nov 19, 2016 at 8:49 AM, Even Rouault <even.roua...@spatialys.com>

wrote:

On samedi 19 novembre 2016 19:34:02 CET Dmitry Baryshnikov wrote:

Hi Even,

The big_endian test now is ok. But osx crash at the exiting of python
after all test finished successfully.

This is error message:

libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: mutex lock failed: Invalid argument
./gdal/ci/travis/osx/script.sh: line 13: 56363 Abort trap: 6
python run_all.py

I find out that this may be the result of resources free order:
https://github.com/dmlc/mxnet/issues/309
https://github.com/google/benchmark/issues/52

No idea why this occurred then C++11 used. I'll try to use osx CI test
disabling the CAD driver to exclude this possible issue.

Hum, I think this might be indeed an issue with resource free order
between
the GDALDestroy() destructor function (in gcore/gdaldllmain.cpp) and the
static C++11 mutex Kurt introduced in
https://github.com/OSGeo/gdal/commit/a9b947d6850d496f09e668f4cd1488
26d45d9fa9

If this mutex gets destroyed before GDALDestroy() is called, then things
might
indeed crash.

I think we should remove this static C++11 mutex. Kurt ?

(Another option would be to remove the library destructor function. I've
the
feeling they cause more harm than good.)

--
Spatialys - Geospatial professional services
http://www.spatialys.com




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

Re: [gdal-dev] CAD (DWG) Driver

[Dmitry Baryshnikov]

Hi Even,

The big_endian test now is ok. But osx crash at the exiting of python 
after all test finished successfully.


This is error message:

libc++abi.dylib: terminating with uncaught exception of type 
std::__1::system_error: mutex lock failed: Invalid argument
./gdal/ci/travis/osx/script.sh: line 13: 56363 Abort trap: 6   python 
run_all.py

I find out that this may be the result of resources free order:
https://github.com/dmlc/mxnet/issues/309
https://github.com/google/benchmark/issues/52

No idea why this occurred then C++11 used. I'll try to use osx CI test 
disabling the CAD driver to exclude this possible issue.

Best regards,
Dmitry

19.11.16 17:18, Even Rouault пишет:

On samedi 19 novembre 2016 16:52:09 CET Dmitry Baryshnikov wrote:

Hi,

I fixed all reported by Even and Kurt errors and recommendations in CAD
(DWG) driver and most of recommendations in OpenCAD library. The pull
request (https://github.com/OSGeo/gdal/pull/164) passed all the checks
successful. It seems to me the driver is ready to merge to the trunk.
This will simplify testing and reviewing the new driver by community.

There are some problems in big_endian and xcode CI tests, because of
C++11 compiler flags (not a problem of CAD driver code, etc.) - I
disable C++11 (and appropriate the CAD driver too) in this tests. It
seems to me that not blocking issue and I can merge the code to trunk.

Are there any objections?

Massive +1

I've just noticed your comment https://github.com/OSGeo/gdal/pull/
164#issuecomment-261525037 about the issue with C++11 in the GeoTIFF driver.
I've just fixed that code, so you can now likely re-enable C++11 in the
big_endian and mac envs




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

Re: [gdal-dev] CAD (DWG) Driver

[Dmitry Baryshnikov]

Hi Jeff,

This driver has no external dependencies (we use an internal copy of 
OpenCAD library). So it builds without any problem.


Best regards,
Dmitry

19.11.16 18:42, Jeff McKenna пишет:

On 2016-11-19 9:52 AM, Dmitry Baryshnikov wrote:

Hi,

I fixed all reported by Even and Kurt errors and recommendations in CAD
(DWG) driver and most of recommendations in OpenCAD library. The pull
request (https://github.com/OSGeo/gdal/pull/164) passed all the checks
successful. It seems to me the driver is ready to merge to the trunk.
This will simplify testing and reviewing the new driver by community.

There are some problems in big_endian and xcode CI tests, because of
C++11 compiler flags (not a problem of CAD driver code, etc.)  - I
disable C++11 (and appropriate the CAD driver too) in this tests. It
seems to me that not blocking issue and I can merge the code to trunk.

Are there any objections?

Just a note: the OpenCAD library and GDAL CAD driver were developed
during Google Summer of Code 2016.



Could you also be sure to document this driver (and its build steps 
for unix and windows) at https://trac.osgeo.org/gdal/wiki/BuildHints 
?  You could list your driver there with the others in the section 
"External Library Issues"


Thanks!

-jeff






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

Re: [gdal-dev] Changes in Travis-CI setup + AppVeyor

[Dmitry Baryshnikov]

Hi Even,

Bravo! Well done!

Best regards,
Dmitry

02.11.16 17:38, Even Rouault пишет:

Hi,

I've refactored a bit the way the multiple test configurations are managed with
Travis-CI. Previously there was a default single test environment (Precise
64bit) in .travis.yml in trunk, and I had a cron job that merged trunk into
custom git branches with different .travis.yml configurations for other test
environments.
One major drawback of this is that those alternate configurations were not
tested for pull requests, or when developing a custom branch.
I've now changed that to use the possibility of doing matrices in .travis.yml.
The various scripts are now in gdal/ci/travis/${BUILD_NAME}

I've also enabled ccache builds in most setups, which speed up builds.

One of the only advantage of having different git branches for different
environments was to be able to have different badges. But I just found
https://github.com/exogen/badge-matrix which offer a way of having badges per
matrix item, so this is now used in
https://github.com/OSGeo/gdal/blob/trunk/README.md

There are a few custom builds that are still managed the old way :
- the one that creates the test coverage. Could potentially be merged into the
main one, but as we upload coverage results in the result repository only for
changes, that's not useful for PR / feature branches. Plus there is an
encrypted variable that should be re-encrypted for the OSGeo/gdal repository
- the one that runs the clang static analyzer checks. Its length is very close
to the timeout limit of Travis-CI jobs, so it regularly fails, and given its
length, it wouldn't be very valuable for quick feedback. Currently it runs at
most 1 time per hour.

For AppVeyor, I've migrated the appveyor.yml for the vc12_full branch into
trunk (which is the one with the most dependencies), so it is now available
for pull requests. A matrix based approach could likely be done too to test
different versions (current setup test x86 and x64 builds), but I didn't pursue
that. So the vc9 and vc13 branches are still using the old merge-from-trunk
approach.


Even



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

Re: [gdal-dev] Time for 2.1.2 ?

[Dmitry Baryshnikov]

Hi,

What do you think about enabling GNM (network model) build by default in 
2.1.2?


GNM using in QNetwork plugin in QGIS and via command line utilities but 
not available by default and only small number users can get it.


I think if we enable GNM by default we can get more user feedback.

Best regards,
Dmitry

10.10.16 20:07, Even Rouault пишет:

Hi,

I'd like to prepare a RC for a 2.1.2 bugfix release on Friday, unless someone
needs more time to push a fix. If there are outstanding issues not yet in the
2.1 branch and that would need to be considered for inclusion, speak up.

The current fixes done since 2.1.1 are:
https://trac.osgeo.org/gdal/query?status=closed=resolution=2.1.2
and probably most of those in:
https://trac.osgeo.org/gdal/query?status=closed=resolution=2.0.4

Even



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

[gdal-dev] CAD (DWG) Driver

[Dmitry Baryshnikov]

Hi,

It seems to me the CAD (DWG) driver developed during Google Summer of 
Code 2016 is ready to merge into the trunk.


The pool request (https://github.com/OSGeo/gdal/pull/145) passed all 
checks. Are there any objections?


--
Best regards,
Dmitry

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

Re: [gdal-dev] R: Problem using ogrlineref

[Dmitry Baryshnikov]

Hi Dan,

Feel free to rewrite the docs more understandable.
You have to fork https://github.com/OSGeo/gdal
make changes to 
https://github.com/OSGeo/gdal/blob/trunk/gdal/apps/ogr_utilities.dox

and provide pull request.
Also, look at man pages of other utilities as an example how it should 
be done (i.e. http://gdal.org/ogr2ogr.html).


Best regards,
Dmitry

02.07.2016 01:19, 積丹尼 Dan Jacobson пишет:

Well OK but the Debian guy closed all my bug reports instantly,
and on the man page you will need to give full examples, including input file 
content,
before any of this becomes understandable. Thanks.



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

Re: [gdal-dev] R: Problem using ogrlineref

[Dmitry Baryshnikov]

Hi Dan,

I see your tickets on debian bug tracker.
1. ogrlineref support all GDAL vector drivers with write capability
2. You didn't set -f (format) option, so default driver was set - ESRI 
shape file

3. I reproduce segmentation fault (will be fixed soon)
4. Current implementation have the only option to return distance along 
line for some geographic coordinates and coordinates for distance. So 
you need to loop every 500 meters to get what you want.
5. We tested using ogrlineref without any repers (reference point, 
milestones) and it works. You only need to add to OGRLayer three fields 
(beg type of REAL, end type of REAL and scale type of REAL).
6. KML is not good format as ogrlineref expect some attributes filled, 
but KML usually has the few attributes (NAME and Description). In that 
case ogrlineref cannot get some sensitive data from attributes.


Best regards,
Dmitry

01.07.2016 10:10, 積丹尼 Dan Jacobson пишет:

I am trying to use the ogrlineref command.
I can't even understand its man page.
Maybe it only works on shapefiles.
Maybe it only Seg Faults.

How can I get the locations of the kilometer markers given only this KML:


   zaokeng main road 中45市道
   
 1
 120.86817,24.17922,0.0 120.86816,24.17922,0.0...
   


Let's say put the output into a new KML file.

OK maybe I need these redundant starting and ending points too:

   Start
   
 120.86817,24.17922,0.0
   


   End
   
 120.86696,24.16733,0.0
   


Anyway the man page is just a mishmosh to me.

Maybe if you show me how to do it, then I can figure out what "reper"
points are. They certainly aren't English. Maybe I don't need "reper"
points. Maybe I am trying to produce "reper" point.
Nobody knows.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


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

Re: [gdal-dev] Build GDAL for android via NDK

[Dmitry Baryshnikov]

Hi Gane,

I build GDAL 2.1 using NDK and borsch build system, based on CMake.
There are some limitations - I only need GDAL in my own c++ library. So 
I created swig bindings for my own library, not use GDAL Java bindings 
(GDAL java binding is not ready yet).
Here it is the link for library which build GDAL and dependency 
libraries - https://github.com/nextgis/nextgis_datastore (especially 
https://github.com/nextgis/nextgis_datastore/blob/master/cmake/extlib.cmake)
Here it is an example of using such library - 
https://github.com/nextgis/android_maplib/tree/ndk (fixed gradle build 
script https://github.com/nextgis/android_maplib/blob/ndk/build.gradle 
and NDK makefiles 
https://github.com/nextgis/android_maplib/tree/ndk/src/main/jni)
Everything works in Android Studio - GDAL and dependencies downloaded 
from github, and build (rather long as build done for each ABI), results 
*.so files and headers copied to jni directory and swig bindings too. 
The exported functions are ready and work in android application.


This is not finished solution, but I hope it will be helpful.

Best regards,
Dmitry

10.06.2016 22:07, Gane R пишет:

Hi all,

I saw a link for Building GDAL for android on linux

https://trac.osgeo.org/gdal/wiki/BuildingForAndroid

Is it updated ?, I tried to build on centOS, It took the android linux 
compiler. The make resulted in a error. gdal 2.1.0


Is there any updated document or any one having personal experience in 
building GDAL for android or any documentation that has worked will be 
of great help.



Gane




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


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

Re: [gdal-dev] R: Problem using ogrlineref

[Dmitry Baryshnikov]

Hi Nicola,

The first and last segments usually have beg and end fields value not a 
multiple of 1000.

I.e. begin = 576 m, end 1000 m or begin 76200 m, end 76234 m
This is ok, and ogrlineref correctly woks with this case.

I think, that you can try to play with your data without equal parts 
sizes. But ogrlineref need - beg (double), end(double) and scale 
(double) fields.

Scale - is spatial length of you part divided on linear lenght.
I.e. scale = part.get_Length() / (end - beg)

Best regards,
Dmitry

07.06.2016 18:25, Nicola Baraldo (ICONSULTING) пишет:


Hi Dmitry,

thank you for you response. There is a way to do the step 2 using GDAL?

Moreover, if the path lengths are not multiple of the split size (e.g. 
1000m), how the last segment is handled?


Best regards,

Nicola

*Da:*gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] *Per conto di 
*Dmitry Baryshnikov

*Inviato:* martedì 7 giugno 2016 16:16
*A:* gdal-dev@lists.osgeo.org
*Oggetto:* Re: [gdal-dev] Problem using ogrlineref

Hi Nicola,

The idea of ogrlineref was follow:
1. You have layer with some lines and some reper points with known 
linear coordinates
2. The reper points divide lines on equal parts (e.i. 1000 m) - this 
is important that parts should be equal
3. The result file will have special structure (required fields: beg, 
end, scale, and some optional)
4. During referencing  ogrlineref make attribute query and get needed 
part based on beg and end fields (which is rather fast), and than calc 
point position inside this part.


In your case, the simple way is to extract begin and end point of your 
lines and make them reper points. After that all steps are usual.


There is no sense to move other fields into the parts file from your 
original datasource. But you can use -lf option to store some value 
and use it in future for join with your original data.


Best regards,
 Dmitry

07.06.2016 15:19, Nicola Baraldo (ICONSULTING) пишет:

Hi guys,

I am trying to split some routes into segments of the same length
(dynamic segmentation) using ogrlineref command.

My data is stored in a shapefile containing a set of paths, for
each path I know the length in meters.

I have tried ogrlineref with –create, –get_coord and - get_subline.

For the first option I don’t have a reper datasource to provide
because I don’t have mile-stones, are they really necessaries?

The second and third options give me the following error for each
path contained in the input shapefile; with –get_coord I have
tried both options “–m 0” and “–m 1000”, with –get_subline I have
tried “-mb 0 -me 1” options.



Can someone help me using this command? Is there a better way to
perform dynamic segmentation using GDAL?

Moreover my shapefile contains also a lot of other fields, there
is a way to keep these information also in the output file?

Thanks,

Nicola



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>

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



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


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

Re: [gdal-dev] Problem using ogrlineref

[Dmitry Baryshnikov]

Hi Nicola,

The idea of ogrlineref was follow:
1. You have layer with some lines and some reper points with known 
linear coordinates
2. The reper points divide lines on equal parts (e.i. 1000 m) - this is 
important that parts should be equal
3. The result file will have special structure (required fields: beg, 
end, scale, and some optional)
4. During referencing  ogrlineref make attribute query and get needed 
part based on beg and end fields (which is rather fast), and than calc 
point position inside this part.


In your case, the simple way is to extract begin and end point of your 
lines and make them reper points. After that all steps are usual.


There is no sense to move other fields into the parts file from your 
original datasource. But you can use -lf option to store some value and 
use it in future for join with your original data.


Best regards,
Dmitry

07.06.2016 15:19, Nicola Baraldo (ICONSULTING) пишет:


Hi guys,

I am trying to split some routes into segments of the same length 
(dynamic segmentation) using ogrlineref command.


My data is stored in a shapefile containing a set of paths, for each 
path I know the length in meters.


I have tried ogrlineref with –create, –get_coord and - get_subline.

For the first option I don’t have a reper datasource to provide 
because I don’t have mile-stones, are they really necessaries?


The second and third options give me the following error for each path 
contained in the input shapefile; with –get_coord I have tried both 
options “–m 0” and “–m 1000”, with –get_subline I have tried “-mb 0 
-me 1” options.




Can someone help me using this command? Is there a better way to 
perform dynamic segmentation using GDAL?


Moreover my shapefile contains also a lot of other fields, there is a 
way to keep these information also in the output file?


Thanks,

Nicola


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


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

Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit

[Dmitry Baryshnikov]

2Jeff

This is the only one example of building GDAL and other libraries and 
this is not CMake problem of MapScript support, but MapServer's team 
priorities.


Building libraries for MS4W is only one activity. But there are lot of 
others which developer may need:


- configure GDAL and dependencies via GUI in crossplatform manner
- configure GDAL and dependencies in make scripts of developer's 
application in crossplatform manner (for example I build my library with 
GDAL and it dependencies for Android/iOS with needed set of drivers and 
options and toolsets, and use the same cmake as for desktop/server)

- build software and dependency with one set of compiler/linker
- generate projects for supported RAD utilities
- etc.

2Alex

The list is silent as we already discussed CMake in GDAL so many times.
There is no problem that two versions of build system exists - original 
and cmake.
All contribution goes to GDAL trunk. Periodically I sync trunk with 
nextgis-borsch/lib_gdal


The borsch cmake scripts are not stable yet and we are still fixing them.
Now I don't see any topic to discuss here.

2All
By the way I'll have a talk about this new build system on FOSS4G Bonn, 
this will be good place to discuss this.


Best regards,
Dmitry

31.05.2016 15:00, Jeff McKenna пишет:

On 2016-05-31 8:46 AM, alex wrote:


Hi Dmitry and others,

I can see that you are making a great effort, and as far as I can 
tell with great progress too.


Do you know why the rest of the list is silent on this? Are the GDAL 
developers not interested in cmakeification or are they in silent 
agreement with your approach?


I for one am not interested in 'cmakeification' of GDAL.  For the MS4W 
community, I build 32 and 64 bit versions, for the full stack of 
Apache, PHP, MapServer, GDAL (I counted recently and it is now over 
200 libraries) - and the few projects that use cmake are the 
troublesome ones.  (for example, MapServer switched to cmake but no 
one is maintaining the mapscript parts of cmake, which means I have 
kept my own makefiles alive, in order to build all of MapServer).


I am very against cmake, I have had terrible experiences.  I am all 
for sharing our makefiles and making life easier, than using a fancy 
cmake system that is not maintained.


-jeff



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

Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit

[Dmitry Baryshnikov]

Hi Alex,

The work is done taking into considerations this link: 
https://trac.osgeo.org/gdal/wiki/CMake
Also, there were some ideas about gdal source code reorganisation in 
dev-list.

This is second turn of cmakefication of GDAL.
The lib_gdal repository synced with gdal trunk periodically (there is a 
python script in etc folder 
(https://github.com/nextgis-borsch/lib_gdal/blob/master/etc/cmake-build-helpers/gdal_restructure.py) 
to do it). Now the sources are 2.1 release version. The different GDAL 
version support will be added in future.


I think current lib_gdal is not ready to switch trunk (not all drivers 
ready, not all bindings ready, etc.), but very close (see 
https://github.com/nextgis-borsch/lib_gdal/blob/master/README.md about 
work status).


Best regards,
Dmitry

27.05.2016 14:56, alex пишет:

[Alex]
Is there a convention about where to place and how to name the win32 and

x64

libraries and include directories when building for both platforms on
Windows?

Especially, I would like CMake's FindGDAL
(https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to

find

the correct paths automatically.


[Dmitry Baryshnikov]

Hi,
It seems to me there is no standard install path on Windows, so search
GDAL is tricky.
CMake can register package in registry and so find GDAL, but GDAL have
to be CMaked too.

You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal).
In your project only need to add find_anyproject(GDAL), see -
https://github.com/nextgis-borsch/borsch.
GDAL will be downloaded, build and linked with your project.


Hi Dmitry,

Thanks, that looks very useful and addresses a major headache. I am a bit 
reluctant to include further dependencies and straying from the 'official' GDAL 
repository and processes.

Is there any chance that your efforts will make it to a future GDAL release?

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


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

Re: [gdal-dev] Building GDAL on Windows 32 and 64 bit

[Dmitry Baryshnikov]

Hi,
It seems to me there is no standard install path on Windows, so search 
GDAL is tricky.
CMake can register package in registry and so find GDAL, but GDAL have 
to be CMaked too.


You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal). 
In your project only need to add find_anyproject(GDAL), see - 
https://github.com/nextgis-borsch/borsch.

GDAL will be downloaded, build and linked with your project.

Best regards,
Dmitry

27.05.2016 11:55, alex пишет:

Hi,

Is there a convention about where to place and how to name the win32 and x64
libraries and include directories when building for both platforms on
Windows?

Especially, I would like CMake's FindGDAL
(https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to find
the correct paths automatically.

Thanks, Alex

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


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

Re: [gdal-dev] Starting a discussion on style and coding guidelines

[Dmitry Baryshnikov]

Hi,

I think it's time to go forward and shift to C++11 in i.e. GDAL 2.2 and 
drop old staff as it was with Windows mobile support, VB, etc.
Yes, it may be some regression in ABI, but this is less evil than 
support lot of ancient compilers.


During our work on cmake build system for GDAL I faced that some 
dependency library needs VC2013SP2 on Windows - i.e liblzma, as it needs 
C99.
We worked around it by including some logic to cmake, that if VC 
compiler is less than specific version the support of dependent features 
will be disabled.


By the way, the repo with cmake for GDAL is here: 
https://github.com/nextgis-extra/lib_gdal
The ubuntu ppa of libgdal2 build using cmake: 
https://launchpad.net/~nextgis/+archive/ubuntu/ppa/+packages

Windows builds also using cmake: http://nextgis.ru/en/borsch/

Please note, that most but not all drivers are available now (for 
details see readme in repo) and only python bindings.


Best regards,
Dmitry

05.05.2016 02:45, Even Rouault пишет:

Le jeudi 05 mai 2016 00:51:28, Mateusz Loskot a écrit :

On 4 May 2016 at 23:30, Kurt Schwehr  wrote:

To start off the conversation, I wrote up a doc on changing large C
arrays on the stack to std::vectors to get this data off of the stack
and to simplify initialization.

Since many, if not most, of the ideas rely on availability of the C++11
features,
it might be a good idea to first agree on C++11 as the lowest
required C++ compilation mode.

Let's poll if there are any users who require C++03 at all.

I think there are different topics in what Kurt proposes :
- style and other changes that are not bound to a particular compiler version
- changes potentially dependant of the C++ version

Of the potential issues with requiring C++11, I can think of OSGeo4W. It is
mostly(completely?) built with Visual Studio 2010. And from
https://msdn.microsoft.com/en-us/library/hh567368.aspx , support of C++11 is
only partial in VS 2010

Regarding the current use of VS2010 in OSGeo4W, this is discussed here :
https://lists.osgeo.org/pipermail/discuss/2016-February/015658.html

Potentially we could imagine having GDAL compiled with a later VS version and
have the rest using VS2010, since most (all?) other software in OSGeo4W use it
probably through its C API. Hum, actually that must not be true for OTB that
uses the C++ API I think. Perhaps Jürgen has something to add regarding this
compiler issue ?

On the other hand regarding dependencies of GDAL, the binary propritary SDKs
with a C++ API could be a problem, although they will likely move on too.
- FileGDB SDK 1.4: available for VS2010, VS2012, VS2013
- ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
- MrSID SDK: I didn't check. Perhaps Kirk can tell us ?
But I'm not sure about the compatibility of C++11 build against non-C++11
builds in the VS realm : can a GDAL C++11 build link against a library built
without C++11 enabled ? Will not there be ABI problems ?

Even



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

[gdal-dev] GSoC 2016

[Dmitry Baryshnikov]

Hello GSoC students!

I created the section about GSoC 2016 
(https://trac.osgeo.org/gdal/wiki/SoCProjects) in GDAL wiki.
Please write your project texts as was done previous years and provide 
them to your mentors to publish them at appropriate wiki pages.

Don't afraid some duplication the OSGeo wiki.

--
Best regards,
Dmitry

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

Re: [gdal-dev] ogr2ogr failing on postgis?

[Dmitry Baryshnikov]

Hi Paolo,

It seems to me that your shape spatial reference not present in 
spatial_ref_sys and GDAL try to import it into spatial_ref_sys.

Your shape file have such SRS:
PROJCS["Monte_Mario_Italy_zone_1",GEOGCS["GCS_Monte 
Mario",DATUM["D_Monte_Mario",SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",150],PARAMETER["false_northing",0],UNIT["Meter",1]]


If I execute such SQL: select * from spatial_ref_sys where srtext like 
'%Monte_Mario%' I received:


4265;"EPSG";4265;"GEOGCS["Monte 
Mario",DATUM["Monte_Mario",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6265"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745 
(...)"
4806;"EPSG";4806;"GEOGCS["Monte Mario 
(Rome)",DATUM["Monte_Mario_Rome",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6806"]],PRIMEM["Rome",12.452333,AUTHORITY["EPSG","8906"] 
(...)"
3003;"EPSG";3003;"PROJCS["Monte Mario / Italy zone 1",GEOGCS["Monte 
Mario",DATUM["Monte_Mario",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6265"]],PRIMEM["Greenwich",0,AUTHORITY[" 
(...)"
3004;"EPSG";3004;"PROJCS["Monte Mario / Italy zone 2",GEOGCS["Monte 
Mario",DATUM["Monte_Mario",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6265"]],PRIMEM["Greenwich",0,AUTHORITY[" 
(...)"
26591;"EPSG";26591;"PROJCS["Monte Mario (Rome) / Italy zone 1 
(deprecated)",GEOGCS["Monte Mario 
(Rome)",DATUM["Monte_Mario_Rome",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6806"]], 
(...)"
26592;"EPSG";26592;"PROJCS["Monte Mario (Rome) / Italy zone 2 
(deprecated)",GEOGCS["Monte Mario 
(Rome)",DATUM["Monte_Mario_Rome",SPHEROID["International 
1924",6378388,297,AUTHORITY["EPSG","7022"]],TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68],AUTHORITY["EPSG","6806"]], 
(...)"


I think you need to reproject shape file to EPSG: 3003 or defined it for 
shape file.


Best regards,
Dmitry

10.04.2016 18:23, Paolo Cavallini пишет:

Hi all,
I have an ogr2ogr command, from shp to pg, that fails because it
requests write access to spatial_ref_sys. An apparently identical
command on another file runs smoothly. Any hint?
Details and data documented here:
http://hub.qgis.org/issues/14650
Thanks.


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

Re: [gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hi Sarthak,

Thanks for submitting your proposal. Proposals are frozen at this point.
Right now we're completing ranking and waiting for Google to assign slots.

Best regards,
Dmitry

06.04.2016 14:49, sarthak agarwal пишет:

Hello Dmitry,

As you know I did submit the proposal on the GSoC portal but there has 
been no discussion of any kind.

I also completed my GSoC task(fixed the bug) on time.

So I request you to kindly review my proposal once and provide your 
feedback. I will make the necessary changes or if you want to change 
the idea and implementation we can work on that also.
I am really interested in applying for the program and contibuting to 
gdal.


Regards,
Sarthak

On Sat, Mar 26, 2016 at 12:13 AM, sarthak agarwal 
<sarthak0...@gmail.com <mailto:sarthak0...@gmail.com>> wrote:


I have submitted the proposal, please check it once and provide
your feedback.

Sarthak

On Fri, Mar 25, 2016 at 2:01 PM, Dmitry Baryshnikov
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:

Hi Sarthak,

Thank you for you note, but I already wrote:

>Don't wait for anybody with proposal. The new GSoC site
is right place to discuss proposals.

So I expected to see and comment, if needed, your proposal on
this site. Let me remind you the site -
https://summerofcode.withgoogle.com/

Best regards,
 Dmitry

25.03.2016 10:17, sarthak agarwal пишет:

The deadline is today.

Sarthak

On Thu, Mar 24, 2016 at 1:52 AM, sarthak agarwal
<sarthak0...@gmail.com <mailto:sarthak0...@gmail.com>> wrote:

Hello Dmitry,

I fixed the bug (I guess).
Now coming to my proposal for GSoC, So I was thinking of
working on project #4 *Auto-detection of EPSG codes from
incomplete WKT.*

What I understood from the project is that we need to
predict the EPSG code of certain files on the basis of
some attributes which are available in the file.

The attributes can be extracted from the file for which I
read this
<http://www.gdal.org/osr_tutorial.html#querying_coordinate_system>.

Now to solve this problem I thought a lot of methods but
I think the best way to solve it will be using machine
learning.

The way ML will handle this problem is as follows-

 1. We need to find the EPSG code for a file (testing data)
 2. We have a file with some attributes
(projections,datum,etc ).
 3. We need to the guess the best suitable class for that
file(EPSG)
 4. Also, we have many files for which we know the
attributes and the corresponding class (training data).

This problem is now translated into an ML problem which
can be solved using the following models-

1. Bayesian Stastics
<https://en.wikipedia.org/wiki/Posterior_probability>

where,
posteriror probability = probability of this file
have EPSG code 'a'.
prior probability = probability of occurence of EPSG
code 'a'.

likelihood probablity = cases where we saw such
attributes when the EPSG code is 'a'.


2. or we can use a simple knn where k is the number of
possible EPSG code and the dimension of the feature
vector is the number of possible attributes. we need to
the find a valid and promising weight function).


3. We can use multi-class SVM.

4. any other suggestion from the community regarding the
possible choice of the algo.

I am thinking of actually implementing all these algo(may
add algo in future depending upon the suggestion) and
select the algo which gives the best performance among
all of them.

Please provide me feedback on my proposal and suggestion
if I can add/change anything.
And since very less time is left in the deadline, I would
like to convert it into proposal ASAP with your help.

Regards,
Sarthak

​






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

Re: [gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hi Sarthak,

Thank you for you note, but I already wrote:

>Don't wait for anybody with proposal. The new GSoC site is right 
place to discuss proposals.


So I expected to see and comment, if needed, your proposal on this site. 
Let me remind you the site - https://summerofcode.withgoogle.com/


Best regards,
Dmitry

25.03.2016 10:17, sarthak agarwal пишет:

The deadline is today.

Sarthak

On Thu, Mar 24, 2016 at 1:52 AM, sarthak agarwal 
> wrote:


Hello Dmitry,

I fixed the bug (I guess).
Now coming to my proposal for GSoC, So I was thinking of working
on project #4 *Auto-detection of EPSG codes from incomplete WKT.*

What I understood from the project is that we need to predict the
EPSG code of certain files on the basis of some attributes which
are available in the file.

The attributes can be extracted from the file for which I read
this
.

Now to solve this problem I thought a lot of methods but I think
the best way to solve it will be using machine learning.

The way ML will handle this problem is as follows-

 1. We need to find the EPSG code for a file (testing data)
 2. We have a file with some attributes (projections,datum,etc ).
 3. We need to the guess the best suitable class for that file(EPSG)
 4. Also, we have many files for which we know the attributes and
the corresponding class (training data).

This problem is now translated into an ML problem which can be
solved using the following models-

1. Bayesian Stastics


where,
posteriror probability = probability of this file have EPSG
code 'a'.
prior probability = probability of occurence of EPSG code 'a'.

likelihood probablity = cases where we saw such attributes
when the EPSG code is 'a'.


2. or we can use a simple knn where k is the number of possible
EPSG code and the dimension of the feature vector is the number of
possible attributes. we need to the find a valid and promising
weight function).


3. We can use multi-class SVM.

4. any other suggestion from the community regarding the possible
choice of the algo.

I am thinking of actually implementing all these algo(may add algo
in future depending upon the suggestion) and select the algo which
gives the best performance among all of them.

Please provide me feedback on my proposal and suggestion if I can
add/change anything.
And since very less time is left in the deadline, I would like to
convert it into proposal ASAP with your help.

Regards,
Sarthak

​

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

Re: [gdal-dev] [GSOC] Student introduction

[Dmitry Baryshnikov]

Hi Pero,

I previously wrote the letter to this mailing list, what we expected 
from the GSoC students. We expected from students who interested in GSoC:
1. To close some GDAL ticket and send pull request (the list of 
recommended tickets was in letter) - this is need to us to understand 
the student's skills and some experience with GDAL sources.

2. To describe the GSoC idea in details.

Some students disappeared not starting the tickets fixing, some after 
beginning work on tickets, some successfully fulfilled all the tasks.


There is one student who did everything what I wrote and wants to work 
on GSoC idea - DWG driver for GDAL. Also his skills match the level of 
this task.
Unfortunately you came so late. Usually students who plan to participate 
in GSoC begins the work with community more earlier (several months).


Best regards,
Dmitry

18.03.2016 21:54, Pero Brbora пишет:

Hi,
My name is Pero Brbora, student of Applied/Business Computing, 
University of Dubrovnik, Croatia . I'm full time 
empolyed in Cadastral Surveying industry and part-time student, so 
CAD/GIS related projects were on my GSOC look up list.


I noticed "DWG driver without third party libraries" idea on your GSOC 
2016 list and would like to apply for it.
Last year I tried GSOC with libredwg project but it was unsuccesfull 
for me, but you can see my work there on the mailing list 
http://lists.gnu.org/archive/html/libredwg/ 
(http://lists.gnu.org/archive/html/libredwg/2015-04/msg1.html) and 
patches I have done at http://savannah.gnu.org/patch/?group=libredwg 
(patch from #8626 to #8635).


I will clone GDAL and do initial compile, test and overview tickets 
you propose student should try over this weekend and will report back. 
My development OS is Linux (Ubuntu 14.04), but I have also access to 
Windows OS (Windows 7).


Your feedback is kindly appreciated.
Thanks, bye

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


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

Re: [gdal-dev] GSoC 2016

[Dmitry Baryshnikov]

Hi Jürgen,

There is several problems with libdxfrw:
1. The library have GPLv2 license which is incompatible with GDAL X/MIT
2. The library support only DWG from r14 to the last 2003 version
3. This is third party dependency for GDAL.
4. There is already the DXF driver in GDAL.

The GPLv2 is ok for QGIS, but it'll be nice to not duplicate efforts.
The GDAL is used widely in many projects and a DWG driver from GDAL will 
be available there (including QGIS).
During GSoC we plan to create not 100% featured driver (this is 
impossible for such small period), but something close to GDAL DXF driver.


No idea what is best to do now.

Best regards,
Dmitry

16.03.2016 17:07, Jürgen E. Fischer пишет:

Hi Alexander,

On Wed, 16. Mar 2016 at 12:40:39 +, Борзых Александр Андреевич wrote:

Overall idea
DWG  is very wide-spread format and it seems like there is a lot of requests
for a good conversion tools from DWG to more common spatial data. I  think
that current implementations of DWG support are not optimal. For  example
libdwg (abandoned), libredwg (GPLv3 incompatible with X/MIT).
There are near 7 versions of DWG format (R13, R14, R2000, R2004, R2007,
R2010, R2013) with differencies in file organisation, so driver should be
able to read from and write to all of them.

There's also libdxfrw that supports these.  It's what we will use to do a
DWG/DXF import in QGIS.



Jürgen



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


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

Re: [gdal-dev] Building GDAL 2.0.0 without ogr on Linux fails

[Dmitry Baryshnikov]

Hi Kurt,

I think, that it's time to do this.

Best regards,
Dmitry

17.03.2016 19:19, Kurt Schwehr пишет:
I propose that we remove --without-ogr and OGR_ENABLED.  Happy to hear 
arguments for the contrary.  I commented here:


https://trac.osgeo.org/gdal/ticket/6117

On Tue, Jun 23, 2015 at 9:14 AM, Even Rouault 
> wrote:


Kor,

I'm half surprised this ended up being broken. At the time of
https://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification, it
still worked
apparently but I might have accidentaly broken it later.

Anyway I was wondering if it was worth fixing that? as it might be
a continuing
maintenance pain... This was something I actually considered
during RFC 46 (I
mean dropping support for --without-ogr).

Even

> Dear all,
>
> I may have found an issue in the build scripts of gdal 2.0.0.
Building
> gdal without ogr on Linux fails on my machine:
>
> ./configure --without-ogr
> make -j8
>
> I attached the output of configure and copied the snippets from the
> build output detailing the errors below.
>
> When I change --without-ogr into --with-ogr, the build succeeds.
>
> Maybe something OGR-ish is building while it shouldn't(?).
>
> Best regards,
> Kor de Jong
>
>
>
>
> libtool: compile:  /opt/gcc-4.9/bin/g++ -I/tmp/blah/gdal-2.0.0/port
> -I/tmp/blah/gdal-2.0.0/gcore -I/tmp/blah/gdal-2.0.0/alg
> -I/tmp/blah/gdal-2.0.0/ogr
-I/tmp/blah/gdal-2.0.0/ogr/ogrsf_frmts -g -O2
> -Wall -I/tmp/blah/gdal-2.0.0/port -I/usr/include
-DGDAL_COMPILATION -c
> mffdataset.cpp -o ../o/mffdataset.o >/dev/null 2>&1
> ogrutils.cpp: In function ‘int OGRGeneralCmdLineProcessor(int,
char***,
> int)’:
> ogrutils.cpp:526:60: error: ‘GDAL_OF_VECTOR’ was not declared in
this scope
>   return GDALGeneralCmdLineProcessor( nArgc, ppapszArgv,
> GDAL_OF_VECTOR );
>   ^
> ogrutils.cpp:526:75: error: ‘GDALGeneralCmdLineProcessor’ was not
> declared in this scope
>   return GDALGeneralCmdLineProcessor( nArgc, ppapszArgv,
> GDAL_OF_VECTOR );
>
>  ^
> ogrutils.cpp:527:1: warning: control reaches end of non-void
function
> [-Wreturn-type]
>   }
>   ^
> make[1]: *** [ogrutils.lo] Error 1
> make[1]: *** Waiting for unfinished jobs
>
>
>
>
>
> pdfwritabledataset.cpp: In member function ‘virtual OGRErr
> PDFWritableVectorDataset::SyncToDisk()’:
> pdfwritabledataset.cpp:307:17: error: ‘class GDALPDFWriter’ has no
> member named ‘WriteOGRLayer’
>   oWriter.WriteOGRLayer((OGRDataSourceH)this,
>   ^
> make[2]: *** [../o/pdfwritabledataset.lo] Error 1
> make[2]: *** Waiting for unfinished jobs
>
>
>
> make[1]: *** [pdf-install-obj] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [frmts-target] Error 2

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




--
--
http://schwehr.org


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


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

Re: [gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hi Sarthak,

The first version is not working (do you test it?): 
https://github.com/sarthak-0415/gdal/commit/36344cc26f23202cb289390322c1d295697136bd#diff-31df0e62d00ca09f9f11ad2f29e94b54R2541
Here you try to get array value with index -1. You need to set 
ppszDbname = NULL no DB name present in input parameters.


The second variant is not working too:
>>> ds = gdal.Open('PG:')
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

In both cases there is a problem here: 
https://github.com/sarthak-0415/gdal/blob/6264d3fc52242fdce858547cc3a0312b04fd638b/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2743


Also look there ppszDbname is using, as before modifications the code 
expect that ppszDbname cannot be NULL.


Best regards,
Dmitry

15.03.2016 13:13, sarthak agarwal пишет:


Hey Dmitry ,
As discussed on the IRC yesterday,
I made the changes in the code.

I build two versions of the code

1.

The changes suggested by you (to use the old trunk code and remove
the additional checks) link


travis  .
a. in this version the Dbname is left empty if not provided by the
user.

2.

The version in which we
a. if the Dbname is provided by the user then ppzDbname=Dbname.
b. else use the psql env var PGDATABASE
c. else use the Username as the database name.
d. if nothing is available then pass empty string.
e link


travis 

I think both version should work

Regards,
Sarthak

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

Re: [gdal-dev] Google Summer of Code

[Dmitry Baryshnikov]

Hi Tanuj,

The error: ImportError: No module named osgeo
is because you build gdal without python support (you need python with 
developers headers).

On Linux Linux this is done via such command:
./configure --with-python ... 

On Windows it depends how you build. On Windows I launch separate tests 
successfully but never try the whole tests (run_all.py).


Best regards,
Dmitry

14.03.2016 19:11, Tanuj Kumar пишет:

Hello Dmitry,
I was reading up on the gdalautotest 
wiki(http://trac.osgeo.org/gdal/wiki/TestingNotes), and it says, 
"After building with either the old or new generation python bindings, 
and installing them (or adding them to your path from the build tree)..."


I could not understand what that means. I guess this is important 
because when I tried the commands given on that page, I got the 
following error :


File "./run_all.py", line 37, in 
import gdaltest
File"pymod/gdaltest.py", line 37, in 
from osgeo import gdal
ImportError: No module named osgeo


Now, as far as I could understand, it is importing a file called 
"gdal.py" from a folder called osgeo. I searched for it, and got its 
path as "gdal/swig/python/osgeo, whereas the autotest folder is separate.

So my guess is I have to somehow specify the path of "gdal.py"

Could you or anyone please guide me on how to proceed with this?

Thanks
Tanuj

On Sat, Mar 12, 2016 at 11:00 PM, Tanuj Kumar <kmrtnjs...@gmail.com 
<mailto:kmrtnjs...@gmail.com>> wrote:


Alright, thank you very much, I'll get to work on it!

On Sat, Mar 12, 2016 at 10:47 PM, Dmitry Baryshnikov
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:

Hi Tanuj,

I wrote a big letter to the list. There is some answers there.
Also I add comments below.

Best regards,
 Dmitry

12.03.2016 10:36, Tanuj Kumar пишет:

Sorry for replying so late, got caught up in an exam :)

I replaced libpng folder of gdal (frmts/png/libpng) with
libpng 1.6.21. And then used ./configure and make install on
this test version of gdal, which installed successfully. I
used gdalinfo on a png file provided with the libpng 1.6.21
source, to check if it was OK, and it successfully gave the
png file details.

Is that enough to check the build on the computer?

No, the autotests must be passed.


I have also tested the gdal library with libpng 1.6.21 on
Travis, and the build succeeded.
https://travis-ci.org/Raeburn1687/gdal/builds/115487530

Would all that be enough to check whether the update was
succesful?

I expected that travis from main gdal repo checked your PR.


PS - Although I have copied the files from libpng 1.6.21
source to the gdal libpng folder, how would I know if any of
those files are not required for gdal?


You need to see the previous version. Some files not needed
(i.e. configures and so on, which already comes from gdal, but
legal notice must be present (license, autors, etc.) ). Don't
hesitate to ask in list.



    Thank you

Tanuj

On Thu, Mar 10, 2016 at 2:07 PM, Dmitry Baryshnikov
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:

Hi Tanuj,
09.03.2016 13:17, Tanuj Kumar пишет:

Yes, I have looked at the ideas list, and I am currently
reading up on idea no. 16, which is, implementing
support for the proposed standard for incrementally
parseable GeoJSON data.

Also, I was thinking that maybe I could work on ticket
no 6294, https://trac.osgeo.org/gdal/ticket/6294
after I've studied about the GSoC idea, which is not
really a bug, but an enhancement. But if there are any
other tickets that you or anyone else would like to
recommend me to work on, I'd love to see them too!

I think this rather arguing ticket as the bool is not
exist in plain C, and duplication functions seems to me
not good idea.
I think this ticket
https://trac.osgeo.org/gdal/ticket/6185 is good for: 1.
building GDAL, 2. Testing via TraviC on GitHub. By the
way the libpng version is 1.6.21 or maybe higher.

Anyhow, you have to try to build gdal and test it with
autotests from appropriate folder.


Now, about the GSoC idea, do I need to know JSON( or
GeoJSON, for that matter) to work on it? I only ask
because the idea lists C/C++ as the required skills, but
I feel that maybe this work would involve knowing JSON
too...

Yes, certainly. But JSON are very simple. Also GeoJSON
spec. can be found here http://geojson

Re: [gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hi Sarthak,

14.03.2016 00:36, sarthak agarwal пишет:


On Sun, Mar 13, 2016 at 11:07 PM, Even Rouault 
<even.roua...@spatialys.com <mailto:even.roua...@spatialys.com>> wrote:


On Sunday 13 March 2016 17:13:27 Dmitry Baryshnikov wrote:
> Hi Sarthak,
>
> 1. The GDAL have 2 postgis drivers (raster and vector).

RIght now I am working on raster part, I still have to figure out 
which part of the code takes care of |vector| postgis driver.



Look at https://github.com/OSGeo/gdal/tree/trunk/gdal/ogr/ogrsf_frmts/pg


> 2. You need to add some information to the doxygen comment of

> GetConnectionInfo method about new functionality.

I made changes in the comments, I guess doxygen reads comments in 
between the lines of the code. If still I have to make some changes, 
please tell me.


I figure out that doxygen not parse this file (it seems to me because it 
is not public). But, I didn't see explain of PGUSER, PGDATABASEetc. Also 
it'll be more useful to extend brief in comment before function name 
(https://github.com/sarthak-0415/gdal/blob/1e7970bf38bc06c837ab76d4a185b59089df07f0/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2463-L2483) 
as it done, for example, for mode parameter.



> 3. Do you look at psql behaviour? It seems to me the ticket
author means
> to get the database name not only from environment variable, but
also
> from the current logged user name.

We should be as tolerant as the OGR PG driver is. ie not
constraint the user
to specify more than what PQconnectdb() requires  (ie it can be
potentially
empty)

I have made the changes to make |DBname| to |NULL| if we do not have 
any database name or username.


This is not expected behaviour. As Even wrote if no username nor dbname 
provided, the function should get user login and this will be username 
and DB name. Do you look at psql sources (this may be rather complex, 
and I'm ready to discuss the scope of this work)?



> 4. There is a logic error: You form connection string based on
> parameters (papszParams) here -
>
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/pos
> tgisrasterdataset.cpp#L2502 , but change the
> papszParams below (i.e.
>
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/pos
> tgisrasterdataset.cpp#L2605). Also changed papszParams never
used and only
> freed here -
>
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/pos
> tgisrasterdataset.cpp#L2735.
>

I fixed that logical error, and Now it reads the |username| twice 
(once to init the |dbname| and second for the |connection|)
you can find those changes here 
<https://github.com/OSGeo/gdal/compare/trunk...sarthak-0415:trunk#diff-31df0e62d00ca09f9f11ad2f29e94b540> 
and travis 
<https://travis-ci.org/sarthak-0415/gdal/builds/115730596> for the builds.


Yes, I see. What about your preferable idea for GSoC? What you ideas 
about it developing?

By the way, today the  Student Application Period started.


Regards,

Sarthak

>
> Best regards,
>  Dmitry
>
> 13.03.2016 00:10, sarthak agarwal пишет:
> > Thank you for your reply Dmitry,
> >
> > Yesterday I was working on ticket 6294
> > <https://trac.osgeo.org/gdal/ticket/6294> but since you said
it was
> > controversial I started to look around at ticket 6316
> > <https://trac.osgeo.org/gdal/ticket/6316>,
> >
> > I figured out that we have to add a |else| statement after
this code
> >
<https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/
> > postgisrasterdataset.cpp> to give a default value to the
|ppszDbname| in
> > case user dosen’t
> > provide any database name by default.
> >
> > And I suggest this small enhancement
> >
<https://github.com/OSGeo/gdal/commit/e7b2e9e9cd946d257cae5dfd196b4786cc2c
> > 0e94> to the code.
> > Although I am not sure of this line
> >
<https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/
> > postgisrasterdataset.cpp#L2642> where I want to copy the
|userName| into
> > |dbName|.
> >
> > This is a small fix and I wanted to discuss further on it.
> >
> > I have succesfully build the code on travis
> > <https://travis-ci.org/sarthak-0415/gdal/builds/115574203>, please
> > check it once.
> >
> > I have some doubts regarding some variables and functions for
which I
> > am still reading the code.
> > I will get back to you if I have some more doubts.
> >
> >

Re: [gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hi Sarthak,

1. The GDAL have 2 postgis drivers (raster and vector).
2. You need to add some information to the doxygen comment of 
GetConnectionInfo method about new functionality.
3. Do you look at psql behaviour? It seems to me the ticket author means 
to get the database name not only from environment variable, but also 
from the current logged user name.
4. There is a logic error: You form connection string based on 
parameters (papszParams) here - 
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2502 
, but change the
papszParams below (i.e. 
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2605). 
Also changed papszParams never used and only freed here - 
https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2735. 



Best regards,
Dmitry

13.03.2016 00:10, sarthak agarwal пишет:


Thank you for your reply Dmitry,

Yesterday I was working on ticket 6294 
<https://trac.osgeo.org/gdal/ticket/6294> but since you said it was 
controversial I started to look around at ticket 6316 
<https://trac.osgeo.org/gdal/ticket/6316>,


I figured out that we have to add a |else| statement after this code 
<https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp> 
to give a default value to the |ppszDbname| in case user dosen’t 
provide any database name by default.


And I suggest this small enhancement 
<https://github.com/OSGeo/gdal/commit/e7b2e9e9cd946d257cae5dfd196b4786cc2c0e94> 
to the code.
Although I am not sure of this line 
<https://github.com/sarthak-0415/gdal/blob/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L2642> 
where I want to copy the |userName| into |dbName|.


This is a small fix and I wanted to discuss further on it.

I have succesfully build the code on travis 
<https://travis-ci.org/sarthak-0415/gdal/builds/115574203>, please 
check it once.


I have some doubts regarding some variables and functions for which I 
am still reading the code.

I will get back to you if I have some more doubts.

Regards,
Sarthak

On Sat, Mar 12, 2016 at 10:42 PM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


Hello GSoC students!

Many of you wrote to different lists and directly for me. I tried
to systematize your questions.

1. First of all each student need to subscribe to
s...@lists.osgeo.org <mailto:s...@lists.osgeo.org> (the themes
connected with organizing moments) and gdal-dev@lists.osgeo.org
<mailto:gdal-dev@lists.osgeo.org> (the themes about ideas,
tickets, coding and community). Please don't flood both lists the
same letters.

2. Next - I dig the GDAL tracker and found some tickets worth to
be fixed. This work help you to understand the project structure
and how it works (building, testing and so on) and help project to
became better.
The expected result is applied pool request in GDAL main
repository at github (https://github.com/OSGeo/gdal).
By the way, after pool request to this repository, the provided
fixes are tested via TravisC and over test utilities.
Before making pool request please test it yourself (ubuntu and
windows is enough, virtualbox or preferable virtualization soft
may help here).
Here is the tickets I think is good for you (it's welcome if
community fix this list - maybe some tickets need to be excluded
or some included):

- https://trac.osgeo.org/gdal/ticket/2773
- https://trac.osgeo.org/gdal/ticket/5035 - Alex
- https://trac.osgeo.org/gdal/ticket/5347
- https://trac.osgeo.org/gdal/ticket/5592
- https://trac.osgeo.org/gdal/ticket/5681
- https://trac.osgeo.org/gdal/ticket/5705
- https://trac.osgeo.org/gdal/ticket/6185 - Tanuj
- https://trac.osgeo.org/gdal/ticket/6222
- https://trac.osgeo.org/gdal/ticket/6246
- https://trac.osgeo.org/gdal/ticket/6304
- https://trac.osgeo.org/gdal/ticket/6316
- https://trac.osgeo.org/gdal/ticket/6385

I checked tickets already get by students. It's good to discuss
with community how you plan to fix the tickets before start
coding. Also, choose tickets carefully, we need students with good
skills, so the ticket should show your potential. Some of you
already choose another tickets, and this is normal too, but they
need to be discussed too. For example the ticket
https://trac.osgeo.org/gdal/ticket/6294 is rather controversial.

3. We need to see which ideas each of student choose, and what is
a plan how to release them. You need some discussion with the
community what is best way or some directions to do it. This is
not spoil of the time as your ideas come as background for your
project announces.

It'll be nice have more details for some ideas from list
htt

Re: [gdal-dev] Google Summer of Code

[Dmitry Baryshnikov]

Hi Tanuj,

I wrote a big letter to the list. There is some answers there. Also I 
add comments below.


Best regards,
Dmitry

12.03.2016 10:36, Tanuj Kumar пишет:

Sorry for replying so late, got caught up in an exam :)

I replaced libpng folder of gdal (frmts/png/libpng) with libpng 
1.6.21. And then used ./configure and make install on this test 
version of gdal, which installed successfully. I used gdalinfo on a 
png file provided with the libpng 1.6.21 source, to check if it was 
OK, and it successfully gave the png file details.


Is that enough to check the build on the computer?

No, the autotests must be passed.


I have also tested the gdal library with libpng 1.6.21 on Travis, and 
the build succeeded.

https://travis-ci.org/Raeburn1687/gdal/builds/115487530

Would all that be enough to check whether the update was succesful?

I expected that travis from main gdal repo checked your PR.


PS - Although I have copied the files from libpng 1.6.21 source to the 
gdal libpng folder, how would I know if any of those files are not 
required for gdal?


You need to see the previous version. Some files not needed (i.e. 
configures and so on, which already comes from gdal, but legal notice 
must be present (license, autors, etc.) ). Don't hesitate to ask in list.



Thank you

Tanuj

On Thu, Mar 10, 2016 at 2:07 PM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


Hi Tanuj,
09.03.2016 13:17, Tanuj Kumar пишет:

Yes, I have looked at the ideas list, and I am currently reading
up on idea no. 16, which is, implementing support for the
proposed standard for incrementally parseable GeoJSON data.

Also, I was thinking that maybe I could work on ticket no 6294,
https://trac.osgeo.org/gdal/ticket/6294
after I've studied about the GSoC idea, which is not really a
bug, but an enhancement. But if there are any other tickets that
you or anyone else would like to recommend me to work on, I'd
love to see them too!

I think this rather arguing ticket as the bool is not exist in
plain C, and duplication functions seems to me not good idea.
I think this ticket https://trac.osgeo.org/gdal/ticket/6185 is
good for: 1. building GDAL, 2. Testing via TraviC on GitHub. By
the way the libpng version is 1.6.21 or maybe higher.

Anyhow, you have to try to build gdal and test it with autotests
from appropriate folder.


Now, about the GSoC idea, do I need to know JSON( or GeoJSON, for
that matter) to work on it? I only ask because the idea lists
C/C++ as the required skills, but I feel that maybe this work
would involve knowing JSON too...

Yes, certainly. But JSON are very simple. Also GeoJSON spec. can
be found here http://geojson.org/Thanks and regards,



Tanuj


On Wed, Mar 9, 2016 at 2:58 PM, Dmitry Baryshnikov
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:

Hi, Tanuj

I'll look for opened tickets for you, or maybe others can
recommend some for you.

By the way, do you see the idea list
(https://trac.osgeo.org/gdal/wiki/SummerOfCode#a2016IdeasList)?
The ideas are not ranked yet - the numbers in the list - are
only in order.
This is a task for us to rank the ideas.
But, have you some preferable idea (or ideas) for GSoC from
this list or maybe you have got own?

Best regards,
 Dmitry

04.03.2016 16:11, Tanuj Kumar пишет:

Hello,
I am interested in applying for GSoC this year. Currently, I
am reading up on the GDAL Summer of Code ideas list. I know
C++ and C, and I have some experience on working on linux.
Could the mentors please recommend a bug for me to work on,
I'd really love to start off as soon as possible!

Thank you,

Tanuj Kumar
Birla institute of Technology and Science
Pilani, Rajasthan,
India


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



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




Best regards,
 Dmitry




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

[gdal-dev] GSOC 2016

[Dmitry Baryshnikov]

Hello GSoC students!

Many of you wrote to different lists and directly for me. I tried to 
systematize your questions.


1. First of all each student need to subscribe to s...@lists.osgeo.org 
(the themes connected with organizing moments) and 
gdal-dev@lists.osgeo.org (the themes about ideas, tickets, coding and 
community). Please don't flood both lists the same letters.


2. Next - I dig the GDAL tracker and found some tickets worth to be 
fixed. This work help you to understand the project structure and how it 
works (building, testing and so on) and help project to became better.
The expected result is applied pool request in GDAL main repository at 
github (https://github.com/OSGeo/gdal).
By the way, after pool request to this repository, the provided fixes 
are tested via TravisC and over test utilities.
Before making pool request please test it yourself (ubuntu and windows 
is enough, virtualbox or preferable virtualization soft may help here).
Here is the tickets I think is good for you (it's welcome if community 
fix this list - maybe some tickets need to be excluded or some included):


- https://trac.osgeo.org/gdal/ticket/2773
- https://trac.osgeo.org/gdal/ticket/5035 - Alex
- https://trac.osgeo.org/gdal/ticket/5347
- https://trac.osgeo.org/gdal/ticket/5592
- https://trac.osgeo.org/gdal/ticket/5681
- https://trac.osgeo.org/gdal/ticket/5705
- https://trac.osgeo.org/gdal/ticket/6185 - Tanuj
- https://trac.osgeo.org/gdal/ticket/6222
- https://trac.osgeo.org/gdal/ticket/6246
- https://trac.osgeo.org/gdal/ticket/6304
- https://trac.osgeo.org/gdal/ticket/6316
- https://trac.osgeo.org/gdal/ticket/6385

I checked tickets already get by students. It's good to discuss with 
community how you plan to fix the tickets before start coding. Also, 
choose tickets carefully, we need students with good skills, so the 
ticket should show your potential. Some of you already choose another 
tickets, and this is normal too, but they need to be discussed too. For 
example the ticket https://trac.osgeo.org/gdal/ticket/6294 is rather 
controversial.


3. We need to see which ideas each of student choose, and what is a plan 
how to release them. You need some discussion with the community what is 
best way or some directions to do it. This is not spoil of the time as 
your ideas come as background for your project announces.


It'll be nice have more details for some ideas from list 
https://trac.osgeo.org/gdal/wiki/SummerOfCode. The ideas #7,8,9 are very 
briefly.


--
Best regards,
Dmitry

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

Re: [gdal-dev] Google Summer of Code

[Dmitry Baryshnikov]

Hi Tanuj,
09.03.2016 13:17, Tanuj Kumar пишет:
Yes, I have looked at the ideas list, and I am currently reading up on 
idea no. 16, which is, implementing support for the proposed standard 
for incrementally parseable GeoJSON data.


Also, I was thinking that maybe I could work on ticket no 6294, 
https://trac.osgeo.org/gdal/ticket/6294
after I've studied about the GSoC idea, which is not really a bug, but 
an enhancement. But if there are any other tickets that you or anyone 
else would like to recommend me to work on, I'd love to see them too!
I think this rather arguing ticket as the bool is not exist in plain C, 
and duplication functions seems to me not good idea.
I think this ticket https://trac.osgeo.org/gdal/ticket/6185 is good for: 
1. building GDAL, 2. Testing via TraviC on GitHub. By the way the libpng 
version is 1.6.21 or maybe higher.


Anyhow, you have to try to build gdal and test it with autotests from 
appropriate folder.


Now, about the GSoC idea, do I need to know JSON( or GeoJSON, for that 
matter) to work on it? I only ask because the idea lists C/C++ as the 
required skills, but I feel that maybe this work would involve knowing 
JSON too...
Yes, certainly. But JSON are very simple. Also GeoJSON spec. can be 
found here http://geojson.org/Thanks and regards,


Tanuj


On Wed, Mar 9, 2016 at 2:58 PM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


Hi, Tanuj

I'll look for opened tickets for you, or maybe others can
recommend some for you.

By the way, do you see the idea list
(https://trac.osgeo.org/gdal/wiki/SummerOfCode#a2016IdeasList)?
The ideas are not ranked yet - the numbers in the list - are only
in order.
This is a task for us to rank the ideas.
But, have you some preferable idea (or ideas) for GSoC from this
list or maybe you have got own?

Best regards,
 Dmitry

04.03.2016 16:11, Tanuj Kumar пишет:

Hello,
I am interested in applying for GSoC this year. Currently, I am
reading up on the GDAL Summer of Code ideas list. I know C++ and
C, and I have some experience on working on linux.
Could the mentors please recommend a bug for me to work on, I'd
really love to start off as soon as possible!

Thank you,

Tanuj Kumar
Birla institute of Technology and Science
Pilani, Rajasthan,
India


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



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




Best regards,
Dmitry

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

Re: [gdal-dev] Google Summer of Code

[Dmitry Baryshnikov]

Hi, Tanuj

I'll look for opened tickets for you, or maybe others can recommend some 
for you.


By the way, do you see the idea list 
(https://trac.osgeo.org/gdal/wiki/SummerOfCode#a2016IdeasList)?

The ideas are not ranked yet - the numbers in the list - are only in order.
This is a task for us to rank the ideas.
But, have you some preferable idea (or ideas) for GSoC from this list or 
maybe you have got own?


Best regards,
Dmitry

04.03.2016 16:11, Tanuj Kumar пишет:

Hello,
I am interested in applying for GSoC this year. Currently, I am 
reading up on the GDAL Summer of Code ideas list. I know C++ and C, 
and I have some experience on working on linux.
Could the mentors please recommend a bug for me to work on, I'd really 
love to start off as soon as possible!


Thank you,

Tanuj Kumar
Birla institute of Technology and Science
Pilani, Rajasthan,
India


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


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

Re: [gdal-dev] map info and projections from GeoTIFF file to create ENVI header

[Dmitry Baryshnikov]

Hi Nevzat,

you need to get spatial reference from GDALDataset (via GetProjectionRef 
http://gdal.org/classGDALDataset.html#aa42537e1062ce254d124b29ff3ebe857) 
and convert it to OGRSpatialReference.


Than use exportToMICoordSys to get MI CRS string.

http://gdal.org/classOGRSpatialReference.html#a1f2908cd5ca33609844ef0c0ff2186ea

Best regards,
Dmitry

18.01.2016 20:27, ngu...@jlab.org пишет:

It is solved. Thank you very much Even and Dmitry for your helps. I have
missed the GDAL_DATA variable and it caused me all that trouble.

Now I need to get the map info string:
map info = {UTM, 1, 1, 145185, 2189715, 30, 30, 19, North,WGS-84}

Using hDS->GetGeoTransform(adfGeoTransform) does not give me all the
information in the map info string. It only gives me elements [4-7], how to
get the others?

Best regards, - Nevzat


Yes, Thank you Even, I was missing the GDAL_DATA environmental variable. Now I
get the same gdalinfo output. Do I need to set this variable while using the
C++ classes you suggested before: GetGeoTransform and GetProjectionRef()..?
Because, there also I had the same problem.

Best regards, - Nevzat



Le lundi 18 janvier 2016 17:13:14, ngu...@jlab.org a écrit :

Dmitry and All,
I just downloaded the set of tiff files from earthexplorer and run gdalinfo
on it. Please see below. I am missing some fields in the output
information. It is different from what you got. I don't know what can
cause this? My gdalinfo.exe is not good? Any idea?

Have a look at the FAQ entries about GDAL_DATA :
https://trac.osgeo.org/gdal/wiki/FAQInstallationAndBuilding#WhatisGDAL_DATAenvironmentvariable


C:\Cubes\LC80080472013174LGN00.tar>gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF
.\LC80080472013174LGN00_MTL.txt
Size is 7571, 7411
Coordinate System is:
PROJCS["unnamed",
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",-69],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]]]
Origin = (145185.000,2189715.000)
Pixel Size = (30.000,-30.000)
Metadata:
   AREA_OR_POINT=Point
   METADATATYPE=ODL
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  145185.000, 2189715.000)
Lower Left  (  145185.000, 1967385.000)
Upper Right (  372315.000, 2189715.000)
Lower Right (  372315.000, 1967385.000)
Center  (  258750.000, 2078550.000)
Band 1 Block=7571x1 Type=UInt16, ColorInterp=Gray

C:\Cubes\LC80080472013174LGN00.tar>gdalinfo --version
GDAL 2.0.1, released 2015/09/15

C:\Cubes\LC80080472013174LGN00.tar>


I have the 2.0.1 version:
C:\warmerda\bld\bin>gdalinfo --version
GDAL 2.0.1, released 2015/09/15

I will check the history of the file I have. Maybe it is modified. I will
also download the same file from earthexplorer and try my routines on
it. Thanks for the suggestions. I appreciate.
- Nevzat

-Original Message-
From: Dmitry Baryshnikov [mailto:bishop@gmail.com]
Sent: Sunday, January 17, 2016 12:57 PM
To: Nevzat Guler <ngu...@jlab.org>; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] map info and projections from GeoTIFF file to
create ENVI header

I downloaded this scene from earthexplorer, and everything is fine:

$ gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF

 ./LC80080472013174LGN00_MTL.txt

Size is 7571, 7411
Coordinate System is:
PROJCS["WGS 84 / UTM zone 19N",

  GEOGCS["WGS 84",

  DATUM["WGS_1984",

  SPHEROID["WGS 84",6378137,298.257223563,

  AUTHORITY["EPSG","7030"]],

  AUTHORITY["EPSG","6326"]],

  PRIMEM["Greenwich",0,

  AUTHORITY["EPSG","8901"]],

  UNIT["degree",0.0174532925199433,

  AUTHORITY["EPSG","9122"]],

  AUTHORITY["EPSG","4326"]],

  PROJECTION["Transverse_Mercator"],
  PARAMETER["latitude_of_origin",0],
  PARAMETER["central_meridian",-69],
  PARAMETER["scale_factor",0.9996],
  PARAMETER["false_easting",50],
  PARAMETER["false_northing",0],
  UNIT["metre",1,

  AUTHORITY["EPSG","9001"]],

  AXIS["Easting",EAST],
  AXIS["Northing",NORTH],
  AUTHORITY["EPSG","32619"]]

Origin = (145185.000,2189715.000)
Pixel Size = (30.000,-30.000)

Metadata:
AREA_OR_POINT=Point
METADATATYPE=ODL

Image Structure Met

Re: [gdal-dev] map info and projections from GeoTIFF file to create ENVI header

[Dmitry Baryshnikov]

Oh, I'm confused MapInfo and ENVI map info.

In your case you need to form this string by yourself using values from 
OGRSpatialReference methods.
Also take a look to 
https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/raw/envidataset.cpp


Best regards,
Dmitry

19.01.2016 00:33, ngu...@jlab.org пишет:

Dmitry,

After doing this, I following your suggested steps, I get the string:

Earth Projection 8, 104, "m", -69, 0, 0.9996, 50, 0

Bit, the map info string I need to use looks like this:

map info = {UTM, 1, 1, 145185, 2189715, 30, 30, 19, North}

I tried other ExportTo functions but none gives me the specific map info
string I want. This is ENVI map info string.

I guess I will just have to stitch it together once I understand what the
second and third elements are used for..

I really appreciated your help.
Best regards, - Nevzat



Hi Nevzat,

you need to get spatial reference from GDALDataset (via GetProjectionRef
http://gdal.org/classGDALDataset.html#aa42537e1062ce254d124b29ff3ebe857)
and convert it to OGRSpatialReference.

Than use exportToMICoordSys to get MI CRS string.

http://gdal.org/classOGRSpatialReference.html#a1f2908cd5ca33609844ef0c0ff2186ea

Best regards,
  Dmitry

18.01.2016 20:27, ngu...@jlab.org пишет:

It is solved. Thank you very much Even and Dmitry for your helps. I have
missed the GDAL_DATA variable and it caused me all that trouble.

Now I need to get the map info string:
map info = {UTM, 1, 1, 145185, 2189715, 30, 30, 19, North,WGS-84}

Using hDS->GetGeoTransform(adfGeoTransform) does not give me all the
information in the map info string. It only gives me elements [4-7], how to
get the others?

Best regards, - Nevzat


Yes, Thank you Even, I was missing the GDAL_DATA environmental variable.
Now I
get the same gdalinfo output. Do I need to set this variable while using
the
C++ classes you suggested before: GetGeoTransform and GetProjectionRef()..?
Because, there also I had the same problem.

Best regards, - Nevzat



Le lundi 18 janvier 2016 17:13:14, ngu...@jlab.org a écrit :

Dmitry and All,
I just downloaded the set of tiff files from earthexplorer and run
gdalinfo
on it. Please see below. I am missing some fields in the output
information. It is different from what you got. I don't know what can
cause this? My gdalinfo.exe is not good? Any idea?

Have a look at the FAQ entries about GDAL_DATA :
https://trac.osgeo.org/gdal/wiki/FAQInstallationAndBuilding#WhatisGDAL_DATAenvironmentvariable


C:\Cubes\LC80080472013174LGN00.tar>gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF
 .\LC80080472013174LGN00_MTL.txt
Size is 7571, 7411
Coordinate System is:
PROJCS["unnamed",
  PROJECTION["Transverse_Mercator"],
  PARAMETER["latitude_of_origin",0],
  PARAMETER["central_meridian",-69],
  PARAMETER["scale_factor",0.9996],
  PARAMETER["false_easting",50],
  PARAMETER["false_northing",0],
  UNIT["metre",1,
  AUTHORITY["EPSG","9001"]]]
Origin = (145185.000,2189715.000)
Pixel Size = (30.000,-30.000)
Metadata:
AREA_OR_POINT=Point
METADATATYPE=ODL
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  145185.000, 2189715.000)
Lower Left  (  145185.000, 1967385.000)
Upper Right (  372315.000, 2189715.000)
Lower Right (  372315.000, 1967385.000)
Center  (  258750.000, 2078550.000)
Band 1 Block=7571x1 Type=UInt16, ColorInterp=Gray

C:\Cubes\LC80080472013174LGN00.tar>gdalinfo --version
GDAL 2.0.1, released 2015/09/15

C:\Cubes\LC80080472013174LGN00.tar>


I have the 2.0.1 version:
C:\warmerda\bld\bin>gdalinfo --version
GDAL 2.0.1, released 2015/09/15

I will check the history of the file I have. Maybe it is modified. I
will
also download the same file from earthexplorer and try my routines on
it. Thanks for the suggestions. I appreciate.
- Nevzat

-Original Message-
From: Dmitry Baryshnikov [mailto:bishop@gmail.com]
Sent: Sunday, January 17, 2016 12:57 PM
To: Nevzat Guler <ngu...@jlab.org>; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] map info and projections from GeoTIFF file to
create ENVI header

I downloaded this scene from earthexplorer, and everything is fine:

$ gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF

  ./LC80080472013174LGN00_MTL.txt

Size is 7571, 7411
Coordinate System is:
PROJCS["WGS 84 / UTM zone 19N",

   GEOGCS["WGS 84",

   DATUM["WGS_1984",

   SPHEROID["WGS 84",6378137,298.257223563,

   AUTHORITY["EPSG","7030"]],

   AUTHORITY["EPSG","6326"]],

   PRIMEM["Greenwich",0,

   AUTHORITY["EPSG","89

Re: [gdal-dev] map info and projections from GeoTIFF file to create ENVI header

[Dmitry Baryshnikov]

I downloaded this scene from earthexplorer, and everything is fine:

$ gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF
   ./LC80080472013174LGN00_MTL.txt
Size is 7571, 7411
Coordinate System is:
PROJCS["WGS 84 / UTM zone 19N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-69],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32619"]]
Origin = (145185.000,2189715.000)
Pixel Size = (30.000,-30.000)
Metadata:
  AREA_OR_POINT=Point
  METADATATYPE=ODL
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  145185.000, 2189715.000) ( 72d23' 7.97"W, 19d46'16.43"N)
Lower Left  (  145185.000, 1967385.000) ( 72d20'44.51"W, 17d45'55.15"N)
Upper Right (  372315.000, 2189715.000) ( 70d13' 8.50"W, 19d47'56.92"N)
Lower Right (  372315.000, 1967385.000) ( 70d12'16.74"W, 17d47'24.74"N)
Center  (  258750.000, 2078550.000) ( 71d17'19.50"W, 18d47' 4.68"N)
Band 1 Block=7571x1 Type=UInt16, ColorInterp=Gray

$ gdalinfo --version
GDAL 2.1.0dev, released 2015/99/99

What is your gdal version? Maybe the Landsat geotiff was modified from 
some software?


Best regards,
Dmitry

17.01.2016 20:15, Nevzat Guler пишет:

Thank you Dmitry,
What is the best way to extract the information we got using gdalinfo.exe by 
using GDAL classes, within a C++ code? As I mentioned, I am using 
GetGeoTransform and GetProjectionRef() but the results miss many of the 
information (specifically the map info elements as I explained in the previous 
email).

On another note, I actually get a different output from gdalinfo.exe using my 
file (please see the printed result below). I got the geotiff file from my 
colleague. When I open the file with ENVI, I get all the information, including 
GEOGCS information.

Can it be that my file is just corrupted and that's why I don't get all the 
information from GetGeoTransform and GetProjectionRef()? But then how would 
ENVI is able to extract this information if it were not in the file?

Thanks again, - Nevzat

C:\Cubes\Landsat\LC80080472013174LGN00>gdalinfo LC80080472013174LGN00_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80080472013174LGN00_B1.TIF
.\LC80080472013174LGN00_MTL.txt
Size is 7571, 7411
Coordinate System is:
PROJCS["unnamed",
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",-69],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",50],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]]]
Origin = (145185.000,2189715.000)
Pixel Size = (30.000,-30.000)
Metadata:
   AREA_OR_POINT=Point
   METADATATYPE=ODL
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  145185.000, 2189715.000)
Lower Left  (  145185.000, 1967385.000)
Upper Right (  372315.000, 2189715.000)
Lower Right (  372315.000, 1967385.000)
Center  (  258750.000, 2078550.000)
Band 1 Block=7571x1 Type=UInt16, ColorInterp=Gray

-Original Message-
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Dmitry 
Baryshnikov
Sent: Sunday, January 17, 2016 6:57 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] map info and projections from GeoTIFF file to create 
ENVI header

Hi Nevzat,

The landsat geotiff already have CRS embeded in file

$ gdalinfo LC80150362013097LGN03_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80150362013097LGN03_B1.TIF
 ./LC80150362013097LGN03_MTL.txt
Size is 7281, 7261
Coordinate System is:
PROJCS["WGS 84 / UTM zone 17N",
  GEOGCS["WGS 84",
  DATUM["WGS_1984",
  SPHEROID["WGS 84",6378137,298.257223563,
  AUTHORITY["EPSG","7030"]],
  AUTHORITY["EPSG","6326"]],
  PRIMEM["Gree

Re: [gdal-dev] map info and projections from GeoTIFF file to create ENVI header

[Dmitry Baryshnikov]

Hi Nevzat,

The landsat geotiff already have CRS embeded in file

$ gdalinfo LC80150362013097LGN03_B1.TIF
Driver: GTiff/GeoTIFF
Files: LC80150362013097LGN03_B1.TIF
   ./LC80150362013097LGN03_MTL.txt
Size is 7281, 7261
Coordinate System is:
PROJCS["WGS 84 / UTM zone 17N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-81],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","32617"]]
Origin = (706185.000,3943515.000)
Pixel Size = (30.000,-30.000)
Metadata:
  AREA_OR_POINT=Point
  METADATATYPE=ODL
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  706185.000, 3943515.000) ( 78d43'24.74"W, 35d36'50.15"N)
Lower Left  (  706185.000, 3725685.000) ( 78d46'35.65"W, 33d39' 3.82"N)
Upper Right (  924615.000, 3943515.000) ( 76d19' 2.05"W, 35d32'39.74"N)
Lower Right (  924615.000, 3725685.000) ( 76d25'33.46"W, 33d35'10.99"N)
Center  (  815400.000, 3834600.000) ( 77d33'38.95"W, 34d36'17.35"N)
Band 1 Block=7281x1 Type=UInt16, ColorInterp=Gray

And this is right CRS.
Where do you get you geotiff?

Best regards,
Dmitry

17.01.2016 03:41, Nevzat Guler пишет:

Dear experts,

I am reading LANDSAT GeoTIFF files and combining bands to create and ENVI
cube.
I am using GDAL to read the GeoTIFF file, and my own custom cube writer to
write the ENVI style cube. Transferring the map information proved to be a
bit convoluted. I seek your help to figure out this.

My first problem is to access map info from GeoTIFF file. The map info
includes:

map info = {UTM, 1.000, 1.000, 145185.000, 2189715.000, 3.00e+001,
3.00e+001, 19, North, WGS-84, units=Meters}

I am able to get the location (x,y), and pixel size (x,y) from :
double adfGeoTransform[6];
srcDS->GetGeoTransform(adfGeoTransform);

But, I could not find any way to get the other variables in the string: UTM,
pixel tie points, Unit and DATUM. Is there any way to get them?

Finally, for the Coordinate System String, GDAL gives me:

PROJCS["unnamed",PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_or
igin
",0],PARAMETER["central_meridian",-69],PARAMETER["scale_factor",0.9996],PARA
METE
R["false_easting",50],PARAMETER["false_northing",0],UNIT["Meter",1]]

But I should actually get

PROJCS["UTM_Zone_19N",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],A
UTHO
RITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["de
gree
",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]],PRO
JECT
ION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["cent
ral_
meridian",-69],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50

],PARAMETER["false_northing",0],UNIT["Meter",1]]

GDAL gives me PROJCS, "unnamed". And no GEOGCS information is given.  I am
able to get the coordinate system properties by using the following commands
but I first need to set few things to use exportToWTK.


   OGRSpatialReference oSRS;
   char *pszWKT = NULL;
   oSRS.SetProjCS("UTM_Zone_19N");
   oSRS.SetWellKnownGeogCS("WGS84");
   oSRS.SetUTM(19, TRUE);
   oSRS.SetWellKnownGeogCS("WGS84");
   oSRS.exportToWkt();
   printf("%s\n", pszWKT);

However, this requires me to set SetProjCS, SetWellKnownGeogCS and SetUTM
first. I don't know these before I read the file. Is there any way to get
them from the file so that I don't need prior knowledge to create the
header. When I pull the GeoTIFF file into ENVI, all these information is
already there. If this list is only or development purposes, please let me
know if there is any other email list that can give me guidance on this
quest.

I appreciate your help and suggestions.
Best regards,
- Nevzat

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


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

Re: [gdal-dev] RFC 48: Geographical networks support

[Dmitry Baryshnikov]

Hi Paul,

The RFS48 implemented, but only in trunk. The plan for release was on 
GDAL 2.1.


Yes, you can create shortest path between 2 points using a shapefile of 
roads, but the graph needed to be created. The autocreate method 
developed mostly for points (valves) and lines (tubes) so it may be 
unusable for you case in current implementation.

The details is here:
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_tut.dox
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_arch.dox
https://github.com/OSGeo/gdal/blob/trunk/gdal/apps/gnm_utilities.dox

Also, I would like to note, what GNMGenericNetowrk is not optimized now 
for big datasets (all graph stored in memory).


Best regards,
Dmitry

23.11.2015 10:50, Paul Meems пишет:

Hi List,

I'm looking at this RFC. Is it already implemented in GDAL v2?
And can we use it to create the shortest path between 2 points using a 
shapefile of roads (linestring)


Thanks,

Paul

*Paul Meems *
Release manager, configuration manager
and forum moderator of MapWindow GIS.
www.mapwindow.org 

Owner of MapWindow.nl - Support for
Dutch speaking users.
www.mapwindow.nl 

*
*

*We've started with the development of MapWindow v5. Read more. 


*



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


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

Re: [gdal-dev] GDAL 2015 annual report for November/December 2015 Newsletter

[Dmitry Baryshnikov]

Hi Even,

I added the sentence about FOSS4G 2015 code sprint in Seoul.

Best regards,
Dmitry

14.11.2015 20:46, Even Rouault пишет:

Hi,

See below Landon's invitation to provide content for the OSGeo Newsletter.
I've initiated a GDAL 2015 yearly report at
https://trac.osgeo.org/gdal/wiki/AnnualReport2015

Last one was in ... 2008 :-) I'd appreciate if people could contribute any
additional content (perhaps with some report of Seoul code sprint for
example), or at least checking and fixing spelling/grammar/style...

Even

--  Message transmis  --

Sujet : Re: [OSGeo-Discuss] November/December 2016 Newsletter
Date : samedi 14 novembre 2015, 17:35:10
De : Landon Blake 
À : OSGeo Discussions , OSGeo Journal


I haven't heard from any of our committees or chapters. I don't need
several pages of content...just a paragraph or two would be great. Please
let me know what your chapter or committee have been up to!

Thanks for your help.

Landon (sunburned.surve...@gmail.com)

On Wed, Nov 11, 2015 at 10:07 AM, Landon Blake 

Re: [gdal-dev] (no subject)

[Dmitry Baryshnikov]

Hi Konstantin,

Can you explain your case. For example for WMS driver (TMS) 
GDAL_HTTP_PROXY config option works for me.


Best regards,
Dmitry

01.10.2015 14:39, Константин Лапин пишет:


Hi,

CPLSetConfigOption( "GDAL_HTTP_PROXY",proxy.toLocal8Bit().data());
CPLSetConfigOption( "GDAL_PROXY_AUTH", "NTLM" );
CPLSetConfigOption( "GDAL_HTTP_PROXYUSERPWD", " : " );

how to make "bypass proxi for local adresses" ?


С уважением,
Константин Лапин
lk...@mail.ru


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


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

Re: [gdal-dev] Russian and Portugese doc pages out of date

[Dmitry Baryshnikov]

Hi,

I'll update Russian version. What about ticket which is about both 
languages - you'll close it then both languages be updated?


Best regards,
Dmitry

30.09.2015 12:02, Even Rouault пишет:

Hi,

http://gdal.org/index_ru.html and http://gdal.org/index_br.html are out of
date related to the English version. Anyone interested in updating them
(actually their master version in doc/br and doc/ru) ?

See https://trac.osgeo.org/gdal/ticket/5996

Even



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

Re: [gdal-dev] S57 SDK in .NET developer

[Dmitry Baryshnikov]

Hi, Thang,

What is the different between  S57 SDK for .NET and GDAL S57 driver with 
CSharp bindings?

There is the sources and API?

Best regards,
Dmitry

29.09.2015 05:36, Dao Thang пишет:


Hi everybody,

I'd like to announce i did the S57 SDK for .NET developer.

Anyone want this please contact me.

Thank you,
Thang.


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


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

[gdal-dev] Quick report code sprint Seoul 2015

[Dmitry Baryshnikov]

Hi everybody,
I'd like to share the results of code sprint in Seoul 2015.
The main aim was to restructure the gdal sources tree to fulfil the 
Cmake needs.
During the code sprint we test the git possibilities to move files 
between directories. But we decide to create a python script 
(https://github.com/nextgis-extra/lib_gdal/tree/master/etc/cmake-build-helpers) 
to do it, as it provide us more complex logic. Also there is a csv file 
with directory mapping.

Additionally the root cmakelists.txt was created.
I plan to build lightweight gdal (port and few drivers) with bindings.
At this point we can discuss if this working idea or not.
During the code sprint we clear all gdal repos and forks in our github 
account.

If anybody need old cmake4gdal branch - let me know.

Best regards,
Dmitry


___
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 Karl,

I think that some ready tests of GDAL are available. I'm not familiar 
with autotest2, so some links to docs and sources are welcome. Also I 
think that in gist you provided only some examples, and somewhere else 
the repo exists. If not - I'll try to play with this code.


Best regards,
Dmitry

15.09.2015 00:42, Kurt Schwehr пишет:

Hi Dmitry,

I didn't totally understand your question.  I don't have autotest2 
really out yet.  You are welcome to use the sample test files that I 
posted in any way that the Apache 2.0 license allows.


-kurt

On Sun, Sep 6, 2015 at 8:27 AM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


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
<https://gist.github.com/schwehr/13137d826763763fb031> (Yes, this
is massively boring code)
- autotest2/cpp/ogr/ogrpoint_test.cc
<https://gist.github.com/schwehr/c8ee86a6f6a1c1cc043b>
- autotest2/cpp/ogr/ogrsf_frmts/geojson/geojson_test.cc
<https://gist.github.com/schwehr/bc44b91a37cd621212c4>

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
<https://gist.github.com/schwehr/c143927ca25d03a10265>
- autotest2/gdrivers/gdrivers_util.py
<https://gist.github.com/schwehr/dd75f73cedf8f7b5357e>
- autotest2/gdrivers/tiff_read_test.py
<https://gist.github.com/schwehr/a35b2bc8a7956ef1f620> (I'm
leading towards moving driver tests in gcore to gdrivers)
- autotest2/ogr/geojson_test.py
<https://gist.github.com/schwehr/6cbdc3482055d2237ad2>

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++
<https://google-styleguide.googlecode.com/svn/trunk/cppguide.html> Python
<https://google-styleguide.googlecode.com/svn/trunk/pyguide.html>

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 testin

Re: [gdal-dev] GDAL testing

[Dmitry Baryshnikov]

 of dependent libs e.g. netcdf/hdf4/5, kakadu, 
openjpeg, etc.


-kurt
Engineer at Google


On Sat, Sep 5, 2015 at 7:48 AM, Dmitry Baryshnikov 
<bishop@gmail.com <mailto:bishop@gmail.com>> wrote:


Hi Even,

05.09.2015 17:10, Even Rouault пишет:

Dmitry,

During the code sprint in FOSS4G 2015 (Korea, Seoul) I
plan to start
refactoring Cmake for GDAL (everybody are welcome
http://2015.foss4g.org/programme/code-sprint/). This is
good starting
point to try release an idea to reformat source tree
(combine drivers on
some principles - raster/vector/raster+vector). I digging
the mailing
list, but didn't found discussion started by Even about this.

Regarding unified drivers, it was a bit mentionned in
https://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification .
Basically the
PCIDSK drivers have been merged in frmts/pcidsk, the PDF ones
in frmts/pdf.
And the raster side of GPKG has been added to the existing
ogr/ogrsf_frmts/geopackage
Potential changes on the tree structure were left out in the
"Potential
changes that are *NOT* included in this RFC" paragraph.

I plan to experiment with this and if I get good results, RFC will
be written.

Also we have
new type of drivers - network. So, how it'll be best to
organise sources?
This can be not only drivers, but the whole source tree.
How should the
ideal GDAL source tree looks like?

Also I plan:
1. Move all internal libraries (zlib, libtiff, libjpeg,
etc.) to
separate github repos to use CMake ExternalProject feature.

Just to give some context: the point for the internal
libraries was to have a
no-brainer way of building GDAL without any prerequisite.
- internal zlib is identical to its upstream v1.2.3 AFAIK
- internal libtiff: most files are identical to libtiff CVS,
but a few ones
(tiffconf.h, tif_config.h) have been modified for integration
with GDAL CPL, and
tif_vsi.c is GDAL specific (I/O implementation) + a build time
hack for TIFF
JPEG 12 bit support
- internal libjpeg is mostly upstream libjpeg v6b + one patch.
There's also
the build hack for libjpeg12

I only plan to move this internal libraries in separate repos, not
to link official ones. So this is only give more structured
sources tree.


2. Remove any other building systems

That sounds ambitious. Given the complexity and maturity of
our current build
systems, I guess this would take some time to have CMake catch up.

Yes, certainly. But anyhow current CMake branch not fully
consistent for current build system. So this have to be done.


3. Try CTest for testing

What do you think it will bring w.r.t our current testing
system ? Do we want
to be dependant of a particular build system for our tests ?
Regarding testing, I've somehow understood Kurt had mentionned
plans for a
"gdalautotest2"

This is only subject of experiments. Let's try CTest and see if it
fits.


Regarding all the above, I assume you mean in a fork of yours ?

Yes. All experiments will be on forked GDAL in separate branch.


As for me the ideal structure should looks like:
+ apps
+ autotests
+ bindings
+ core
+ port
+ ogr
+ gcore

gnm core would go here too ?

Yes


+ cmake
+ data
+ docs
+ doxygen
+ readme
+ drivers
+ raster
+ vector
+ network
+ combined
+ CMakeLists.txt
+ LICENSE

So, at the root of sources tree we will have only 8
folders and 2 files.

Is the churn in the tree structure worth the effort ? Be aware
that there are a
number of interdependencies between drivers, so this might
require fixing a
number of source files. What advantages do you see in a new
structure ?

1. More ease to understand sources tree for novice.
2. More useful for CMake macro. In current release there are a lot
of hardcoded things. Macro give more flexibility.
3. More ease to add some new check needed by separate drivers.
4. More configurable (ease selected depended libraries installed
in OS, or should be loaded via ExternalProject), more dependence
checks.
5. May be CPack using in future to create distros.


I'm afraid that if you wa

[gdal-dev] Code sprint Korea, reformat sources tree

[Dmitry Baryshnikov]

Hi everybody,

During the code sprint in FOSS4G 2015 (Korea, Seoul) I plan to start
refactoring Cmake for GDAL (everybody are welcome 
http://2015.foss4g.org/programme/code-sprint/).
This is good starting point to try release an idea to reformat source
tree (combine drivers on some principles - raster/vector/raster+vector).
I digging the mailing list, but didn't found discussion started by Even about 
this.
Also we have new type of drivers - network. So, how it'll be best to organise 
sources?
This can be not only drivers, but the whole source tree. How should the
ideal GDAL source tree looks like?

Also I plan:
1. Move all internal libraries (zlib, libtiff, libjpeg, etc.) to 
separate github repos to use CMake ExternalProject feature.

2. Remove any other building systems
3. Try CTest for testing

As for me the ideal structure should looks like:
+ apps
+ autotests
+ bindings
+ core
  + port
  + ogr
  + gcore
+ cmake
+ data
+ docs
  + doxygen
  + readme
+ drivers
  + raster
  + vector
  + network
  + combined
+ CMakeLists.txt
+ LICENSE

So, at the root of sources tree we will have only 8 folders and 2 files.

--
Best regards,
Dmitry

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

Re: [gdal-dev] Code sprint Korea, reformat sources tree

[Dmitry Baryshnikov]

Hi Even,

05.09.2015 17:10, Even Rouault пишет:

Dmitry,


During the code sprint in FOSS4G 2015 (Korea, Seoul) I plan to start
refactoring Cmake for GDAL (everybody are welcome
http://2015.foss4g.org/programme/code-sprint/). This is good starting
point to try release an idea to reformat source tree (combine drivers on
some principles - raster/vector/raster+vector). I digging the mailing
list, but didn't found discussion started by Even about this.

Regarding unified drivers, it was a bit mentionned in
https://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification . Basically the
PCIDSK drivers have been merged in frmts/pcidsk, the PDF ones in frmts/pdf.
And the raster side of GPKG has been added to the existing
ogr/ogrsf_frmts/geopackage
Potential changes on the tree structure were left out in the "Potential
changes that are *NOT* included in this RFC" paragraph.
I plan to experiment with this and if I get good results, RFC will be 
written.

Also we have
new type of drivers - network. So, how it'll be best to organise sources?
This can be not only drivers, but the whole source tree. How should the
ideal GDAL source tree looks like?

Also I plan:
1. Move all internal libraries (zlib, libtiff, libjpeg, etc.) to
separate github repos to use CMake ExternalProject feature.

Just to give some context: the point for the internal libraries was to have a
no-brainer way of building GDAL without any prerequisite.
- internal zlib is identical to its upstream v1.2.3 AFAIK
- internal libtiff: most files are identical to libtiff CVS, but a few ones
(tiffconf.h, tif_config.h) have been modified for integration with GDAL CPL, and
tif_vsi.c is GDAL specific (I/O implementation) + a build time hack for TIFF
JPEG 12 bit support
- internal libjpeg is mostly upstream libjpeg v6b + one patch. There's also
the build hack for libjpeg12
I only plan to move this internal libraries in separate repos, not to 
link official ones. So this is only give more structured sources tree.



2. Remove any other building systems

That sounds ambitious. Given the complexity and maturity of our current build
systems, I guess this would take some time to have CMake catch up.
Yes, certainly. But anyhow current CMake branch not fully consistent for 
current build system. So this have to be done.



3. Try CTest for testing

What do you think it will bring w.r.t our current testing system ? Do we want
to be dependant of a particular build system for our tests ?
Regarding testing, I've somehow understood Kurt had mentionned plans for a
"gdalautotest2"

This is only subject of experiments. Let's try CTest and see if it fits.


Regarding all the above, I assume you mean in a fork of yours ?

Yes. All experiments will be on forked GDAL in separate branch.



As for me the ideal structure should looks like:
+ apps
+ autotests
+ bindings
+ core
+ port
+ ogr
+ gcore

gnm core would go here too ?

Yes



+ cmake
+ data
+ docs
+ doxygen
+ readme
+ drivers
+ raster
+ vector
+ network
+ combined
+ CMakeLists.txt
+ LICENSE

So, at the root of sources tree we will have only 8 folders and 2 files.

Is the churn in the tree structure worth the effort ? Be aware that there are a
number of interdependencies between drivers, so this might require fixing a
number of source files. What advantages do you see in a new structure ?

1. More ease to understand sources tree for novice.
2. More useful for CMake macro. In current release there are a lot of 
hardcoded things. Macro give more flexibility.

3. More ease to add some new check needed by separate drivers.
4. More configurable (ease selected depended libraries installed in OS, 
or should be loaded via ExternalProject), more dependence checks.

5. May be CPack using in future to create distros.


I'm afraid that if you want to change multiple things at a time (build system,
testing mechanisms, tree structure), you will never manage to get a working
result. Incremental approaches when feasible are less risky (but admitedly
involve potentially a larger cumulated effort).
Yes, you may be right. But it seems to me that current Cmake version is 
too complicated than it can be. If Ican improve it it'll solve lot of 
problems, if not - ok this will be only an unsuccessful experiment.


Even

I do not insist, maybe it's a crazy idea. But as was the discussion of 
unification, it seemed to me that this worth trying during improvements 
Cmake build system.


Best regards,
Dmitry

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

Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver

[Dmitry Baryshnikov]

Hi Stefan,

The QMS (QuickMapServices) plugin uses the GDAL AGS capability to work 
with ArcGIS MapServe, so if gdal works with you ImageService, th QMS 
will work too.


Best regards,
Dmitry

11.08.2015 10:15, Stefan Keller пишет:

Dmitry

Oh, thanks.

Do you know BTW somebody from QuickMapServices (which also seems to
support some of ArcGIS REST API for QGIS)?
I'd like to know if this plugin only works with ArcGIS MapServer (or
also ImageService of static MapService/WMS) and I'd like configure an
own MapServer (and it shows nothing).

Yours, Stefan


2015-08-10 18:55 GMT+02:00 Dmitry Baryshnikov bishop@gmail.com:

Hi Stefan,

The ArcGIS REST API was introduced in GDAL 2.0 (see
http://gdal.org/frmt_wms.html). What is you GDAL version?

Best regards,
 Dmitry

10.08.2015 19:02, Stefan Keller пишет:

Hi Dmitry

When testing your example I get No mini-driver registered for 'AGS'.:


gdal_translate -of PNG ags.xml ags_test.png --config CPL_DEBUG ON

ERROR 1: GDALWMS: No mini-driver registered for 'AGS'.
GDALOpen failed - 1
GDALWMS: No mini-driver registered for 'AGS'.

Do you know if this AGS mini-driver code is made publicly available i.e.
being pushed to the GDAL source/trunk?

Yours, Stefan


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







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

Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver

[Dmitry Baryshnikov]

Hi Stefan,

The ArcGIS REST API was introduced in GDAL 2.0 (see 
http://gdal.org/frmt_wms.html). What is you GDAL version?


Best regards,
Dmitry

10.08.2015 19:02, Stefan Keller пишет:

Hi Dmitry

When testing your example I get No mini-driver registered for 'AGS'.:

gdal_translate -of PNG ags.xml ags_test.png --config CPL_DEBUG ON
ERROR 1: GDALWMS: No mini-driver registered for 'AGS'.
GDALOpen failed - 1
GDALWMS: No mini-driver registered for 'AGS'.

Do you know if this AGS mini-driver code is made publicly available 
i.e. being pushed to the GDAL source/trunk?


Yours, Stefan

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




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

[gdal-dev] Adopt RFC48: Geographical networks support

[Dmitry Baryshnikov]

Hi everybody,

The motion of RFC48 has been adopted with support from PSC members JukkaR, 
TamasS and EvenR.

The code merged in trunk now (r29585). Let me know if issues arise.

Also the RFC 
(https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) and
RFC common page (https://trac.osgeo.org/gdal/wiki/RfcList) were corrected.

--
Best regards,
Dmitry

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

Re: [gdal-dev] Adopt RFC48: Geographical networks support

[Dmitry Baryshnikov]

Hi Stephen,

31.07.2015 22:54, Stephen Woodbridge пишет:

On 7/31/2015 2:51 PM, Dmitry Baryshnikov wrote:

Hi everybody,

The motion of RFC48 has been adopted with support from PSC members
JukkaR, TamasS and EvenR.

The code merged in trunk now (r29585). Let me know if issues arise.

Also the RFC
(https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) and 

RFC common page (https://trac.osgeo.org/gdal/wiki/RfcList) were 
corrected.




This looks very interesting. I have a few questions which might get 
added to the futures if they are not already supported.


Are there any drivers yet? Which?
  * like read/write OSM data or pgRouting tables
By now only two drivers present - both implements generic (or GDAL) 
network. The pgRouting driver in plans. The GNMNetwork API let write 
features to the network and connect them. See 
https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support and 
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_arch.dox and 
https://github.com/OSGeo/gdal/blob/trunk/gdal/gnm/gnm_tut.dox


Are there plans to support turn restrictions?
  * OSM defines edge-node-edge restrictions AND edge-edge-edge-... 
restrictions

* currently OSRM only supports edge-node-edge restrictions
  * pgRouting supports edge-edge-edge-... restrictions
In GNM you can block edge and connection (node), but in generic network. 
In other drivers i.e. pgRoputing, OSRM, graphopper etc. it'll depends on 
implementation. Also the API of GNMNetwork class may be change (so the 
compiling of GNM is disabled by default).


There is a real need to be able to move network data between pgRouting 
and OSRM. The osm2pgrouting tool is undergoing some enhancements 
during the current GSoC. There is also a need to be able to move 
pgrouting tables to OSM pbf files so we can load them into OSRM and 
this seems like an excellent use case for this.
We can begin thinking about network2network tool after the couple of 
network drivers will be implemented. The help is welcome, as I plan now 
to concentrate on cmake for GDAL.



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




Best regards,
Dmitry

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

Re: [gdal-dev] Adopt RFC48: Geographical networks support

[Dmitry Baryshnikov]

Hi,

this is error. Fixed in r29588

Best regards,
Dmitry

01.08.2015 00:02, Even Rouault пишет:

(so the
compiling of GNM is disabled by default).

Just wanted to mention that with the Unix build, it is enabled by default.

Even



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

Re: [gdal-dev] Motion: Adopt FRC48: Geographical networks support

[Dmitry Baryshnikov]

Hi,

now we have +3 for adopt RFC48: Even, Jukka and Tamas

Also I merged gnm with last trunk. Travis CI passed - 
https://github.com/OSGeo/gdal/pull/60


Best regards,
Dmitry


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

Re: [gdal-dev] Motion: Adopt FRC48: Geographical networks support

[Dmitry Baryshnikov]

Hi everybody,

Just a friendly remainder about motion adopt RFC48. Geographical 
networks support.


Now we have +2 (+1 from me as proposer and +1 from Even). Formally the 
RFC can be adopted, but maybe there is some disagreement or some 
valuable comments.


Best regards,
Dmitry


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

[gdal-dev] Motion: Adopt FRC48: Geographical networks support

[Dmitry Baryshnikov]

Hi,

I finished the work on merging the GSoC2014  Geographical networks 
support in GDAL to trunk.
The RFC 
(https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) 
was corrected.

The pull request (https://github.com/OSGeo/gdal/pull/60) created.
Travis building passed.

I think it's time to vote for adopt the RFC 48 Geographical networks 
support and to merge the pull request to the GDAL sources trunk. 
According to https://trac.osgeo.org/gdal/wiki/rfc1_pmc I start the vote 
and my +1 for adopt.


--
Best regards,
Dmitry

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

Re: [gdal-dev] RFC 48: Geographical networks support

[Dmitry Baryshnikov]

Hi Even,

10.07.2015 00:19, Even Rouault пишет:

Hi Dmitry,


I have just finished the integration of GSoC2014 work into the
geographical network support in GDAL.
The major changes from original code:
1) The base network class (GNMNetwork) is inherited form GDALDataset. So
any GDAL utility, that works with GDALDataset can work with GNMNetwork.
2) Geographical network is a new type of data, additionally to the
DCAP_RASTER and DCAP_VECTOR, added DCAP_GNM
3) I created the generic implementation of GDAL geographical network
(GNMGenericNetwork). The generic network have some features: support of
connection rules, support virtual vertices and edges, etc. The
GNMNetwork API can be changed in future as common functions to generic
network and some other networks (pgRouting, ArcGIS, OSRM, etc.) should
be moved to the GNMNetwork class.
4) Two network drivers created for generic network: file based
datasource and db based datasource. The file network driver tested on
ESRI shapefile and db - on PostGIS. The another vector datasource which
are not applicable with this drivers should have their own drivers.

I could probably figure out that myself by looking at the code, but what are
the main difference between the generic file network driver and the db file
network driver ? Both should use the generic OGR API, no ?

The difference come from the OGR driver specific. For example, database can
store strings more than 255 characters, but shape file - not (I need to 
store the

spatial reference somethere), also in file based sources the layer usually
connect with it's own datasource,  and database have a one datasource 
for all

layers. Also, in file based datasource the network is a sonamed folder, and
during deletion process the folder may be deleted if it empty (if user 
put to
this folder it's own files, the folder will not deleted). In case of 
database the
network is a database schema. So, the such differences force me to make 
the two
drivers. Also this drivers show the example of implementation the 
generic network

support.



5) The main method of created and configured GNMNetwork is GetPath,
which return the temporary OGRLayer (similar to ExecuteSQL).
6) By default the GNM is switched off. The ./configure --with-gnm should
be run to enable GNM. Mayne set it on by default?

I think the decision depends mostly on how much we are confident that the API
is stable. While there's not a non-generic driver implemented, there's
potentially a risk (I think, but I've not a strong opinion on this.)

Ok, let leave it. Also I change nmake to not build GNM by default



7) The python binding is implemented and used in tests.

The RFC 48 in most cases is actual, except C API, which is not
implemented.  Do we need it?

The idea is that the SWIG bindings only needs to know the C API, which provide
some insulation from C++ ABI changes. So you could theoretically use the GDAL
2.0.0 Python bindings with a GDAL 2.1.0 shared object.
But the main reason might be to avoid issues related to C++ ABI if not using
the same compiler for the GDAL dll and building the Python bindings. Which can
happen on Windows since the Python bindings require the same MSVC version than
the one used to compile Python itself. When sticking to the C ABI, you can be
safe. With the C++ ABI, some bad things could potentially happen.

Done



https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support

Links:

Perhaps do you have a git branch somewhere (just for the sake of easier
applying) ?

Ok, I send the pull request.



- diff with binary test data -
https://drive.google.com/file/d/0BzlLlHyrgQHkNkktUmxYbWtjV3M/view?usp=shari
ng - diff without binary test data -
https://drive.google.com/file/d/0BzlLlHyrgQHkZ2lZN2wwTTVOQlE/view?usp=shari
ng - binary test data -
https://drive.google.com/file/d/0BzlLlHyrgQHkTTJjRFZNOEtfb3c/view?usp=shari
ng

Code reviewing and testing are welcome. Also the some decisions in
implementation can be discussed.

 From a random skimming, I'm wondering about the below :

+%inline %{
+  GNMNetworkShadow* CastToNetwork(GDALMajorObjectShadow* base) {
+return static_castGNMNetworkShadow*(base);
+  }
+%}
+
+%inline %{
+  GNMGenericNetworkShadow* CastToGenericNetwork(GDALMajorObjectShadow* base)
{
+return static_castGNMGenericNetworkShadow*(base);
+  }
+%}
+

Shouldn't that be a dynamic_cast ? Otherwise you'll manage to cast any
GDALMajorObject into a GNM even when it is not valid. You could probably
test that by trying to cast a TIFF dataset or something completely irrelevant.

The compiler didn't let me dynamic cast from void* to void* (as the
GDALMajorObjectShadow* is typedef void* and GNMNetworkShadow*,
GNMGenericNetworkShadow* also void). Any idea how to solve this?

The GDAL 2.0 provide ability to create datasets combine vector and
raster data (drivers support both types).
In case of PostGIS we can have the driver combined vector, raster and
networks (pgRouting). Maybe someone give an idea how it can be done.

[gdal-dev] RFC 48: Geographical networks support

[Dmitry Baryshnikov]

Hi everybody,

I have just finished the integration of GSoC2014 work into the 
geographical network support in GDAL.

The major changes from original code:
1) The base network class (GNMNetwork) is inherited form GDALDataset. So 
any GDAL utility, that works with GDALDataset can work with GNMNetwork.
2) Geographical network is a new type of data, additionally to the 
DCAP_RASTER and DCAP_VECTOR, added DCAP_GNM
3) I created the generic implementation of GDAL geographical network 
(GNMGenericNetwork). The generic network have some features: support of 
connection rules, support virtual vertices and edges, etc. The 
GNMNetwork API can be changed in future as common functions to generic 
network and some other networks (pgRouting, ArcGIS, OSRM, etc.) should 
be moved to the GNMNetwork class.
4) Two network drivers created for generic network: file based 
datasource and db based datasource. The file network driver tested on 
ESRI shapefile and db - on PostGIS. The another vector datasource which 
are not applicable with this drivers should have their own drivers.
5) The main method of created and configured GNMNetwork is GetPath, 
which return the temporary OGRLayer (similar to ExecuteSQL).
6) By default the GNM is switched off. The ./configure --with-gnm should 
be run to enable GNM. Mayne set it on by default?

7) The python binding is implemented and used in tests.

The RFC 48 in most cases is actual, except C API, which is not 
implemented.  Do we need it?

https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support

Links:
- diff with binary test data - 
https://drive.google.com/file/d/0BzlLlHyrgQHkNkktUmxYbWtjV3M/view?usp=sharing
- diff without binary test data - 
https://drive.google.com/file/d/0BzlLlHyrgQHkZ2lZN2wwTTVOQlE/view?usp=sharing
- binary test data - 
https://drive.google.com/file/d/0BzlLlHyrgQHkTTJjRFZNOEtfb3c/view?usp=sharing


Code reviewing and testing are welcome. Also the some decisions in 
implementation can be discussed.


The GDAL 2.0 provide ability to create datasets combine vector and 
raster data (drivers support both types).
In case of PostGIS we can have the driver combined vector, raster and 
networks (pgRouting). Maybe someone give an idea how it can be done.


--
Best regards,
Dmitry

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

Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver

[Dmitry Baryshnikov]

Hi James,

As the server didn't provide information about levels, some help needed 
to calculate this values. Also the all layers switched off, so we need 
to tell which layers should be shown.
I create such xml file based on information from here: 
https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=true


 GDAL_WMS
Service name=AGS
ServerUrlhttps://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer/ServerUrl
ImageFormatpng/ImageFormat
Layersshow:1,2,3/Layers
BBoxOrderxyXY/BBoxOrder
SRS3857/SRS
/Service
DataWindow
UpperLeftX-1821098.1612395868/UpperLeftX
UpperLeftY9441422.428028269/UpperLeftY
LowerRightX1157719.0542395862/LowerRightX
LowerRightY6462605.212549096/LowerRightY
SizeX1024/SizeX
SizeY1024/SizeY
/DataWindow
/GDAL_WMS

$ gdal_translate -of PNG ~/tmp/ags.xml ~/tmp/ags_test.png --config 
CPL_DEBUG ON

GDAL: GDALOpen(/home/bishop/tmp/ags.xml, this=0x15138c0) succeeds as WMS.
Input file size is 512, 512
AGS: URL = 
https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer/export?f=imagebbox=-1821098.16123959,6462605.21254910,1157719.05423959,9441422.42802827size=512,512dpi=imageSR=3857bboxSR=3857format=pnglayerdefs=layers=show:1,2,3transparent=falsetime=layerTimeOptions=dynamicLayers=


HTTP: Requesting [1/1] 
https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer/export?f=imagebbox=-1821098.16123959,6462605.21254910,1157719.05423959,9441422.42802827size=512,512dpi=imageSR=3857bboxSR=3857format=pnglayerdefs=layers=show:1,2,3transparent=falsetime=layerTimeOptions=dynamicLayers=
HTTP: Request [0] 
https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer/export?f=imagebbox=-1821098.16123959,6462605.21254910,1157719.05423959,9441422.42802827size=512,512dpi=imageSR=3857bboxSR=3857format=pnglayerdefs=layers=show:1,2,3transparent=falsetime=layerTimeOptions=dynamicLayers= 
: status = 200, content type = image/png, error = (null)
GDAL: GDALOpen(/vsimem/wms/0x15dc720/wmsresult.dat, this=0x15c3d00) 
succeeds as PNG.

GDAL: GDALClose(/vsimem/wms/0x15dc720/wmsresult.dat, this=0x15c3d00)
0...10...20...30...40...50...60...70...80...90...100 - done.
GDAL: GDALClose(/home/bishop/tmp/ags_test.png, this=0x1599830)
GDAL: GDALClose(/home/bishop/tmp/ags.xml, this=0x15138c0)




Also I test this xml in QGIS - works fine.

Best regards,
Dmitry

07.07.2015 18:42, Passmore, James H. пишет:

Fromhttp://www.gdal.org/frmt_wms.html   I see you can access an ArcGIS REST 
API like:

gdalinfohttp://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer?f=jsonpretty=true;

and

gdal_translatehttp://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer?f=json;
  wms.xml -of WMS

These above examples work for me.

When I try on a BGS service it fails as below:

...:\gdalinfohttps://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=true;
gdalinfo failed - unable to open 
'https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=
true'.

And:

..:\gdal_translatehttps://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=true;
  bgs.xml -of WMS --debug ON
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_BAG.dll using 
GDALRegister_BAG.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_ECW_JP2ECW.dll 
using GDALRegister_ECW_JP2ECW.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_FITS.dll using 
GDALRegister_FITS.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_GMT.dll using 
GDALRegister_GMT.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_HDF4.dll using 
GDALRegister_HDF4.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_HDF4Image.dll 
using GDALRegister_HDF4Image.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_HDF5.dll using 
GDALRegister_HDF5.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_HDF5Image.dll 
using GDALRegister_HDF5Image.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_KEA.dll using 
GDALRegister_KEA.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_MG4Lidar.dll 
using GDALRegister_MG4Lidar.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_MrSID.dll using 
GDALRegister_MrSID.
GDAL: Auto register C:\apps\gisinternals\bin\gdaL\plugins\gdal_netCDF.dll using 
GDALRegister_netCDF.
HTTP: 
Fetch(https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=true)
WMS: Did not get levels
HTTP: 
Fetch(https://map.bgs.ac.uk/arcgis/rest/services/UKSO/UKSO_BGS/MapServer?f=jsonpretty=true)
GDALOpen failed - 0

Is the reason that HTTPS is not supported here at all, or if not what might be 
wrong with the service/request/ configuration?

Thanks

James




  This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 

Re: [gdal-dev] RPC orthorectification accuracy issues.

[Dmitry Baryshnikov]

Hi,
I think the vendor specific shifts should be accepted to RPC while 
reading via mdreader or something same. So the fix_PleiadesRPC.patch 
looks good.
Also about changing alg/gdal_rpc.cpp: мaybe the addition config key, 
i.e. RPC_SHIFT which will be 0.5 as default value?


Best regards,
Dmitry

19.06.2015 17:35, Even Rouault пишет:

Le vendredi 19 juin 2015 15:47:54, Pablo d'Angelo a écrit :

Dear GDAL Developers,

i have recently compared the results of our internal RPC based
orthorectification software and have found several difference, which I
think are due to various corner vs center of pixel issues in the RPC
transform code. This lead to significant shifts when using lower
resolution DEMs, such as SRTM, particularly in hilly and mountainous
regions.

I have prepared an analysis and patches to fix these issues at:
https://trac.osgeo.org/gdal/ticket/5993

Hi Pablo,

I had seen your well documented ticket and wanted to give feedback. Thanks for
the reminder.
To my opinion, adjustments between vendor/formats conventions and the GDAL
convention (0,0=upper-left corner of upper-lef pixel) should be done during
the reading of the RPC parameters from their source (similarly to what is done
when reading a geotransform with pixel-is-center convention), so as to make
the
https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_RPCTransformPoint.patch
patch unnecessary.
Apart .rpb and .rpc_txt, we can also read RPC from GeoTIFF, NITF, ENVI,
Oracle, PCIDSK... so I'm wondering what our situation is related to them.
Of course this also leaves the embarassing question of which convention to
adopt when writing RPC values in .rpb or _rpc.txt files... Probably DG
convention for .rpb ?

fix_rpc_dem_interpolation.patch looks good to me.

Even



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

Re: [gdal-dev] gdalwarp on a separate RPC model

[Dmitry Baryshnikov]

Hi Yi,

GDAL use the RPC which it report by gdalinfo. If gdalinfo reports old 
RPC, you have to clean them from dataset. It seem's to me that rpb 
(*_rpc.txt, etc.) files accepted only on GeoTIFF and TILL formats. On 
GDAL 2.0 also jp2 added. So NITF is not a right format for use external 
RPC. So, first of all try to gdal_translate you format to GTiff, and 
than try to create so-name rpb file.


Best regards,
Dmitry

15.06.2015 21:18, Yi Dong пишет:

Dear List,

I have a question about recitify satellite images that has RPC camera 
using gdalwarp.  I know gdalwarp can be used for this task, with using 
RPC metadata (either packed inside the NITF or stored inside RPB files)

Normally, the image folder shall contain following files
input.ntf
input.rpb
input.imd
etc...
The command I used for this is
gdalwarp -rpc input.ntf -to RPC_HEIGHT=200 rectified.tif

Now I performed some geo-correction on the satellite image and 
generate a corrected RPC model (with imporved offset values) and I 
store this correct RPC camera in 'correct.rpb'.  Now I am trying to 
use this 'correct.rpb' to recitify the image

I tried
gdalwarp -rpc input.ntf correct.rpb -to RPC_HEIGHT=200 
recitify_corrected.tif

but it failed with following error
ERROR 4: 'correct.rpb' not recognized as a supported file format

Then I tried to overwrite the 'input.rpb' in the image folder with my 
'corrected.rpb', run 'gdalwarp -rpc input.ntf -to RPC_HEIGHT=200 
rectified.tif' again but I got exactly same results as I used the 
original RPC model.  I guess that might be because gdalwarp used RPC 
parameter that was packed inside NITF image itself, instead of getting 
them from rpb files ?


So Is there other way to use my corrected RPC model in gdal, like 
gdalwarp, gdal_transform, etc.?
Also, gdaltransform doesn't not accept RPB files either.  It only 
recognizes GDAL dataset, i.e. vrt file.  Therefore I need to generate 
vrt file from my RPB.  Is there any vrt example for RPC camera that I 
can follow?


Thanks a lot
Ian

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




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

Re: [gdal-dev] GDAL Landsat Dirver

[Dmitry Baryshnikov]

Hi,

I would like to note that the Landsat metadata files support added to 
GDAL 2.0 
(https://svn.osgeo.org/gdal/trunk/gdal/gcore/mdreader/reader_landsat.cpp)
I think you can use this metadata reader to parse Landsat metadata file, 
or set to the Landsat dataset the imagery metadata in same manner.
Also, I think the tests for new format in autotest 
(https://svn.osgeo.org/gdal/trunk/autotest/gdrivers/) folder needed.


And, it seems to me that the use:
char** papszBandMeta = NULL;
papszBandMeta = CSLAddString(papszBandMeta, pszFilename);
pLandsatBand-SetMetadata(papszBandMeta);
poDS-SetBand( iBand+1, pLandsatBand);

should ended with free papszBandMeta array:
CSLDestroy(papszBandMeta);

But the new driver look promising!

Best regards,
Dmitry

01.06.2015 15:55, liminlu0314 пишет:

landsatdataset.cpp
http://osgeo-org.1560.x6.nabble.com/file/n5208440/landsatdataset.cpp

landsatdataset.cpp is LANDSAT Driver source code



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GDAL-Landsat-Dirver-tp5208438p5208440.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev




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

Re: [gdal-dev] GDAL 2.0 release plans

[Dmitry Baryshnikov]

Hi Even,

It's strange as I create patch with same command (svn diff --force  
~/md_reader.patch) as previous one.

I add changes for metadata readers directly to svn trunk copy on my PC.
I can create pull request for github GDAL trunk, but it takes some time 
to do, or I can just commit to svn trunk (preferable).

If something will be wrong, it can be easily roll back.

So, I decide to commit my changes to trunk.

Best regards,
Dmitry

03.05.2015 12:11, Even Rouault пишет:

Dmitry,

I didn't manage to apply the patch (due to the binary files)

$ patch -p0  /tmp/md_reader.patch
patching file autotest/gcore/data/md_dg.IMD
patching file autotest/gcore/data/md_dg.RPB
patching file autotest/gcore/data/md_dg.tif
patch:  malformed patch at line 187: \ No newline at end of file

Is there some branch somewhere where it can be tested ?

That said, I have no further remarks on this updated patch which looks good to
me.

Even

Le dimanche 03 mai 2015 01:34:04, Dmitry Baryshnikov a écrit :

Hi everybody,

Let me introduce the patch to the current GDAL v.2 trunk. This patch
change the way how imagery (satellite or aerial) metadata read. I create
some base classes and several metadata readers: DigitalGlobe, GeoEye,
OrbView (change existed code to use metadata readers), add Landsat,
Pleiades, Resurs-DK1 (plan to add about 6 new satellites). Also I added
new metadata domain: IMAGERY to hold some common imagery metadata:
satellite, cloud cover, acquisition date/time. The cloud cover transform
to values from 0 to 100 or 999 for n/a, and date/time to UTC.

Additional code review and testing are welcome. Also let me know, if I
can commit this changes to trunk.

P.S. Even review the code of previous patch. I fix all errors reported
by Even.

Best regards,
  Dmitry

29.04.2015 21:40, Even Rouault пишет:

Hi,

I wanted to have an update from other developers to know where there are
with respect to their planned schedule.
I had noted that :
- Dmitriy wanted to integrate his work on metadata support for various
satellite imagery. I have reviewed a preliminary version of it.
- Ari has ongoing work on Perl. I've seen a few commits passed.
- Pirmin intended to add curve support in Interlis. Haven't seen yet any
commit.

Are you still in track to finalize those works in the following days ?
Would adding the week-end help to have that in Beta1 ? I especially
think to Dmitriy's work who is quite substantial, and perhaps Perl
changes if there are still breaking change to come. Interlis specfic
changes might arrive after Beta1 I think.

Even


Hi,

Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?

And if things go well with this beta (and potentially other beta(s)
needed), we could try a release candidate for end of May. One month of
beta phase might seem a bit short, but I'm not sure extending the beta
testing period more will bring significant additional feedback (and
things tend to slip, so better aim for a tight schedule). Thoughts ?
Anyone using GDAL intensively and/or interesting in 2.0 should already
track trunk closely ;-)

I can wear the hat of 2.0 release manager, but I'm happy to let it to
any other volunteer.

Best regards,

Even


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

Re: [gdal-dev] GDAL 2.0 release plans

[Dmitry Baryshnikov]

Hi Even,

I plan to fix all reported errors on Friday or Saturday, may be add few 
new satellites.


Best regards,
Dmitry

29.04.2015 21:40, Even Rouault пишет:

Hi,

I wanted to have an update from other developers to know where there are with
respect to their planned schedule.
I had noted that :
- Dmitriy wanted to integrate his work on metadata support for various
satellite imagery. I have reviewed a preliminary version of it.
- Ari has ongoing work on Perl. I've seen a few commits passed.
- Pirmin intended to add curve support in Interlis. Haven't seen yet any
commit.

Are you still in track to finalize those works in the following days ? Would
adding the week-end help to have that in Beta1 ? I especially think to
Dmitriy's work who is quite substantial, and perhaps Perl changes if there are
still breaking change to come. Interlis specfic changes might arrive after
Beta1 I think.

Even



Hi,

Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?

And if things go well with this beta (and potentially other beta(s)
needed), we could try a release candidate for end of May. One month of
beta phase might seem a bit short, but I'm not sure extending the beta
testing period more will bring significant additional feedback (and things
tend to slip, so better aim for a tight schedule). Thoughts ?
Anyone using GDAL intensively and/or interesting in 2.0 should already
track trunk closely ;-)

I can wear the hat of 2.0 release manager, but I'm happy to let it to any
other volunteer.

Best regards,

Even


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

Re: [gdal-dev] Implementing a streaming version of KML Driver

[Dmitry Baryshnikov]

Hi,

https://code.google.com/p/libkml/downloads/list?can=1q=colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

The last release was on Feb 2010 - 5 year ago. Does the libkml still alive?
Also libkml has depending on boost, and kml driver has no external 
depending.


Best regards,
Dmitry

29.04.2015 00:03, Yuchen Zhong пишет:

Hello everybody,

I notice that there are two KML drivers in GDAL, namely KMLDriver and 
LIBKMLDriver. Both of them will load all the data into memory.


We would like to write a new KML driver for GDAL, a streaming version, 
so as to reduce memory consumption. We would still want to use LIBKML, 
so that we don't have to reinvent the wheels. However, the LIBKML only 
supports SAX API, and GDAL doesn't seems to works with that very well. 
I am wondering whether it is a good idea to go along this path.


This is about the existing streaming parse in LIBKML (under *KmlStream 
Section*):

https://code.google.com/p/libkml/wiki/KmlEngineReference

Hope can hear some of your opinions about this idea.

Sincerely,

Yuchen


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


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

Re: [gdal-dev] GDAL 2.0 release plans

[Dmitry Baryshnikov]

Hi Even,

As I promise, this is my estimation for finishing previously mentioned 
works:
1) Integrate GSoC'14 GNM by Mikhail Gusev. He finished most of work, but 
I need to review his code. - *plan to finish on 15 of May*
2) Add support for ArcGIS Server REST API to WMS driver. It'll be very 
good to add this functionality to GDAL v.2 - *already commited to trunk**.*
3) Add support for metadata numerous imagery satellites (Alos, EROS, 
Formosat, Kompsat, Landsat, Pleiades, RepidEye, Spot, Resurs-DK). - 
*plan to finished 25 of April *


So only no. 1 will not be ready for GDAL 2.0 beta version release (April 
30th). I think this is not blocking issue. The GNM may be included in 
next release (may be 2.0.1).


Best regards,
Dmitry

13.04.2015 15:01, Even Rouault пишет:

Hi,

Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?

And if things go well with this beta (and potentially other beta(s) needed),
we could try a release candidate for end of May. One month of beta phase might
seem a bit short, but I'm not sure extending the beta testing period more will
bring significant additional feedback (and things tend to slip, so better aim
for a tight schedule). Thoughts ?
Anyone using GDAL intensively and/or interesting in 2.0 should already track
trunk closely ;-)

I can wear the hat of 2.0 release manager, but I'm happy to let it to any
other volunteer.

Best regards,

Even



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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

[Dmitry Baryshnikov]

As for me the main problem is, that gdal write wrong WKT for 3857 
(http://trac.osgeo.org/gdal/ticket/3962).
The Geographic SRS use WGS84 ellipsoid 
(SPHEROID[WGS_1984,6378137,298.257223563]]) instead sphere 
(EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext 
+no_defs],) and all the data shifts.


Best regards,
Dmitry

15.04.2015 19:15, Even Rouault пишет:

Hi,

I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of issues
and findings when trying to write GeoTIFF files in EPSG:3857 in a standard way
(using ProjectedCSTypeGeoKey = 3857), while making them correctly displayed by
ArcGIS (and ideally by other independant implementations).
The current situation is that there's no such way (AFAIK). I'd appreciate any
feedback/suggestion related to that issue.

Best regards,

Even



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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

[Dmitry Baryshnikov]

15.04.2015 23:46, Even Rouault пишет:

Le mercredi 15 avril 2015 22:14:37, Dmitry Baryshnikov a écrit :

As for me the main problem is, that gdal write wrong WKT for 3857
(http://trac.osgeo.org/gdal/ticket/3962).
The Geographic SRS use WGS84 ellipsoid
(SPHEROID[WGS_1984,6378137,298.257223563]]) instead sphere
(EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
+no_defs],) and all the data shifts.

I do think that the above SPHEROID WKT and Proj.4 are both OK, even if they
don't look consistent.

The ArcGIS (or QGIS in qpj) save 3857 in such prj file:

PROJCS[WGS 84 / Pseudo-Mercator,
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
AUTHORITY[EPSG,6326]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4326]],
PROJECTION[Mercator_1SP],
PARAMETER[central_meridian,0],
PARAMETER[scale_factor,1],
PARAMETER[false_easting,0],
PARAMETER[false_northing,0],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AXIS[X,EAST],
AXIS[Y,NORTH],
EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext 
+no_defs],

AUTHORITY[EPSG,3857]]

And GDAL opens such shape file and set the spheroid.
But if I save the shape file in 3857 via GDAL I get ellipsoid:

  PROJCS[WGS_84_Pseudo_Mercator,
GEOGCS[GCS_WGS_1984,
DATUM[D_WGS_1984,
SPHEROID[WGS_1984,6378137,298.257223563]],
PRIMEM[Greenwich,0],
UNIT[Degree,0.017453292519943295]],
PROJECTION[Mercator],
PARAMETER[central_meridian,0],
PARAMETER[false_easting,0],
PARAMETER[false_northing,0],
UNIT[Meter,1],
PARAMETER[standard_parallel_1,0.0]]

And both GDAL(QGIS) and ArcGIS open this shape file and set the ellipsoid!


The datum is technically WGS84 datum (ellipsoidal), even if the projection
only uses the semi major axis (spherical). This is all the hell of this
WebMercator projection ! We use a hack of proj.4 to use classical mercator
transformation with spherical parameters, while still being considered as a
WGS84 datum. When reprojecting from a non-WGS 84 datum (let's say EPSG:4322)
to EPSG:3857, the datum transformation should be from this non-WGS 84 to
ellipsoid WGS 84, and then the WebMercator projection uses the spherical
parameters to compute the easting/northing.

Look:

1) Normal EPSG:3857 transformation (with +nadgrids=@null) :

$ echo 2 49 | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:3857
222656.112419298 6274866.20215882 2.9538588412106

-- correct. Same result as operating in 2 steps :

$ echo 2 49 | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:4326 |
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
222656.112419298 6274866.20215883 2.9538588412106

2) Incorrect definition using +towgs84=0,0,0,0,0,0,0 :

$ gdaltransform -s_srs EPSG:4322 -t_srs +proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +towgs84=0,0,0,0,0,0,0
2 49
222656.112419297 6242580.32725437 -12133.4419494262

2 49 is transformed from EPSG:4322 datum to a spherical datum, instead to the
ellipsoid WGS84 datum.

3) Incorrect definition without +towgs84 or +nadgrids=@null : no datum
transformation at all is done since its only an ellipsoid definition, and
proj.4 will not do any ellipsoid transformation in that case

$ gdaltransform -s_srs EPSG:4322 -t_srs +proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
2 49
222638.981586547 6274861.39400658 0



Best regards,
  Dmitry

15.04.2015 19:15, Even Rouault пишет:

Hi,

I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of
issues and findings when trying to write GeoTIFF files in EPSG:3857 in a
standard way (using ProjectedCSTypeGeoKey = 3857), while making them
correctly displayed by ArcGIS (and ideally by other independant
implementations).
The current situation is that there's no such way (AFAIK). I'd appreciate
any feedback/suggestion related to that issue.

Best regards,

Even

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


Best regards,
Dmitry

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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

[Dmitry Baryshnikov]

Sorry for some spam in GeoTIFF topic.

I'll create some shape files and screenshots and attach them to the 
ticket #3962 to explain what  I mean.


Best regards,
Dmitry

16.04.2015 00:10, Even Rouault пишет:

The ArcGIS (or QGIS in qpj) save 3857 in such prj file:


I hoped that this thread could remain focused just about GeoTIFF encoding.
Shapefile encoding issues are a different matter (see
http://trac.osgeo.org/gdal/ticket/3962)


PROJCS[WGS 84 / Pseudo-Mercator,
  GEOGCS[WGS 84,
  DATUM[WGS_1984,
  SPHEROID[WGS 84,6378137,298.257223563,
  AUTHORITY[EPSG,7030]],
  AUTHORITY[EPSG,6326]],
  PRIMEM[Greenwich,0,
  AUTHORITY[EPSG,8901]],
  UNIT[degree,0.0174532925199433,
  AUTHORITY[EPSG,9122]],
  AUTHORITY[EPSG,4326]],
  PROJECTION[Mercator_1SP],
  PARAMETER[central_meridian,0],
  PARAMETER[scale_factor,1],
  PARAMETER[false_easting,0],
  PARAMETER[false_northing,0],
  UNIT[metre,1,
  AUTHORITY[EPSG,9001]],
  AXIS[X,EAST],
  AXIS[Y,NORTH],
  EXTENSION[PROJ4,+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
+no_defs],
  AUTHORITY[EPSG,3857]]


Are you 100% positive that ArcGIS generates such a .prj ? This doesn't look
like classical ESRI WKT (which generally lacks most AUTHORITY nodes and has no
EXTENSION PROJ4 stuff), but like GDAL WKT.


And GDAL opens such shape file and set the spheroid.
But if I save the shape file in 3857 via GDAL I get ellipsoid:

PROJCS[WGS_84_Pseudo_Mercator,
  GEOGCS[GCS_WGS_1984,
  DATUM[D_WGS_1984,
  SPHEROID[WGS_1984,6378137,298.257223563]],
  PRIMEM[Greenwich,0],
  UNIT[Degree,0.017453292519943295]],
  PROJECTION[Mercator],
  PARAMETER[central_meridian,0],
  PARAMETER[false_easting,0],
  PARAMETER[false_northing,0],
  UNIT[Meter,1],
  PARAMETER[standard_parallel_1,0.0]]

Yes, that's the result after morphToESRI(). Which is probably not the right
ESRI WKT for WebMercator, anyway... Should rather be something like the
following according to http://trac.osgeo.org/gdal/ticket/3962 :
PROJCS[WGS_1984_Web_Mercator_Auxiliary_Sphere,
 GEOGCS[GCS_WGS_1984,
 DATUM[D_WGS_1984,
 SPHEROID[WGS_1984,6378137.0,298.257223563]],
 PRIMEM[Greenwich,0.0],
 UNIT[Degree,0.0174532925199433]],
 PROJECTION[Mercator_Auxiliary_Sphere],
 PARAMETER[False_Easting,0.0],
 PARAMETER[False_Northing,0.0],
 PARAMETER[Central_Meridian,0.0],
 PARAMETER[Standard_Parallel_1,0.0],
 PARAMETER[Auxiliary_Sphere_Type,0.0],
 UNIT[Meter,1.0],
 AUTHORITY[ESRI,102100]]


And both GDAL(QGIS) and ArcGIS open this shape file and set the ellipsoid!

I don't understand what you mean here.



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

Re: [gdal-dev] Snap point to vertex/segment

[Dmitry Baryshnikov]

Hi Federico,
Does the Project method of OGRLineString not suits you? The point snap to
nearest point, the point on line via the project, and point on polygon via
cast the outer or inner rings to line and project too.
Best regards,
Dmitry
11 дек. 2014 г. 0:56 пользователь Even Rouault even.roua...@spatialys.com
написал:

 Le mercredi 10 décembre 2014 22:28:48, Federico Jurio a écrit :
  Dear all, i'm trying to make a snapping tool to project new points in a
  layer to the nearest geometry. First of all, when i activate my tool i
 make
  a buffer of all the geometries in the layer. If the point that i'm trying
  to add in the layer is within the buffer i want to move this point to the
  nearest vertex/segment in that geometry but i don't know how to find the
  new coordinates.
  It would be helpful if someone could help me!

 Frederico,

 Available as ST_Snap in PostGIS (http://postgis.org/docs/ST_Snap.html),
 that
 relies on GEOSSnap : http://geos.osgeo.org/doxygen/geos__c_8h_source.html

 Would be easy to add in OGR geometry class as well (relying on GEOSSnap)

 Even

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

Re: [gdal-dev] GSoC weekly report 8. GDAL Networking

[Dmitry Baryshnikov]

Even hi,

As was noted Mikhail works under windows on QTCreator. There is no autoconf
on window and building python bindings is not trivial.
So I wrote cmake scripts which build fine on both (Linux/windows) os.
Yes, were is some limitations on windows: cannot build swig python bindings
on debug build. This is because linker required python and all it modules
compiled with debug support. But on release build everything is OK.
So the scenario is so: Mikhail develop gnm C methods for bindings and test
them on debug build. If them works fine, than write python bindings in
separate file (i.e. gnm.i) and try to compile on release build. Than
install the bindings and test them too.

Best regards,
Dmitry
11 июля 2014 г. 22:27 пользователь Even Rouault 
even.roua...@mines-paris.org написал:

 Le vendredi 11 juillet 2014 20:21:36, Mikhail Gusev a écrit :
  Hello everyone.
  According to my plan this week I worked on automatic graph building in
 GNM.
  See my blog post:
 
 http://gsoc2014gnm.blogspot.ru/2014/07/week-8-automatic-graph-building.html
  I'm also still a bit blocked on python tests and bindings. I haven't
  succeeded in building GDAL with python support using CMake. But I hope to
  finish this the next week.

 Mikhail,

 why do you mention CMake ? Your tree
 https://github.com/MikhanGusev/gdal/commits/trunk is based on GDAL trunk,
 which uses autoconf.

 Anyway, you don't even need to ask for the python bindings at configure
 time.
 Building them should just be a matter of :

 cd swig/python
 python setup.py build

 And if you want to install them
 * system-wide: (sudo) python setup.py install
 * otherwise export PYTHONPATH=$PWD/build/lib.use_autocompletion

 Even

 --
 Geospatial professional services
 http://even.rouault.free.fr/services.html
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] RPC transform

[Dmitry Baryshnikov]

Hi Ivan,
Look here: 
http://www.gdal.org/gdal__alg_8h.html#af4c3c0d4c79218995b3a1f0bac3700a0


You can find such options:

 *

   RPC_HEIGHT: a fixed height offset to be applied to all points passed
   in. In this situation the Z passed into the transformation function
   is assumed to be height above ground, and the RPC_HEIGHT is assumed
   to be an average height above sea level for ground in the target scene.

 *

   RPC_HEIGHT_SCALE: a factor used to multiply heights above ground.
   Usefull when elevation offsets of the DEM are not expressed in
   meters. (GDAL = 1.8.0)

 *

   RPC_DEM: the name of a GDAL dataset (a DEM file typically) used to
   extract elevation offsets from. In this situation the Z passed into
   the transformation function is assumed to be height above ground.
   This option should be used in replacement of RPC_HEIGHT to provide a
   way of defining a non uniform ground for the target scene (GDAL =
   1.8.0)

 * RPC_DEMINTERPOLATION: the DEM interpolation (near, bilinear or cubic)


Best regards,
Dmitry

16.01.2013 19:54, Ivan Lucena ?:

Yehiyam,

For that kind of issue my advise is to run in debugging mode. The GDAL 
transformation engine must have an internal pixel geolocation defined. 
It is probably CENTER of the pixel, as in AREA. I am not sure. In that 
case the returning pixel/line refers to AREA and you might need to do 
the adjustment. But again, I would debug it to make sure. We have 
instructions on how to debug GDAL using VS and NetBeans on wiki. I 
just can't find it. I can't find anything about the RPC_DEM either. 
Where did you get it?


Regards,

Ivan

On 1/16/13 7:40 AM, Livneh Yehiyam wrote:


Hi

I have a question about the RPC transform implemented in gdal_rpc.cpp.

If a dem file is specified in the transform options (RPC_DEM) the 
file is sampled to retrieve the elevation of the transformed point.


In the case where the dem file is a DTED file (which defines 
AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem 
file be offset by half a pixel to get the correct height?


Thanks

Yehiyam



This message (including any attachments) issued by RAFAEL- ADVANCED 
DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential 
information intended for a specific individual and purpose, may 
constitute information that is privileged or confidential or 
otherwise protected from disclosure. If you are not the intended 
recipient, you should contact us immediately and thereafter delete 
this message from your system. You are hereby notified that any 
disclosure, copying, dissemination, distribution or forwarding of 
this message, or the taking of any action based on it, is strictly 
prohibited. If you have received this e-mail in error, please notify 
us immediately by e-mail mailto:law...@rafael.co.il and completely 
delete or destroy any and all electronic or other copies of the 
original message and any attachments thereof.



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




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


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