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 
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 :

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 

Re: [gdal-dev] About CMake build again

[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

[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 
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 :
> > 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 

Re: [gdal-dev] WCS driver

[Ari Jolma]

Even Rouault kirjoitti 29.10.2017 klo 12:49:


> So, treat lat,lon and north,east always as exceptions. And in this case

> add an option to make that exception when appropriate and when writing

> the BoundingBox into the request. (But not when reading GridOrigin.

> However, I still have to see what other servers say.)

I'm not sure what you exactly mean with "option". I'd see more that as 
a code branch ("if WCS >= 1.1 with SRS with unusual axis order, do 
axis inversion"), rather than something user visible. Similarly to 
what the WMS driver does in WMS 1.3 vs WMS 1.1


We may need to expose an advanced user option to deal with broken 
servers to avoid doing axis inversion although it would be normally 
required.




Yes, sure. It should be the expected behavior.

Ari


--

Spatialys - Geospatial professional services

http://www.spatialys.com



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

Re: [gdal-dev] 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 :

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 

Re: [gdal-dev] Add timestamp field with value to table during ogr2ogr operation

[Even Rouault]

On dimanche 29 octobre 2017 09:58:06 CET Bo Victor Thomsen wrote:
> To the list -
> 
> I'm converting shapefiles to postgres tables using ogr2ogr. As usual
> with ogr2ogr, it works very well.
> 
> Now I want to automatically add an extra column "created" with the
> current timestamp during the ogr2ogr operation.
> 
> Something like this:
> 
> ogr2ogr .  -sql "SELECT *, CURRENT_TIMESTAMP AS created FROM
> point_data" 
> 
> Shapefile name is "point_data.shp" and CURRENT_TIMESTAMP is a SQL92
> standard function

OGR SQL is only a partial implementation of SQL92 :
http://gdal.org/ogr_sql.html

> 
> However, It doesn't work. Is there some way, I can add this timestamp
> value to the resulting table using a built-in function in ogr2ogr?

You may use the SQL SQLite dialect by adding -dialect SQLite
( http://gdal.org/ogr_sql_sqlite.html )
to your ogr2ogr command line, and that will do what you expect

Or almost, as I see that the column is recognized as a String column with 
values like 
'2017-10-29 10:26:43'. So you may need to do some SQL transformation on the PG 
database 
to properly type it.

Even

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

Re: [gdal-dev] WCS driver

[Even Rouault]

> So, treat lat,lon and north,east always as exceptions. And in this case
> add an option to make that exception when appropriate and when writing
> the BoundingBox into the request. (But not when reading GridOrigin.
> However, I still have to see what other servers say.)

I'm not sure what you exactly mean with "option". I'd see more that as a code 
branch ("if WCS >= 1.1 with SRS with unusual axis order, do axis inversion"), 
rather than something user visible. Similarly to what the WMS driver does in 
WMS 1.3 vs WMS 1.1

We may need to expose an advanced user option to deal with broken servers to 
avoid doing axis inversion although it would be normally required.

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

Re: [gdal-dev] WCS driver

[Ari Jolma]

Even Rouault kirjoitti 29.10.2017 klo 11:52:


The "tradition" in GDAL drivers such as GML, WFS is to strip AXIS from 
the CRS WKT exposed when they are in the "annoying" lat,long and 
northing,easting,


From the GML driver:

{{{

if (poSRS != NULL && m_bInvertAxisOrderIfLatLong &&

GML_IsSRSLatLongOrder(pszSRSName))

{

OGR_SRSNode *poGEOGCS = poSRS->GetAttrNode("GEOGCS");

if( poGEOGCS != NULL )

poGEOGCS->StripNodes("AXIS");

OGR_SRSNode *poPROJCS = poSRS->GetAttrNode("PROJCS");

if (poPROJCS != NULL && poSRS->EPSGTreatsAsNorthingEasting())

poPROJCS->StripNodes("AXIS");

}

}}}

and to switch the coordinates appropriately so that the user sees the 
"GIS friendly" lon,lat and x,y order. It would be propably appropriate 
for the WCS driver to do so as well, as nothing else in GDAL can deal 
with rasters referenced in lat,long order.




So, treat lat,lon and north,east always as exceptions. And in this case 
add an option to make that exception when appropriate and when writing 
the BoundingBox into the request. (But not when reading GridOrigin. 
However, I still have to see what other servers say.)


Now, you may also have to deal with implementation bugs (if what 
MapServer does is indeed a bug), which can sometimes be 
auto-corrected, or not...




We'll see what MapServer developers say. I submitted an issue to its github.

Ari


Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com



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

Re: [gdal-dev] WCS driver

[Even Rouault]

Hi Ari,

> 
> I'd like to have your comment on this.
> 
> Ari Jolma kirjoitti 28.10.2017 klo 17:39:
> > Reading MapServer code, it seems to be based on the idea that x,y is
> > always east,north and when it writes BoundingBox, it swaps x and y if
> > the projection is inverted (like 4326). It does not do that when it
> > writes GridCRS.
> > 
> > GDAL seems to be based on the idea that x,y is what the projection
> > says (what the projection says could be found out with
> > OGRSpatialReference::GetAxis - however, for 4326 it does not say
> > anything).

Depends on how your import the CRS. If you import with importFromEPSG(), it 
will strip axis 
definition when they are in the unusual order. If you do importFromEPSGA(), 
you'll always 
get the axis definition.
(try gdalsrsinfo EPSG:4326 vs gdalsrsinfo EPSGA:4326. Same for EPSG:2393 vs 
EPSGA:2393)

> > This is my impression from WCS driver - I see there's a lot
> > on this issue in the GML driver page.
> 
> I think the fix depends on what's GDAL's opinion to what X,Y is. Is it
> what the projection says or is it easting,northing?
> 

I guess it depends on the WCS version. According to
http://mapserver.org/development/rfc/ms-rfc-41.html , contrary to WCS 1.0,  WCS 
1.1 is 
supposed to honour EPSG axis order, so lat,long for most/all geodetic CRS, and 
easting,northing or northing,easting depending on the actual projected CRS

The "tradition" in GDAL drivers such as GML, WFS is to strip AXIS from the CRS 
WKT exposed 
when they are in the "annoying" lat,long and northing,easting, 

>From the GML driver:
{{{
if (poSRS != NULL && m_bInvertAxisOrderIfLatLong &&
GML_IsSRSLatLongOrder(pszSRSName))
{
OGR_SRSNode *poGEOGCS = poSRS->GetAttrNode("GEOGCS");
if( poGEOGCS != NULL )
poGEOGCS->StripNodes("AXIS");

OGR_SRSNode *poPROJCS = poSRS->GetAttrNode("PROJCS");
if (poPROJCS != NULL && poSRS->EPSGTreatsAsNorthingEasting())
poPROJCS->StripNodes("AXIS");

}
}}}

and to switch the coordinates appropriately so that the user sees the "GIS 
friendly" lon,lat 
and x,y order. It would be propably appropriate for the WCS driver to do so as 
well, as 
nothing else in GDAL can deal with rasters referenced in lat,long order.

Now, you may also have to deal with implementation bugs (if what MapServer does 
is indeed 
a bug), which can sometimes be auto-corrected, or not...

Even

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

Re: [gdal-dev] WCS driver

[Ari Jolma]

jratike80 kirjoitti 28.10.2017 klo 13:10:

Ari Jolma-2 wrote

The case of GeoServer is also strange
https://msp.smartsea.fmi.fi/geoserver/wcs?SERVICE=WCS=1.1.1=GetCoverage=smartsea%3Aeusm2016=image%2Ftiff=61610,7303970,61630,7303990,urn:ogc:def:crs:EPSG::3067=contents

-- GeoServer does not seem to understand that GDAL wants only a 2 x 2
sample - the response is huge (the whole geotiff?).

Ari


An open Geoserver with a DEM of Finland is available for testing at
http://avoindata.maanmittauslaitos.fi/geoserver/wcs?service=WCS=2.0.1=GetCapabilities


Same thing with this server (I'm still testing with version 1.1), except 
that it is nice enough to let me know that


ERROR 1: This request is trying to generate too much data, the limit is 
488.28MB but the actual amount of bytes to be written in the output is 
18479MB


With the help of GeoServer demo tool in its admin panel, it seems 
necessary to add GridCRS to the request


http://avoindata.maanmittauslaitos.fi/geoserver/wcs?SERVICE=WCS=1.1.0=GetCoverage=korkeusmalli_10m%3Akorkeusmalli_10m=image%2Ftiff=44005,7781985,44015,7781995,urn:ogc:def:crs:EPSG::3067=contents=urn:ogc:def:crs:EPSG::3067=urn:ogc:def:method:WCS:1.1:2dSimpleGrid=20.0,-20.0=urn:ogc:def:cs:OGC:0.0:Grid2dSquareCS

GridCRS should be optional but in practise GeoServer seems to require it.

Ari



-Jukka Rahkonen-




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


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

[gdal-dev] Add timestamp field with value to table during ogr2ogr operation

[Bo Victor Thomsen]

To the list -

I'm converting shapefiles to postgres tables using ogr2ogr. As usual 
with ogr2ogr, it works very well.


Now I want to automatically add an extra column "created" with the 
current timestamp during the ogr2ogr operation.


Something like this:

ogr2ogr .  -sql "SELECT *, CURRENT_TIMESTAMP AS created FROM 
point_data" 


Shapefile name is "point_data.shp" and CURRENT_TIMESTAMP is a SQL92 
standard function


However, It doesn't work. Is there some way, I can add this timestamp 
value to the resulting table using a built-in function in ogr2ogr?


(The above command works, if you replace "CURRENT_TIMESTAMP" with ex. 
"OGR_TYPE". Obviously It doesn't produce a timestamp after this edit ;-)


Kind regards
Bo Victor Thomsen




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

Re: [gdal-dev] About CMake build again

[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 :
> 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