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 ?
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 ?
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
On Mon, Oct 24, 2016 at 11:05 AM, Vincent Bain <
bain@
> 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>
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 :
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?
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.
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.
> 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?