Re: [gdal-dev] deb package for 2.2.3

[Grégory Bataille]

wow, ok, a bit more work than I expected. Now I understand why it's hard to
keep it up-to-date.
Thanks for the osgeolive pointer, did not know about it.

Cool if you move soon to 2.3.0 and therefore feeds ubuntugis. I'll still
see if I can quickly get somewhere is the meantime on my own with what you
sent

cheers

---
Gregory Bataille


On Fri, May 4, 2018 at 7:28 AM Sebastiaan Couwenberg 
wrote:

> On 05/04/2018 07:11 AM, Grégory Bataille wrote:
> > I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I
> just
> > got stuck by https://trac.osgeo.org/gdal/ticket/7143.
> > Took me some time to debug because I develop locally on Mac, where the
> > package is at 2.2.3 and the bug is fixed.
> >
> > What does it take to build the .deb package. Is this something that
> someone
> > can do? is this something sufficiently scripted that I can do it and give
> > you guys the result for publication?
>
> In the case of UbuntuGIS, you can rebuild the source package from
> Debian. The sources are available in git:
>
>  https://salsa.debian.org/debian-gis-team/gdal
>  https://salsa.debian.org/debian-gis-team/gdal-grass
>
> Once you have rebuild the gdal package, you need to rebuild all reverse
> dependencies (packages that depend on libgdal20) with the new gdal to
> have them use the new virtual ABI dependency.
>
> Because of interdependencies you need to rebuild the packages in the
> correct order, have a look at:
>
>  https://trac.osgeo.org/ubuntugis/wiki/BuildOrder
>
> Note that this page may have become outdated again. The Debian GIS
> transition trackers shows all libgdal20 reverse dependencies in Debian
> unstable:
>
>  https://linuxminded.nl/debian/gis-transitions/html/gdal.html
>
> You will need to host all the rebuild packages in your own PPA to easily
> install them. If your goal is to update the gdal packages in the
> UbuntuGIS PPA, you need to coordinate your contributions on the
> appropriate mailinglist:
>
>  https://lists.osgeo.org/mailman/listinfo/ubuntu
>
> Due to the lack of manpower, pretty much all the packages in the
> UbuntuGIS PPA get copied from the OSGeoLive PPA where a little more
> manpower is available to create backports of Debian GIS packages for
> Ubuntu LTS releases.
>
> The next OSGeoLive release will be based on bionic, and will rely for a
> large part on the packages already available in Ubuntu because they're
> up-to-date with the latest upstream releases. At least proj & gdal will
> most likely be updated to 5.0.1 & 2.3.0 for OSGeoLive 12.0. So you can
> also just wait for those packages to find their way from the OSGeoLive
> PPA to the UbuntuGIS PPA. Contributing to OSGeoLive is also most welcome.
>
> Kind Regards,
>
> Bas
> ___
> 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] deb package for 2.2.3

[Sebastiaan Couwenberg]

On 05/04/2018 07:11 AM, Grégory Bataille wrote:
> I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I just
> got stuck by https://trac.osgeo.org/gdal/ticket/7143.
> Took me some time to debug because I develop locally on Mac, where the
> package is at 2.2.3 and the bug is fixed.
> 
> What does it take to build the .deb package. Is this something that someone
> can do? is this something sufficiently scripted that I can do it and give
> you guys the result for publication?

In the case of UbuntuGIS, you can rebuild the source package from
Debian. The sources are available in git:

 https://salsa.debian.org/debian-gis-team/gdal
 https://salsa.debian.org/debian-gis-team/gdal-grass

Once you have rebuild the gdal package, you need to rebuild all reverse
dependencies (packages that depend on libgdal20) with the new gdal to
have them use the new virtual ABI dependency.

Because of interdependencies you need to rebuild the packages in the
correct order, have a look at:

 https://trac.osgeo.org/ubuntugis/wiki/BuildOrder

Note that this page may have become outdated again. The Debian GIS
transition trackers shows all libgdal20 reverse dependencies in Debian
unstable:

 https://linuxminded.nl/debian/gis-transitions/html/gdal.html

You will need to host all the rebuild packages in your own PPA to easily
install them. If your goal is to update the gdal packages in the
UbuntuGIS PPA, you need to coordinate your contributions on the
appropriate mailinglist:

 https://lists.osgeo.org/mailman/listinfo/ubuntu

