[GRASS-dev] r.out.gdal and Rasterlite driver

Hello,
following a previous post on the users ML[1], I am planning to open a
new ticket concerning an issue I met trying to export raster maps to a
spatialite database. It looks like the output raster table lacks a
correct reference to the srid it should be linked to, i.e. in the
geometry_column table, srid equals -1 for the newly written raster
table.

Would anyone mind having a try running r.out.gdal with his/her data to
check if the problem is due to my configuration or actually a bug in the
command ?

Thank you,
Vincent.

[1]https://lists.osgeo.org/pipermail/grass-user/2016-October/075413.html

Vincent Bain wrote

Hello,
following a previous post on the users ML[1], I am planning to open a
new ticket concerning an issue I met trying to export raster maps to a
spatialite database. It looks like the output raster table lacks a
correct reference to the srid it should be linked to, i.e. in the
geometry_column table, srid equals -1 for the newly written raster
table.

Would anyone mind having a try running r.out.gdal with his/her data to
check if the problem is due to my configuration or actually a bug in the
command ?

Thank you,
Vincent.

[1]https://lists.osgeo.org/pipermail/grass-user/2016-October/075413.html

_______________________________________________
grass-dev mailing list

grass-dev@.osgeo

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

Tested here with the NC sample data set and grass trunk on windows and
linux.

missing srs confirmed.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-out-gdal-and-Rasterlite-driver-tp5292212p5292236.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

Thank you Helmut,
I open a ticket.

V.

Le lundi 24 octobre 2016 à 01:44 -0700, Helmut Kudrnovsky a écrit :

Vincent Bain wrote
> Hello,
> following a previous post on the users ML[1], I am planning to open a
> new ticket concerning an issue I met trying to export raster maps to a
> spatialite database. It looks like the output raster table lacks a
> correct reference to the srid it should be linked to, i.e. in the
> geometry_column table, srid equals -1 for the newly written raster
> table.
>
> Would anyone mind having a try running r.out.gdal with his/her data to
> check if the problem is due to my configuration or actually a bug in the
> command ?
>
>
> Thank you,
> Vincent.
>
> [1]https://lists.osgeo.org/pipermail/grass-user/2016-October/075413.html
>
> _______________________________________________
> grass-dev mailing list

> grass-dev@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

Tested here with the NC sample data set and grass trunk on windows and
linux.

missing srs confirmed.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-out-gdal-and-Rasterlite-driver-tp5292212p5292236.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Mon, Oct 24, 2016 at 11:05 AM, Vincent Bain <bain@toraval.fr> wrote:

Thank you Helmut,
I open a ticket.

Might that not be rather a GDAL issue? To my knowledge we do not any
special treatment in r.out.gdal but let rather GDAL do the job.

<uninformed guess>
If, say, an export to GeoTIFF is fine but Rasterlite is not it looks
like a GDAL related thing to me.
</uninformed guess>

Markus

Markus Neteler wrote

On Mon, Oct 24, 2016 at 11:05 AM, Vincent Bain &lt;

bain@

&gt; wrote:

Thank you Helmut,
I open a ticket.

Might that not be rather a GDAL issue? To my knowledge we do not any
special treatment in r.out.gdal but let rather GDAL do the job.
<uninformed guess>
If, say, an export to GeoTIFF is fine but Rasterlite is not it looks
like a GDAL related thing to me.
</uninformed guess>

yes it seems so, see https://trac.osgeo.org/grass/ticket/3191#comment:1

any idea if e.g. -a_srs EPSG:12345 works with a r.out.gdal createopt?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-out-gdal-and-Rasterlite-driver-tp5292212p5292292.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

Unfortunately this is not a valid lco...

OK, it is not really a critical issue as we can easily solve it whether
via gdal_translate or via a simple sql update, but to me it sounds a bit
weird for a GRASS user who does not care for gdal in the background...

V.

Le lundi 24 octobre 2016 à 04:59 -0700, Helmut Kudrnovsky a écrit :

-a_srs EPSG:12345

W dniu 24.10.2016 o 14:06, Vincent Bain pisze:

Unfortunately this is not a valid lco...

OK, it is not really a critical issue as we can easily solve it whether
via gdal_translate or via a simple sql update,

