gdal/ogr and spatialite functions as ST_MakeValid: how to build it?

[Andrea Borruso]

Hi,

I have GDAL 2.3.0dev and if I run `ogrinfo -dialect sqlite -sql  "select spatialite_version() from test" test.shp` the result is `spatialite_version() (String) = 4.3.0-RC1`.

I'm using it on windows, it's the gisinternals release.

If I run:

    ogr2ogr valid.shp input.shp -dialect sqlite -sql "select MakeValid(geometry) as geometry, * from input"

I have `no such function: MakeValid`.

I have read here something related to linux environment and SpatiaLite, and I image that I must do something similar to build gdal/ogr binaries with the support of LWGEOM functions. Am I right? Is there some how-to doc?

Thank you

[Jukka Rahkonen]

Hi,

From https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html you
can read that MakeValid/ST_MakeValid is a LWGEOM function so the check
to perform is

SELECT lwgeom_version();

It really seems to give NULL for the GDAL from gisinternals that I have.

-Jukka Rahkonen-

Andrea Borruso kirjoitti 2017-11-01 14:58:
> Hi,
>
> I have GDAL 2.3.0dev and if I run `ogrinfo -dialect sqlite -sql
> "select spatialite_version() from test" test.shp` the result is
> `spatialite_version() (String) = 4.3.0-RC1`.

> I'm using it on windows, it's the gisinternals [1] release.

>
> If I run:
>
> ogr2ogr valid.shp input.shp -dialect sqlite -sql "select
> MakeValid(geometry) as geometry, * from input"
>
> I have `no such function: MakeValid`.
>

> I have read [2] here something related to linux environment and

> SpatiaLite, and I image that I must do something similar to build
> gdal/ogr binaries with the support of LWGEOM functions. Am I right? Is
> there some how-to doc?
>
> Thank you
>

> --
> You received this message because you are subscribed to the Google
> Groups "SpatiaLite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to spatialite-use...@googlegroups.com.
> To post to this group, send email to
> spatiali...@googlegroups.com.
> Visit this group at https://groups.google.com/group/spatialite-users.
> For more options, visit https://groups.google.com/d/optout.
>
>
> Links:
> ------
> [1] http://www.gisinternals.com
> [2]
> https://groups.google.com/d/msg/spatialite-users/wx0RAFTA2tM/sNlt63gVfxAJ

[mj10777]

On Wednesday, 1 November 2017 13:58:32 UTC+1, Andrea Borruso wrote:

Hi,

I have GDAL 2.3.0dev and if I run `ogrinfo -dialect sqlite -sql  "select spatialite_version() from test" test.shp` the result is `spatialite_version() (String) = 4.3.0-RC1`.

I'm using it on windows, it's the gisinternals release.

That is an outdated version, 4.3.0 was released more that 2 years ago

- it would need LWGEOM to be installed (i.e. 'SELECT lwgeom_version(); ' must return a result)

The present developer version uses RTTOPO

- which then must be installed

When you look for the command in:

http://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html

you will see the column 'required module' and the module listed needs to be installed for that command to work.

Mark

[mj10777]

On Wednesday, 1 November 2017 14:05:57 UTC+1, Jukka Rahkonen wrote:

Hi,

 From https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html you
can read that MakeValid/ST_MakeValid is a LWGEOM function so the check
to perform is

SELECT lwgeom_version();

It really seems to give NULL for the GDAL from gisinternals that I have.

For spatialite 4.3.0, then that is a sign that LWGEOM has not been installed

- which may happen if PostGis (that LWGEOM)  is not part of the package 

RTTOPO will/does not have that dependency on PostGis and is completely independent.

Mark

[andy]

Hi Jukka and Mark,

thank you very much.

On 1 November 2017 at 14:17, 'mj10777' via SpatiaLite Users <spatiali...@googlegroups.com> wrote:

That is an outdated version, 4.3.0 was released more that 2 years ago

- it would need LWGEOM to be installed (i.e. 'SELECT lwgeom_version(); ' must return a result)

The present developer version uses RTTOPO

- which then must be installed

Now I know that I have an outdated version and moreover I do not have LWGEOM.

How to build GDAL/OGR binaries with RTTOPO support? Is there some how-to page?

Thank you again

--

___________________

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___________________

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno, 
e farlo durare, e dargli spazio"

Italo Calvino