Due to the lack of manpower, pretty much all the packages in the
UbuntuGIS PPA get copied from the OSGeoLive PPA where a little more
manpower is available to create backports of Debian GIS packages for
Ubuntu LTS releases.

The next OSGeoLive release will be based on bionic, and will rely for a
large part on the packages already available in Ubuntu because they're
up-to-date with the latest upstream releases. At least proj & gdal will
most likely be updated to 5.0.1 & 2.3.0 for OSGeoLive 12.0. So you can
also just wait for those packages to find their way from the OSGeoLive
PPA to the UbuntuGIS PPA. Contributing to OSGeoLive is also most welcome.

Kind Regards,

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

[gdal-dev] deb package for 2.2.3

[Grégory Bataille]

Hi all,

I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I just
got stuck by https://trac.osgeo.org/gdal/ticket/7143.
Took me some time to debug because I develop locally on Mac, where the
package is at 2.2.3 and the bug is fixed.

What does it take to build the .deb package. Is this something that someone
can do? is this something sufficiently scripted that I can do it and give
you guys the result for publication?

Thanks

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

[gdal-dev] C# Read Raster slow

[tval]

I am reading a raster to an IntPtr buffer in c#:

band.ReadRaster(256, 256, 128, 128, buf, 128, 128, band.DataType, 6, stride)

I loop through the size of the raster I am retrieving (say 500x500) pixels
and read each 128 block of the raster. The problem is, this can take up to 6
seconds just to read a 500x500 portion of the image! I notice that the very
first read method can often take the longest (4 sec or so). I am trying to
understand why this is so slow and if there is something I can do to resolve
it. I have tried with and without overviews and it does not seem to matter. 
The image is .jp2 and the image sizes are only 2800x2000 in total pixel
size.

Any help would be appreciated.
Travis



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

Re: [gdal-dev] mssql append fails for non-geometry layers

[Tamas Szekeres]

Hi Martin,

For some reason the table hasn't been found and the driver wanted to create
a new table.
I've tried to reproduce this with a shapefile with no geometry uploaded to
MSSQL, but I couldn't.
Can I have your sample data? Which GDAL version has been used?
You could also check what happens by disabling bulk insert by adding *--config
MSSQLSPATIAL_USE_BCP NO*


Thanks,

Tamas


2018-05-03 19:31 GMT+02:00 Martin Landa :

> Hi all,
>
> let's assume sample data:
>
> $ ogrinfo sample.gpkg
>
> 1: SOBR (Point)
> 2: VLA (None)
>
> Append for geometry layers seems to work:
>
> 1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg sobr
>
> ->
>
> 1> select count(*) from sobr
> 2> go
>
> ---
>5437
>
> 2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg sobr
>
> ->
>
> 1> select count(*) from sobr
> 2> go
>
> ---
>   10874
>
> The same procedure fails for non-geometry layers:
>
> 1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg vla
>
> ->
>
> 1> select count(*) from vla
> 2> go
>
> ---
> 111
>
> 2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg vla
> ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client
> 11.0][SQL Se
> rver]There is already an object named 'vla' in the database. When using
> the over
> write option and the layer doesn't contain geometry column, you might
> require to
>  use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous
> layer de
> leted before creating the new one.
> ERROR 1: Terminating translation prematurely after failed
> translation of layer VLA (use -skipfailures to skip errors)
>
> OK, let's try with MSSQLSPATIAL_LIST_ALL_TABLES
>
> 3) ogr2ogr -f MSSQLSpatial -append --config
> MSSQLSPATIAL_LIST_ALL_TABLES YES MSSQL:database=kn sample.gpkg vla
>
> Same error:
>
> ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client
> 11.0][SQL Se
> rver]There is already an object named 'vla' in the database. When using
> the over
> write option and the layer doesn't contain geometry column, you might
> require to
>  use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous
> layer de
> leted before creating the new one.
> ERROR 1: Terminating translation prematurely after failed
> translation of layer VLA (use -skipfailures to skip errors)
>
> Number of records unchanged:
>
> 1> select count(*) from vla
> 2> go
>
> ---
> 111
>
> It seems to me as a bug, or is there anything I miss? Thanks for
> pointers, Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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] mssql append fails for non-geometry layers

[Martin Landa]

Hi all,

let's assume sample data:

$ ogrinfo sample.gpkg

1: SOBR (Point)
2: VLA (None)

Append for geometry layers seems to work:

1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg sobr

->

1> select count(*) from sobr
2> go

---
   5437

2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg sobr

->