Maybe `gdal_edit.py -a_srs' will be the simplest workaround?

Maciek

--
Maciej Sieczka
http://www.sieczka.org

Hi Maciek,

thanks for your suggestion. In fact, the script runs without error or
warning but it does not change anything :

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]
        
        gdal_edit.py -a_srs EPSG:12345 \
        Rasterlite:my_db.sqlite,table=my_raster
        
        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

Anyway, on the spatialite> prompt it's a matter of seconds...

Bye,
Vincent.

Le mardi 25 octobre 2016 à 11:39 +0200, Maciej Sieczka a écrit :

W dniu 24.10.2016 o 14:06, Vincent Bain pisze:
> Unfortunately this is not a valid lco...
>
> OK, it is not really a critical issue as we can easily solve it whether
> via gdal_translate or via a simple sql update,

Maybe `gdal_edit.py -a_srs' will be the simplest workaround?

Maciek

Le mardi 25 octobre 2016 12:02:01, Vincent Bain a écrit :

Hi Maciek,

thanks for your suggestion. In fact, the script runs without error or
warning but it does not change anything :

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

        gdal_edit.py -a_srs EPSG:12345 \
        Rasterlite:my_db.sqlite,table=my_raster

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

Yes, the SetProjection() method needed to change the SRS on an existing
dataset isn't implemented in the GDAL Rasterlite driver.

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

W dniu 25.10.2016 o 12:02, Vincent Bain pisze:

thanks for your suggestion. In fact, the script runs without error or
warning but it does not change anything :

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

        gdal_edit.py -a_srs EPSG:12345 \
        Rasterlite:my_db.sqlite,table=my_raster

What is EPSG:12345? This doesn't look like a common EPSG SRID. If you
want to use it with GDAL, you would need to make sure it's defined in
GDAL support files.

From https://trac.osgeo.org/grass/ticket/3191#comment:1 it looks like
you are after EPSG:31255 actually. Does this one work with gdal_edit.py?

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

Anyway, on the spatialite> prompt it's a matter of seconds...

Le mardi 25 octobre 2016 à 11:39 +0200, Maciej Sieczka a écrit :

W dniu 24.10.2016 o 14:06, Vincent Bain pisze:

Unfortunately this is not a valid lco...

OK, it is not really a critical issue as we can easily solve it whether
via gdal_translate or via a simple sql update,

Maybe `gdal_edit.py -a_srs' will be the simplest workaround?

no, no : it was just an imaginary srid for the example.
V.

Le mardi 25 octobre 2016 à 12:15 +0200, Maciej Sieczka a écrit :

W dniu 25.10.2016 o 12:02, Vincent Bain pisze:
> thanks for your suggestion. In fact, the script runs without error or
> warning but it does not change anything :
>
> gdalinfo Rasterlite:my_db.sqlite,table=my_raster
> [...]
> AUTHORITY["EPSG","54321"]]
> [...]
>
> gdal_edit.py -a_srs EPSG:12345 \
> Rasterlite:my_db.sqlite,table=my_raster

What is EPSG:12345? This doesn't look like a common EPSG SRID. If you
want to use it with GDAL, you would need to make sure it's defined in
GDAL support files.

From https://trac.osgeo.org/grass/ticket/3191#comment:1 it looks like
you are after EPSG:31255 actually. Does this one work with gdal_edit.py?

> gdalinfo Rasterlite:my_db.sqlite,table=my_raster
> [...]
> AUTHORITY["EPSG","54321"]]
> [...]
>
> Anyway, on the spatialite> prompt it's a matter of seconds...
>
> Le mardi 25 octobre 2016 à 11:39 +0200, Maciej Sieczka a écrit :
>> W dniu 24.10.2016 o 14:06, Vincent Bain pisze:
>>> Unfortunately this is not a valid lco...
>>>
>>> OK, it is not really a critical issue as we can easily solve it whether
>>> via gdal_translate or via a simple sql update,
>>
>> Maybe `gdal_edit.py -a_srs' will be the simplest workaround?

W dniu 25.10.2016 o 12:08, Even Rouault pisze:

Le mardi 25 octobre 2016 12:02:01, Vincent Bain a écrit :

Hi Maciek,

thanks for your suggestion. In fact, the script runs without error or
warning but it does not change anything :

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

        gdal_edit.py -a_srs EPSG:12345 \
        Rasterlite:my_db.sqlite,table=my_raster

        gdalinfo Rasterlite:my_db.sqlite,table=my_raster
        [...]
            AUTHORITY["EPSG","54321"]]
        [...]

Yes, the SetProjection() method needed to change the SRS on an existing
dataset isn't implemented in the GDAL Rasterlite driver.

Now I get it. Thanks.

Maciek

--
Maciej Sieczka
http://www.sieczka.org