[mj10777]

On Wednesday, 1 November 2017 14:25:46 UTC+1, Andrea Borruso wrote:

Hi Jukka and Mark,

thank you very much.

On 1 November 2017 at 14:17, 'mj10777' via SpatiaLite Users <spatiali...@googlegroups.com> wrote:

That is an outdated version, 4.3.0 was released more that 2 years ago

- it would need LWGEOM to be installed (i.e. 'SELECT lwgeom_version(); ' must return a result)

The present developer version uses RTTOPO

- which then must be installed

Now I know that I have an outdated version and moreover I do not have LWGEOM.

How to build GDAL/OGR binaries with RTTOPO support? Is there some how-to page?

You don't.

You must compile spatialite (starting with the present developer version) with TTOPO support.

Download from here:

https://gitlab.com/rttopo/rttopo

compile and install.

Then configure spatialite with rttopo support

- ./configure --enable-rttopo=yes

compile and install.

Mark

[a.fu...@lqt.it]

On Wed, 1 Nov 2017 05:58:32 -0700 (PDT), Andrea Borruso wrote:
> Hi,
>
> I have GDAL 2.3.0dev and if I run `ogrinfo -dialect sqlite -sql 
> "select spatialite_version() from test" test.shp` the result is
> `spatialite_version() (String) = 4.3.0-RC1`.

> I'm using it on windows, it's the gisinternals [1] release.

>
> If I run:
>
>     ogr2ogr valid.shp input.shp -dialect sqlite -sql "select
> MakeValid(geometry) as geometry, * from input"
>
> I have `no such function: MakeValid`.
>

> I have read [2] here something related to linux environment

> and SpatiaLite, and I image that I must do something similar to build
> gdal/ogr binaries with the support of LWGEOM functions. Am I right?
> Is there some how-to doc?
>

ciao Andrea,

older versions of SpatiaLite had an optional dependency on LWGEOM,
that wasn't really a free-standing library, it simply was an
internal component of PostGIS eventually available for other
projects.

depending on LWGEOM was largely unsatisfying, mainly because
it lacked long term stability and was plagued by severe
API breakages on each new release.
even more, building LWGEOM alone was unsupported, so you
necessarily had to build a full fledged PostGIS, that in
turn required to build PostgreSQL ... obviously a very
demanding and almost unrealistic prerequisite on Windows.

but on Linux too several distributions (Debian for sure)
refused to continue supporting LWGEOM due to its restless
cross-version instabilities.

so modern versions of SpatiaLite (since 4.4.0) now depend
on RTTOPO [1], a fork from PostGIS/LWGEOM.
RTTOPO really is a self-standing library respecting reasonable
cross-version stability, it just depends on GEOS alone and it
can be easily built on Windows too.
Even more important, RTTOPO not only supports MakeValid
and few others advanced functions; it fully supports
ISO Topology primitives.

[1] https://git.osgeo.org/gogs/rttopo/librttopo

Note: there is a licence issue affecting MakeValid etc;
both LWGEOM and RTTOPO are released under the GPL, and
consequently any tool or application linking one of
these two libraries will be automatically GPLed as well
due to the viral clauses dictated by GPL.

bye Sandro

[andy]

Ciao Alessandro,

On 1 November 2017 at 14:35, <a.fu...@lqt.it> wrote:

On Wed, 1 Nov 2017 05:58:32 -0700 (PDT), Andrea Borruso wrote:

so modern versions of SpatiaLite (since 4.4.0) now depend
on RTTOPO [1], a fork from PostGIS/LWGEOM.
RTTOPO really is a self-standing library respecting reasonable
cross-version stability, it just depends on GEOS alone and it
can be easily built on Windows too.
Even more important, RTTOPO not only supports MakeValid
and few others advanced functions; it fully supports
ISO Topology primitives.

I use GDAL/OGR a lot and it would fantastic to have these functions "inside" it. It would be very convenient, because I'm lazy :)

But to do not have them in GDAL/OGR is not my barrier, I would like to use function like ST_MAKEVALID from command-line.

Now I'm able to use it only in the great spatialitegui.

I have tried to build spatialite with LWGEOM support in a Debian PC, but I made some mistakes, and everytime I run a gdal/ogr command I have the classic (for lamer people like me) error: "symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: sqlite3_column_table_name".