1> select count(*) from sobr
2> go

---
  10874

The same procedure fails for non-geometry layers:

1) ogr2ogr -f MSSQLSpatial MSSQL:database=kn sample.gpkg vla

->

1> select count(*) from vla
2> go

---
111

2) ogr2ogr -f MSSQLSpatial -append MSSQL:database=kn sample.gpkg vla
ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client 11.0][SQL Se
rver]There is already an object named 'vla' in the database. When using the over
write option and the layer doesn't contain geometry column, you might require to
 use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous layer de
leted before creating the new one.
ERROR 1: Terminating translation prematurely after failed
translation of layer VLA (use -skipfailures to skip errors)

OK, let's try with MSSQLSPATIAL_LIST_ALL_TABLES

3) ogr2ogr -f MSSQLSpatial -append --config
MSSQLSPATIAL_LIST_ALL_TABLES YES MSSQL:database=kn sample.gpkg vla

Same error:

ERROR 1: Error creating layer: [Microsoft][SQL Server Native Client 11.0][SQL Se
rver]There is already an object named 'vla' in the database. When using the over
write option and the layer doesn't contain geometry column, you might require to
 use the MSSQLSPATIAL_LIST_ALL_TABLES config option to get the previous layer de
leted before creating the new one.
ERROR 1: Terminating translation prematurely after failed
translation of layer VLA (use -skipfailures to skip errors)

Number of records unchanged:

1> select count(*) from vla
2> go

---
111

It seems to me as a bug, or is there anything I miss? Thanks for
pointers, Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal 2.3 ecw 5.4

[Jorge Mendes de Jesus]

Hi
Can confirm that there is a problem, I made a docker for the developers to
test the problem

https://github.com/jorgejesus/gdal-ecw


Jorge

On Thu, May 3, 2018 at 12:04 AM, Jachym Cepicky 
wrote:

> Hi,
>
> I try to build gdal (`git checkout release 2.3`, but the same result I've
> got on master) with ECW support.
>
> I followed the tutorial on https://trac.osgeo.org/gdal/wiki/ECW
>
> Downloaded sdk 5.4 for Linux from https://download.hexagongeospatial.com/
> downloads/ecw/erdas-ecw-jp2-sdk-v5-4-linux
>
> Installed to /opt/hexagon dir
>
> configured with
>
> $ ./configure --with-ecw=/opt/hexagon/ERDAS-ECW_JPEG_2000_SDK-5.4.0/
> Desktop_Read-Only/
>
> made copy of libNCSEcw.so to /usr/local/lib
>
> $ sudo cp /opt/hexagon/ERDAS-ECW_JPEG_2000_SDK-5.4.0/Desktop_Read-
> Only/lib/x64/release/libNCSEcw.so.5.4.0 /usr/local/lib/
> $ sudo ldconfig
>
> And after running `make`, I've got
>
> ```
> make[1]: Entering directory '/home/jachym/src/gdal/gdal/apps'
> /bin/bash /home/jachym/src/gdal/gdal/libtool --mode=link --silent g++
> gdalinfo_bin.lo  /home/jachym/src/gdal/gdal/libgdal.la  -o gdalinfo
> /home/jachym/src/gdal/gdal/.libs/libgdal.so: undefined reference to
> `NCS::CString::utf8_str(std::__cxx11::basic_string std::char_traits, std::allocator >&) const'
> /home/jachym/src/gdal/gdal/.libs/libgdal.so: undefined reference to
> `NCS::CString::Utf8Encode(std::__cxx11::basic_string std::char_traits, std::allocator >&, 
> std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> /home/jachym/src/gdal/gdal/.libs/libgdal.so: undefined reference to
> `NCS::CView::SetTransformList(int, std::__cxx11::list std::allocator >&)'
> /home/jachym/src/gdal/gdal/.libs/libgdal.so: undefined reference to
> `NCS::CString::Utf8Decode(std::__cxx11::basic_string std::char_traits, std::allocator > const&)'
> collect2: error: ld returned 1 exit status
> GNUmakefile:82: recipe for target 'gdalinfo' failed
> make[1]: *** [gdalinfo] Error 1
> make[1]: Leaving directory '/home/jachym/src/gdal/gdal/apps'
> GNUmakefile:105: recipe for target 'apps-target' failed
> make: *** [apps-target] Error 2
> ```
>
> Any hint, what to try?
>
> Thank you
>
> Jachym
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky gmail com
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
>
> ___
> 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