I have written to GDAL mailing list, but I'm not able to use the reply I have had to solve my problem.

Now, if I want to start from zero and build spatialite with RTTOPO support (in Debian, Ubuntu, in a Linux system), is there a page like this with RTTOPO instructions?

Grazie

[a.fu...@lqt.it]

On Wed, 1 Nov 2017 15:30:51 +0100, andy wrote:
> I have tried to build spatialite with LWGEOM support in a Debian PC
>

Andrea,

I _STRONGLY_ discourage you from using LWGEOM, it's really awful.

if you are going to do a custom build of your own directly switching
to the most recent versions of librttopo, libspatialite, libsqlite3
and gdal will surely make your work easier and safer.

> error: "symbol lookup error: /usr/lib/libgdal.so.20: undefined
> symbol:
> sqlite3_column_table_name".
>

sqlite3_column_table_name() is a someway tainted API; it's usually
disabled on libsqlite3 canonical builds because it causes some
performance degradation.
if you absolutely need to enable this function you necessarily
have to build your own private libsqlite3 after configuring the
non-standard SQLITE_ENABLE_COLUMN_METADATA C-preprocessor symbol.

> Now, if I want to start from zero and build spatialite with RTTOPO
> support (in Debian, Ubuntu, in a Linux system), is there a page like

> this [2] with RTTOPO instructions?
>

there is no specific guide for Linux builds because there are too
many subtle differences depending on specific distributions.
just to say, building on Fedora or Debian isn't exactly the same.

you can anyway follow this:
http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

all right, it's specifically intended for Windows MinGW-64, but
it's fully based on standard gcc, automake, ./configure and make.
as a general rule you've just to keep on your mind that on Linux
your standard location would be "/usr/local/" instead of
"/mingw64/local", and you obviously have to ignore any manual
patch specifically intended for Windows.

bye Sandro

[Jukka Rahkonen]

a.fu...@lqt.it kirjoitti 2017-11-01 17:06:
> On Wed, 1 Nov 2017 15:30:51 +0100, andy wrote:

>
>> error: "symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol:
>> sqlite3_column_table_name".
>>
>
> sqlite3_column_table_name() is a someway tainted API; it's usually
> disabled on libsqlite3 canonical builds because it causes some
> performance degradation.
> if you absolutely need to enable this function you necessarily
> have to build your own private libsqlite3 after configuring the
> non-standard SQLITE_ENABLE_COLUMN_METADATA C-preprocessor symbol.
>

Hi,

GDAL can handle spatial indexes with views in GeoPackage if SQlite is
compiled with SQLITE_ENABLE_COLUMN_METADATA
http://www.gdal.org/drv_geopackage.html so it may be good to have it.

-Jukka Rahkonen-

[andy]

Ciao Alessandro,

On 1 November 2017 at 16:06, <a.fu...@lqt.it> wrote:

you can anyway follow this:
http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

than to build a spatialite with RTTOPO functions support from command line, I need to install these packages in this order:

1 libiconv

2 libz

7 libproj

9 libgeos

10 libexpat

11 FreeXL

12 READOSM

17 librttopo

18 libspatialite

19 spatialite-tools 

I will try!!

Thank you

[a.fu...@lqt.it]

On Wed, 1 Nov 2017 17:00:10 +0100, andy wrote:
> Ciao Alessandro,
>

> On 1 November 2017 at 16:06, wrote:
>
>> you can anyway follow this:

>> http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html [1]

>
> than to build a spatialite with RTTOPO functions support from command
> line, I need to install these packages in this order:
>
> 1 libiconv
>

libiconv is not available as a separate package on Linux; it's always
directly integrated into the platform/system run-time support.

> 2 libz
> 7 libproj
> 9 libgeos
> 10 libexpat
>

all these libraries are usually distributed as system packages;
there is no compelling reason to build them from sources.

possible exception: several distros (as e.g. Debian and Red Hat)
are typically _VERY_ conservative, and tend to distribute only
"well seasoned" versions (aka irremediably obsolete versions).
in some exceptional case rebuilding libproj and libgeos could
be required, but it's the exception rather than the rule.


> 11 FreeXL
> 12 READOSM
>

I personally use the standard system packages where available
(on Debian and Fedora for sure).


> 17 librttopo
>

you necessarily have to download the latest sources from the
git repository:

https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz

and you have to run "./autoconf.sh" before attempting to execute
./configure


> 18 libspatialite
> 19 spatialite-tools
>

hint: download the most recent sources from the Fossil repo

fossil clone https://www.gaia-gis.it/fossil/libspatialite
libspatialite.fossil
mkdir libspatialite
cd libspatialite
fossil open ../libspatialite.fossil
./configure --enable-rttopo=yes --enable-gcp=yes
make -j8
sudo make install-strip

the same is for spatialite-tools; just replace all
occurrences of "libspatialite" with "spatialite-tools"

have a good luck,
Sandro

[andy]

Ciao Sandro

I have this error: "configure: error: cannot find proj_api.h, bailing out".

I have already installed libproj. How to pass this check?

Thank you

[andy]

Ciao Sandro,

On 1 November 2017 at 17:32, <a.fu...@lqt.it> wrote:

On Wed, 1 Nov 2017 17:00:10 +0100, andy wrote:

https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz

and you have to run "./autoconf.sh" before attempting to execute
./configure

where can I find  the "./autoconf.sh" file?

Sorry for the stupid question.

Thank you

[mj10777]

On Thursday, 2 November 2017 13:18:34 UTC+1, Andrea Borruso wrote:

Ciao Sandro

On 1 November 2017 at 17:32, <a.fu...@lqt.it> wrote:

On Wed, 1 Nov 2017 17:00:10 +0100, andy wrote:

fossil clone https://www.gaia-gis.it/fossil/libspatialite libspatialite.fossil
mkdir libspatialite
cd libspatialite
fossil open ../libspatialite.fossil
./configure --enable-rttopo=yes --enable-gcp=yes

I have this error: "configure: error: cannot find proj_api.h, bailing out".

I have already installed libproj. How to pass this check?

Where have you installed proj4?

On a Linux-System it will normally be installed ín

- /usr/local

but will look for it in

- /usr or /usr/local

if not found you must tell configure where it is.

The same is true for other sub-projects like rttopo, sqlite3, freexl, which are checked later.

Mark

[a.fu...@lqt.it]

On Thu, 2 Nov 2017 13:17:50 +0100, andy wrote:
> I have this error: "configure: error: cannot find proj_api.h, bailing
> out".
>
> I have already installed libproj. How to pass this check?
>

Ciao Andrea,

library packages are usually split in two halves:
- the binary objects (static and dynamic libraries)
- the corresponding header files

the second component isn't strictly required in order
to execute the code, it's just required for building
other code depending on that library.
this is a rather advanced activity just interesting
developers alone, so the "development" packages are
never installed by default.
just a couple of practical examples (based on Debian8):

- libproj0 (standard binary package)
- libproj-dev (advanced developement package)
- libgeos-c1 (standard binary package)
- libgeos-dev (advanced developement package)

you simply have to install all required "*-dev" system
packages before building.

saluti,
Sandro

[a.fu...@lqt.it]

On Thu, 2 Nov 2017 13:36:51 +0100, andy wrote:
> Ciao Sandro,

>
>> https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz
>>
>> and you have to run "./autoconf.sh" before attempting to execute
>> ./configure
>
> where can I find  the "./autoconf.sh" file?
>

Andrea,

you'll find the "./autoconf.sh" script directly into the
sources tarball downloaded from git.

bye Sandro

[mj10777]

On Thursday, 2 November 2017 13:37:34 UTC+1, Andrea Borruso wrote:

Ciao Sandro,

On 1 November 2017 at 17:32, <a.fu...@lqt.it> wrote:

On Wed, 1 Nov 2017 17:00:10 +0100, andy wrote:

https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz

and you have to run "./autoconf.sh" before attempting to execute
./configure

where can I find  the "./autoconf.sh" file?

When you unpack the archive, it should be in the root directory. 

It may also be called 'autogen.sh' (on my copy and in git these is no  autoconf.sh)

Mark

[andy]

Ciao Sandro,

On 2 November 2017 at 13:42, <a.fu...@lqt.it> wrote:

you'll find the "./autoconf.sh" script directly into the
sources tarball downloaded from git.

I have found the autogen.sh file, but when I run it I have "Missing autoconf!" 

But I have autoconf already installed:

```

$ pacman -Ss autoconf

msys/autoconf 2.69-3 (base-devel) [installed]

    A GNU tool for automatically configuring source code

msys/autoconf-archive 2017.09.28-1

    Autoconf Macro Archive

msys/autoconf2.13 2.13-2 (base-devel) [installed]

    A GNU tool for automatically configuring source code

```

I think I must export some path variable, but I do not know which.

[mj10777]

On Thursday, 2 November 2017 14:06:12 UTC+1, Andrea Borruso wrote:

Ciao Sandro,

On 2 November 2017 at 13:42, <a.fu...@lqt.it> wrote:

you'll find the "./autoconf.sh" script directly into the
sources tarball downloaded from git.

I have found the autogen.sh file, but when I run it I have "Missing autoconf!" 

But I have autoconf already installed:

```

$ pacman -Ss autoconf

msys/autoconf 2.69-3 (base-devel) [installed]

    A GNU tool for automatically configuring source code

msys/autoconf-archive 2017.09.28-1

    Autoconf Macro Archive

msys/autoconf2.13 2.13-2 (base-devel) [installed]

    A GNU tool for automatically configuring source code

```

I think I must export some path variable, but I do not know which.

This is what I get when running ./autogen.sh'

./autogen.sh

* Running /usr/bin/libtoolize (2.4.2)

   OPTIONS = --force --copy

libtoolize: putting auxiliary files in `.'.

libtoolize: copying file `./ltmain.sh'

libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.

libtoolize: copying file `m4/libtool.m4'

libtoolize: copying file `m4/ltoptions.m4'

libtoolize: copying file `m4/ltsugar.m4'

libtoolize: copying file `m4/ltversion.m4'

libtoolize: copying file `m4/lt~obsolete.m4'

* Running /usr/bin/aclocal (1.14.1)

* Running /usr/local/bin/autoheader (2.69)

* Running /usr/bin/automake (1.14.1)

   OPTIONS = --add-missing --copy -Woverride

* Running /usr/local/bin/autoconf (2.69)

======================================

Now you are ready to run './configure'

To check you paths, to see if the needed tools are found try:

which autoconf

/usr/local/bin/autoconf

- if nothing is returned, add the path where where these tools are placed into your PATH

echo $PATH

will show you which directories 'which' will search in.

Mark

[a.fu...@lqt.it]

On Thu, 2 Nov 2017 14:05:29 +0100, andy wrote:
> $ pacman -Ss autoconf
> msys/autoconf 2.69-3 (base-devel) [installed]
>

Sorry Andrea,

have you perhaps suddenly switched from Linux to Windows/MSYS/MinGW ?

it would be surely better if you'll acquire first a fairly good
familiarity with civilized Linux before adventuring yourself into
the dangerous savage lands of lawless Far West.

(hint: try closing and reopening again your MSYS shell;
sometimes it resolves many odd issues on Windows).

bye Sandro

[andy]

Ciao Sandro,

On 2 November 2017 at 14:34, <a.fu...@lqt.it> wrote:

have you perhaps suddenly switched from Linux to Windows/MSYS/MinGW ?

it would be surely better if you'll acquire first a fairly good
familiarity with civilized Linux before adventuring yourself into
the dangerous savage lands of lawless Far West.

I have choosen to start from your great page http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

I need something like that because is really well written. Than in this moment I'm in Windows/MSYS/MinGW.

Two notes for that page:

- at the beginning there is a wrong URL in the "Please follow the instructions you can find here" sentence (in "here");

- when I built libspatialite, I have had a note about libxml2  dependency. If this is right, I should add it in libspatialite dependency list.

If I run all the commands of that page I have no problem to compile spatialite with rttopo.

But If I want to build an updated version, starting from https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz, I have the missing `autoconf` problem when I run `autogen.sh`.

If I run `which autoconf`, I have:

```

which: no autoconf in (/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

```

Than I have some problem :(

Thank you

 

[mj10777]

On Thursday, 2 November 2017 14:52:42 UTC+1, Andrea Borruso wrote:

Ciao Sandro,

On 2 November 2017 at 14:34, <a.fu...@lqt.it> wrote:

have you perhaps suddenly switched from Linux to Windows/MSYS/MinGW ?

it would be surely better if you'll acquire first a fairly good
familiarity with civilized Linux before adventuring yourself into
the dangerous savage lands of lawless Far West.

I have choosen to start from your great page http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

I need something like that because is really well written. Than in this moment I'm in Windows/MSYS/MinGW.

Two notes for that page:

- at the beginning there is a wrong URL in the "Please follow the instructions you can find here" sentence (in "here");

- when I built libspatialite, I have had a note about libxml2  dependency. If this is right, I should add it in libspatialite dependency list.

If I run all the commands of that page I have no problem to compile spatialite with rttopo.

But If I want to build an updated version, starting from https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz, I have the missing `autoconf` problem when I run `autogen.sh`.

If I run `which autoconf`, I have:

```

which: no autoconf in (/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

You must find where  **autoconf** was installed

- just as you must find where proj4 was installed

find /usr -iname autoconf

/usr/local/bin/autoconf

Note: here '/usr' means start at the directory '/usr' to search

You can also do:

find / -iname autoconf

which will search the whole disk.

You have a '/usr/local/bin:/usr/bin', this is where autoconf should be found

- and libproj4  should be in /usr/local/lib or /usr/lib

find / -iname 

libproj4*

should tell you that.

Mark

[andy]

Hi Mark,

thank you for your time

On 2 November 2017 at 15:23, 'mj10777' via SpatiaLite Users <spatiali...@googlegroups.com> wrote:

find /usr -iname autoconf

/usr/local/bin/autoconf

I have:

```

/home/andybandy/msys2/libiconv-1.15/libcharset/autoconf

/usr/share/autoconf

/usr/share/autoconf/autoconf

/usr/share/bash-completion/completions/autoconf

/usr/share/licenses/autoconf

```

Is `/usr/share/autoconf` the right one? I think no, because it's a folder.

Best regards

[a.fu...@lqt.it]

On Thu, 2 Nov 2017 14:51:58 +0100, andy wrote:
> If I run all the commands of that page I have no problem to compile
> spatialite with rttopo.
>

certainly yes; but this will use the bogus librttopo-1.0.0, that
is notoriously bug ridden and practically useless.
the current version available from the git repository resolves
many critical bugs.

note: if you are only interested into MakeValid and aren't
planning to use Topology at all using rtoopo 1.0.0 could
probably be a reasonable choice (if I remember well all
bugs specifically affected Topology).

> But If I want to build an updated version, starting from
> https://git.osgeo.org/gogs/rttopo/librttopo/archive/master.tar.gz

> [4],

> I have the missing `autoconf` problem when I run `autogen.sh`.
>
> If I run `which autoconf`, I have:
>
> ```
> which: no autoconf in
>
> (/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
>

this is the current $PATH supporting your MSYS shell;
all Linux-like binary executables will be loaded from
/ming64/bin, /usr/local/bin, /usr/bin and /bin

on my local MSYS-MinGW4 shell autoconf nicely works,
and "which autoconf" reports:
/usr/bin/autoconf

and " find / -name autoconf -print" reports:
/usr/bin/autoconf
/usr/share/autoconf
/usr/share/autoconf/autoconf
/usr/share/bash-completion/completions/autoconf
/usr/share/licenses/autoconf
/bin/autoconf

it seems that you have not properly installed
the autoconf package.

bye Sandro

[andy]

Caro Sandro,

On 2 November 2017 at 15:44, <a.fu...@lqt.it> wrote:

it seems that you have not properly installed
the autoconf package.

the right way to solve in my system was to run `pacman -Sy autoconf`.

Now I have autoconf!!

I'm restarting :)

Thank you, thank you, thank you

[andy]

Hi all,

On 1 November 2017 at 17:32, <a.fu...@lqt.it> wrote:

have a good luck,

I succeeded to build all, and it was not luck: it has been possible because you are skilled and very kind people.

I would like to give back something. Is this page in some git repo? If yes I would like to update it with some tips for lamer (like me), and I would like to do some pull request.

A last (I hope for you) question: if I build GDAL (using always mingw64_how_to page), will it be possible to run command like "ogr2ogr valid.shp input.shp -dialect sqlite -sql "select MakeValid(geometry) as geometry, * from input""

Thank you very much,

Andrea

[mj10777]

On Thursday, 2 November 2017 16:21:58 UTC+1, Andrea Borruso wrote:

Hi all,

On 1 November 2017 at 17:32, <a.fu...@lqt.it> wrote:

have a good luck,

I succeeded to build all, and it was not luck: it has been possible because you are skilled and very kind people.

I would like to give back something. Is this page in some git repo? If yes I would like to update it with some tips for lamer (like me), and I would like to do some pull request.

A last (I hope for you) question: if I build GDAL (using always mingw64_how_to page), will it be possible to run command like "ogr2ogr valid.shp input.shp -dialect sqlite -sql "select MakeValid(geometry) as geometry, * from input""

When you compile gdal, you must make sure that during ./configure of gdal finds the spatialite that you have installed.

- in most cases it will find it itsself, but you can also add like this

./configure  \

--prefix=/usr/local \

--with-sqlite3=/usr/local \

--with-spatialite=/usr/local \

--with-static-proj4=/usr/local \

--with-geos=/usr/local/bin/geos-config

when the spatialite has been properly found, gdal when calling the libspatialite, should find the needed librttopo.

Mark

[a.fu...@lqt.it]

On Thu, 2 Nov 2017 16:21:15 +0100, andy wrote:
> I would like to give back something. Is this page [1] in some git

> repo? If yes I would like to update it with some tips for lamer (like
> me), and I would like to do some pull request.
>

> [1] http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html
>

Andrea,

it's just a stupid standalone HTML file of about 64 KB, you
can easily download it by calling:

wget http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html

edit your local copy so to add all your integrations,
then semd me the final outcome and I'll be glad to
incorporate your contributions into the "official"
WEB page.

bye Sabdri

[andy]

Hi Mark,

than for my environment, I have used

```

export "CPPLAGS=-I/mingw64/local/include"

export "LDFLAGS=-L/mingw64/local/lib"

./configure  \

--prefix=/mingw64/local \

--with-sqlite3=/mingw64/local \

--with-spatialite=/mingw64/local \

--with-static-proj4=/mingw64/local \

--with-geos=/mingw64/local/bin/geos-config \

--with-liblzma=/mingw64/local  --with-webp=/mingw64/local

```

It seems to work (I'm building now).

Thank you

[andy]

Hi,

On 3 November 2017 at 10:55, andy <abor...@gmail.com> wrote:

```

export "CPPLAGS=-I/mingw64/local/include"

export "LDFLAGS=-L/mingw64/local/lib"

./configure  \

--prefix=/mingw64/local \

--with-sqlite3=/mingw64/local \

--with-spatialite=/mingw64/local \

--with-static-proj4=/mingw64/local \

--with-geos=/mingw64/local/bin/geos-config \

--with-liblzma=/mingw64/local  --with-webp=/mingw64/local

```

I have done make, and it seems I have no error. The last rows are:

echo 'CONFIG_VERSION='`cat ./VERSION`'' >> gdal.pc
echo 'CONFIG_INST_PREFIX=/mingw64/local' >> gdal.pc
echo 'CONFIG_INST_LIBS=-L/mingw64/local/lib -lgdal' >> gdal.pc
echo 'CONFIG_INST_CFLAGS=-I/mingw64/local/include' >> gdal.pc
echo 'CONFIG_INST_DATA=/mingw64/local/share/gdal/data' >> gdal.pc
cat gdal.pc.in >> gdal.pc

But when I run make install-strip, I have make: *** No rule to make target "install-strip".

How to solve it?

Thank you

​

[mj10777]

On Friday, 3 November 2017 12:36:29 UTC+1, Andrea Borruso wrote:

Hi,

On 3 November 2017 at 10:55, andy <abor...@gmail.com> wrote:

```

export "CPPLAGS=-I/mingw64/local/include"

export "LDFLAGS=-L/mingw64/local/lib"

./configure  \

--prefix=/mingw64/local \

--with-sqlite3=/mingw64/local \

--with-spatialite=/mingw64/local \

--with-static-proj4=/mingw64/local \

--with-geos=/mingw64/local/bin/geos-config \

--with-liblzma=/mingw64/local  --with-webp=/mingw64/local

```

I have done make, and it seems I have no error. The last rows are:

echo 'CONFIG_VERSION='`cat ./VERSION`'' >> gdal.pc
echo 'CONFIG_INST_PREFIX=/mingw64/local' >> gdal.pc
echo 'CONFIG_INST_LIBS=-L/mingw64/local/lib -lgdal' >> gdal.pc
echo 'CONFIG_INST_CFLAGS=-I/mingw64/local/include' >> gdal.pc
echo 'CONFIG_INST_DATA=/mingw64/local/share/gdal/data' >> gdal.pc
cat gdal.pc.in >> gdal.pc

But when I run make install-strip, I have make: *** No rule to make target "install-strip".

How to solve it?

try

make install

Mark
 

[andy]

GDAL/OGR works with RTTOPO!!!

RTTOPO warning: Ring Self-intersection at or near point 528108.51558918029 4571486.8073004419
RTTOPO warning: Ring Self-intersection at or near point 1177064.5067999677 4571209.1925928816
RTTOPO warning: Ring Self-intersection at or near point 1154968.4279781275 4561653.8165247878
...

Thank you very much

​

[gritibaenz]

Hello all,

actually I like spatialite a lot and I am mainly using spatialite_gui for my work related to qgis. Due to this thread and the page http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html I was motivated to try to build as well a "new/actual version of at least spatialite_gui".
Since I'm no software developper, it is quite hard to follow the steps and solve difficulties.

For example:

• shall I use all the named downloads in the how-to file or using rhe fossil repos?
• integration of openjpeg-2.3.0 which compiles but later on other parts/pakets are looking for version 2.0 / 2.1
• ...

therefor I like the idea of Andrea to include experiences which probably could help.

BTW: any idea when an offical new spatialite_gui windows executable can be expected?

thanks a lot, bye
Adrian

Anyway thanks for the excellent software the documentation ...

[a.fu...@lqt.it]

On Sun, 5 Nov 2017 10:21:53 -0800 (PST), gritibaenz wrote:
> Hello all,
>
> actually I like spatialite a lot and I am mainly using spatialite_gui
> for my work related to qgis. Due to this thread and the page

> http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html [3] I was

> motivated to try to build as well a "new/actual version of at least
> spatialite_gui".
> Since I'm no software developper, it is quite hard to follow the
> steps
> and solve difficulties.
>
> For example:
>

> * shall I use all the named downloads in the how-to file or using
> rhe
> fossil repos?
>

it depends. both solutions are reasonable, but have completely
different scopes.

- using the source tarballs (the choice supported by the How-To guide);
for sure this will create "seasoned" executables lacking all very
recent changes and upgrades, but your binary code will presumably
be reasonably stable and affordable.
when a release (or even a release candidate) is make available this
surely means that it has successfully passed a thorough and extensive
testing on several different platforms.

- using the latest sources from the Fossil repo; this will create
*experimental* executables possibly still suffering from several
undetected bugs and other instabilities.
to be always used with a pinch of salt and only for testing purposes;
you must be well aware that such executables could be unstable and
buggy "by definition" ... use them at your risk.


> * integration of openjpeg-2.3.0 which compiles but later on other

> parts/pakets are looking for version 2.0 / 2.1

> * ...
>

RasterLite2 is currently passing a rather complex re-engineering;
properly supporting openjpeg-2.3.0 is part of the problem.
Unhappily in the next weeks I'll be probably unable to work
on RasterLite2 for personal reasons, so you'll be patient for
another while ;-)

>
> therefor I like the idea of Andrea to include experiences which
> probably could help.
>

I fully agree, it surely is a good idea.

> BTW: any idea when an offical new spatialite_gui windows executable
> can be expected?
>

immediately after completing the development cycle of both
libspatialite-4.5.0 and librasterlite-1.1.0 :-D

bye Sandro

[andy]

Hi Adrian,

On 5 November 2017 at 19:21, gritibaenz <mat...@abmaco.info> wrote:

Since I'm no software developper, it is quite hard to follow the steps and solve difficulties.

I'm not a developer too :)

I have create a copy of the great Sandro documentation, and than I made changes (very few).

My goal was to build spatialite (not spatialiteGui), using the most updated spatialite source code, with rttopo support, and to build also the last GDAL with spatialite support.

This is my version: http://bl.ocks.org/aborruso/raw/ba04d8cdf65cc5203e830c54f3714a5f/

This are the differences with the original one https://gitlab.com/aborruso/MinGW_Gaia-SINS_build_instructions/commit/f443292a5510b49c339cd8971e6c8ca125f775fb

bye

 

[gritibaenz]

Hello Sandro, Hello Andrea,

thanks a lot to both of you. I'll give it a try later on. Your answers gave some more inputs on how to decide which pieces (seasoned or latest) to use and how to implement the things out of fossil.

my best personal regards,
Adrian