rgrass7 - SQLite and GML drivers not working for readVECT

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Veronica Andreo
Dear Roger, MarkusM and all

Thank you very much for such quick answers and solutions! I cannot tell which would be the best solution, but I tested the one already in r-forge and readVECT works again with SQLite and GML :)

Thanks again to everybody!
Vero

2017-10-11 14:10 GMT+02:00 Markus Metz <[hidden email]>:
Dear Roger,

On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]> wrote:
>
> New version submitted to CRAN; until then:
>
> install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>
> should pick up the latest version; #3425 closed. Please report back whether this works ... (conditioning on GRASS version to create comparable driver name strings).

I don't think there is a need to condition on the GRASS version, see my suggestion in #3425

Markus M
>

> Roger
>
>
> On Wed, 11 Oct 2017, Roger Bivand wrote:
>
>> Thanks for trying to contribute. The GH site is not the rgrass7 development site - that is SVN on R-forge (GH is a very preliminary trial site for using sf vector representation in R, and maybe raster raster representation (or forthcoming stars), instead of sp classes).
>>
>> GRAS 7.2.2 works OK with the current logic checks; I can reproduce the issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there is no such change. Could the GRASS developer responsible for this obvious regression provide an additional flag in v.in.ogr (and v.external, v.out.ogr) to permit backwards compatibility? See line 387, needs to change
>>
>> #if GDAL_VERSION_NUM >= 2000000
>>
>> to add a !backwards_compatible test too.
>>
>> I'll hold off trying to fix this in rgrass7 because it is a regression. I can add the backwards_compatibility=TRUE flag to readVECT() once it is exposed.
>>
>> This is:
>>
>> https://trac.osgeo.org/grass/ticket/3425
>>
>> Roger
>>
>> On Tue, 10 Oct 2017, Ahmadou Dicko wrote:
>>
>>> In the readVECT function, internally v.in.ogr is used to list the supported
>>> vector format and it is compared the format available using rgdal (or sf).
>>> However, using v.external instead of v.in.ogr fix this single problem
>>> because of the way the output is different (in form).
>>> For example, if you use v.in.ogr you will have to compare
>>
>> SQLite_/_Spatialite
>>>
>>> (GRASS) to SQLite (R) and they are not the same.
>>>
>>> I tried to send a PR, let me know if it works
>>>
>>> https://github.com/rsbivand/rgrass7/pull/1
>>>
>>> Best,
>>>
>>> On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]> wrote:
>>>
>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>> Von: "Ahmadou Dicko" <[hidden email]>
>>>>> An: "Helmut Kudrnovsky" <[hidden email]>
>>>>> Cc: "Roger Bivand" <[hidden email]>, "[hidden email]" <
>>>>
>>>> [hidden email]>
>>>>>
>>>>> Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not working
>>>>
>>>> for readVECT
>>>>>
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I think that using v.external -f (instead of v.in.ogr -f) can fix this
>>>>
>>>> issue (didn't try yet)
>>>>>
>>>>>
>>>>>
>>>>> execGRASS("v.external", flags = "f", intern = TRUE)
>>>>> [1] "ARCGEN"         "AVCBin"         "AVCE00"
>>>>> [4] "AeronavFAA"     "AmigoCloud"     "BNA"
>>>>> [7] "CAD"            "CSV"            "CSW"
>>>>> [10] "Carto"          "Cloudant"       "CouchDB"
>>>>> [13] "DGN"            "DXF"            "EDIGEO"
>>>>> [16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
>>>>> [19] "GML"            "GPKG"           "GPSBabel"
>>>>> [22] "GPSTrackMaker"  "GPX"            "GeoJSON"
>>>>> [25] "GeoRSS"         "Geoconcept"     "Geomedia"
>>>>> [28] "HTF"            "HTTP"           "Idrisi"
>>>>> [31] "JML"            "JPEG2000"       "KML"
>>>>> [34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
>>>>> [37] "MySQL"          "ODBC"           "ODS"
>>>>> [40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
>>>>> [43] "OGR_SDTS"       "OGR_VRT"        "OSM"
>>>>> [46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
>>>>> [49] "PDF"            "PGDUMP"         "PGeo"
>>>>> [52] "PLSCENES"       "PostgreSQL"     "REC"
>>>>
>>>>
>>>> in a quick check, there is no difference in available formats.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: <a href="tel:+47%2055%2095%2093%2055" value="+4755959355" target="_blank">+47 55 95 93 55; e-mail: [hidden email]
> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> _______________________________________________
> grass-stats mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/grass-stats


_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats


_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Markus Metz-3
In reply to this post by Roger Bivand
Dear Roger,

On Wed, Oct 11, 2017 at 2:36 PM, Roger Bivand <[hidden email]> wrote:
>
> Dear Markus,
>
> I can't see how to get the same strings out without conditioning,

with

ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"), "[", 1)))

> because for v.in.ogr -f and GDAL >= 2.0, GRASS < 7.3 presents for example:
>
> GML (rw): GML
> SQLite (rw): SQLite
> ESRI Shapefile (rw): ESRI Shapefile
> GeoJSON (rw): GeoJSON
>
> (readOGR used the string following ":" )

The structure of the output of r.in.gdal -f and v.in.ogr -f is

 <short name> (<read/write flags>): <description>

readOGR must use the string preceding "(". Anything following ":" is a description which can change any time. Before GDAL 2.0, there was nothing else but the short name for OGR drivers, therefore the short name was used as description.

>
> and >= 7.3:
>
> GML (rw+): Geography Markup Language (GML)
> SQLite (rw+): SQLite / Spatialite
> ESRI Shapefile (rw+): ESRI Shapefile
> GeoJSON (rw+): GeoJSON
>
> where the string after ":" is different.

the string before the read/write flags, i.e. before "(" is identical.

> If we can depend on all GRASS < 7.3 having the same short name position, yes, I could avoid conditioning by changing the string processing to suit >= 7.3 and apply it to all previous; I chose not to modify the string processing for < 7.3 to avoid any problems I can't readily check.

For all versions of GRASS 7 and all versions of GDAL, the short name position has been and continues to be the first position. For v.in.ogr -f, the short name may also appear after ":", but only if there is no long name.

Best regards,

Markus

>

> Best wishes,
>
> Roger
>
>
> On Wed, 11 Oct 2017, Markus Metz wrote:
>
>> Dear Roger,
>>
>> On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]> wrote:
>>>
>>>
>>> New version submitted to CRAN; until then:
>>>
>>> install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>>>
>>> should pick up the latest version; #3425 closed. Please report back
>>
>> whether this works ... (conditioning on GRASS version to create comparable
>> driver name strings).
>>
>> I don't think there is a need to condition on the GRASS version, see my
>> suggestion in #3425
>>
>> Markus M
>>>
>>>
>>> Roger
>>>
>>>
>>> On Wed, 11 Oct 2017, Roger Bivand wrote:
>>>
>>>> Thanks for trying to contribute. The GH site is not the rgrass7
>>
>> development site - that is SVN on R-forge (GH is a very preliminary trial
>> site for using sf vector representation in R, and maybe raster raster
>> representation (or forthcoming stars), instead of sp classes).
>>>>
>>>>
>>>> GRAS 7.2.2 works OK with the current logic checks; I can reproduce the
>>
>> issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c
>> returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there is no
>> such change. Could the GRASS developer responsible for this obvious
>> regression provide an additional flag in v.in.ogr (and v.external,
>> v.out.ogr) to permit backwards compatibility? See line 387, needs to change
>>>>
>>>>
>>>> #if GDAL_VERSION_NUM >= 2000000
>>>>
>>>> to add a !backwards_compatible test too.
>>>>
>>>> I'll hold off trying to fix this in rgrass7 because it is a regression.
>>
>> I can add the backwards_compatibility=TRUE flag to readVECT() once it is
>> exposed.
>>>>
>>>>
>>>> This is:
>>>>
>>>> https://trac.osgeo.org/grass/ticket/3425
>>>>
>>>> Roger
>>>>
>>>> On Tue, 10 Oct 2017, Ahmadou Dicko wrote:
>>>>
>>>>> In the readVECT function, internally v.in.ogr is used to list the
>>
>> supported
>>>>>
>>>>> vector format and it is compared the format available using rgdal (or
>>
>> sf).
>>>>>
>>>>> However, using v.external instead of v.in.ogr fix this single problem
>>>>> because of the way the output is different (in form).
>>>>> For example, if you use v.in.ogr you will have to compare
>>>>
>>>>
>>>> SQLite_/_Spatialite
>>>>>
>>>>>
>>>>> (GRASS) to SQLite (R) and they are not the same.
>>>>>
>>>>> I tried to send a PR, let me know if it works
>>>>>
>>>>> https://github.com/rsbivand/rgrass7/pull/1
>>>>>
>>>>> Best,
>>>>>
>>>>> On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]>
>>
>> wrote:
>>>>>
>>>>>
>>>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>>>> Von: "Ahmadou Dicko" <[hidden email]>
>>>>>>> An: "Helmut Kudrnovsky" <[hidden email]>
>>>>>>> Cc: "Roger Bivand" <[hidden email]>, "[hidden email]"
>>
>> <
>>>>>>
>>>>>>
>>>>>> [hidden email]>
>>>>>>>
>>>>>>>
>>>>>>> Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not
>>
>> working
>>>>>>
>>>>>>
>>>>>> for readVECT
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I think that using v.external -f (instead of v.in.ogr -f) can fix this
>>>>>>
>>>>>>
>>>>>> issue (didn't try yet)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> execGRASS("v.external", flags = "f", intern = TRUE)
>>>>>>> [1] "ARCGEN"         "AVCBin"         "AVCE00"
>>>>>>> [4] "AeronavFAA"     "AmigoCloud"     "BNA"
>>>>>>> [7] "CAD"            "CSV"            "CSW"
>>>>>>> [10] "Carto"          "Cloudant"       "CouchDB"
>>>>>>> [13] "DGN"            "DXF"            "EDIGEO"
>>>>>>> [16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
>>>>>>> [19] "GML"            "GPKG"           "GPSBabel"
>>>>>>> [22] "GPSTrackMaker"  "GPX"            "GeoJSON"
>>>>>>> [25] "GeoRSS"         "Geoconcept"     "Geomedia"
>>>>>>> [28] "HTF"            "HTTP"           "Idrisi"
>>>>>>> [31] "JML"            "JPEG2000"       "KML"
>>>>>>> [34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
>>>>>>> [37] "MySQL"          "ODBC"           "ODS"
>>>>>>> [40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
>>>>>>> [43] "OGR_SDTS"       "OGR_VRT"        "OSM"
>>>>>>> [46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
>>>>>>> [49] "PDF"            "PGDUMP"         "PGeo"
>>>>>>> [52] "PLSCENES"       "PostgreSQL"     "REC"
>>>>>>
>>>>>>
>>>>>>
>>>>>> in a quick check, there is no difference in available formats.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Roger Bivand
>>> Department of Economics, Norwegian School of Economics,
>>> Helleveien 30, N-5045 Bergen, Norway.
>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
>>> http://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>> _______________________________________________
>>> grass-stats mailing list
>>> [hidden email]
>>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>>
>>
>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: [hidden email]
> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Roger Bivand
OK, thanks, will revise at next release.

Roger

On Wed, 11 Oct 2017, Markus Metz wrote:

> Dear Roger,
>
> On Wed, Oct 11, 2017 at 2:36 PM, Roger Bivand <[hidden email]> wrote:
>>
>> Dear Markus,
>>
>> I can't see how to get the same strings out without conditioning,
>
> with
>
> ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"),
> "[", 1)))
>
>> because for v.in.ogr -f and GDAL >= 2.0, GRASS < 7.3 presents for example:
>>
>> GML (rw): GML
>> SQLite (rw): SQLite
>> ESRI Shapefile (rw): ESRI Shapefile
>> GeoJSON (rw): GeoJSON
>>
>> (readOGR used the string following ":" )
>
> The structure of the output of r.in.gdal -f and v.in.ogr -f is
>
> <short name> (<read/write flags>): <description>
>
> readOGR must use the string preceding "(". Anything following ":" is a
> description which can change any time. Before GDAL 2.0, there was nothing
> else but the short name for OGR drivers, therefore the short name was used
> as description.
>
>>
>> and >= 7.3:
>>
>> GML (rw+): Geography Markup Language (GML)
>> SQLite (rw+): SQLite / Spatialite
>> ESRI Shapefile (rw+): ESRI Shapefile
>> GeoJSON (rw+): GeoJSON
>>
>> where the string after ":" is different.
>
> the string before the read/write flags, i.e. before "(" is identical.
>
>> If we can depend on all GRASS < 7.3 having the same short name position,
> yes, I could avoid conditioning by changing the string processing to suit
>> = 7.3 and apply it to all previous; I chose not to modify the string
> processing for < 7.3 to avoid any problems I can't readily check.
>
> For all versions of GRASS 7 and all versions of GDAL, the short name
> position has been and continues to be the first position. For v.in.ogr -f,
> the short name may also appear after ":", but only if there is no long name.
>
> Best regards,
>
> Markus
>
>>
>> Best wishes,
>>
>> Roger
>>
>>
>> On Wed, 11 Oct 2017, Markus Metz wrote:
>>
>>> Dear Roger,
>>>
>>> On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]>
> wrote:
>>>>
>>>>
>>>> New version submitted to CRAN; until then:
>>>>
>>>> install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>>>>
>>>> should pick up the latest version; #3425 closed. Please report back
>>>
>>> whether this works ... (conditioning on GRASS version to create
> comparable
>>> driver name strings).
>>>
>>> I don't think there is a need to condition on the GRASS version, see my
>>> suggestion in #3425
>>>
>>> Markus M
>>>>
>>>>
>>>> Roger
>>>>
>>>>
>>>> On Wed, 11 Oct 2017, Roger Bivand wrote:
>>>>
>>>>> Thanks for trying to contribute. The GH site is not the rgrass7
>>>
>>> development site - that is SVN on R-forge (GH is a very preliminary trial
>>> site for using sf vector representation in R, and maybe raster raster
>>> representation (or forthcoming stars), instead of sp classes).
>>>>>
>>>>>
>>>>> GRAS 7.2.2 works OK with the current logic checks; I can reproduce the
>>>
>>> issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c
>>> returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there is no
>>> such change. Could the GRASS developer responsible for this obvious
>>> regression provide an additional flag in v.in.ogr (and v.external,
>>> v.out.ogr) to permit backwards compatibility? See line 387, needs to
> change
>>>>>
>>>>>
>>>>> #if GDAL_VERSION_NUM >= 2000000
>>>>>
>>>>> to add a !backwards_compatible test too.
>>>>>
>>>>> I'll hold off trying to fix this in rgrass7 because it is a regression.
>>>
>>> I can add the backwards_compatibility=TRUE flag to readVECT() once it is
>>> exposed.
>>>>>
>>>>>
>>>>> This is:
>>>>>
>>>>> https://trac.osgeo.org/grass/ticket/3425
>>>>>
>>>>> Roger
>>>>>
>>>>> On Tue, 10 Oct 2017, Ahmadou Dicko wrote:
>>>>>
>>>>>> In the readVECT function, internally v.in.ogr is used to list the
>>>
>>> supported
>>>>>>
>>>>>> vector format and it is compared the format available using rgdal (or
>>>
>>> sf).
>>>>>>
>>>>>> However, using v.external instead of v.in.ogr fix this single problem
>>>>>> because of the way the output is different (in form).
>>>>>> For example, if you use v.in.ogr you will have to compare
>>>>>
>>>>>
>>>>> SQLite_/_Spatialite
>>>>>>
>>>>>>
>>>>>> (GRASS) to SQLite (R) and they are not the same.
>>>>>>
>>>>>> I tried to send a PR, let me know if it works
>>>>>>
>>>>>> https://github.com/rsbivand/rgrass7/pull/1
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]>
>>>
>>> wrote:
>>>>>>
>>>>>>
>>>>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>>>>> Von: "Ahmadou Dicko" <[hidden email]>
>>>>>>>> An: "Helmut Kudrnovsky" <[hidden email]>
>>>>>>>> Cc: "Roger Bivand" <[hidden email]>, "
> [hidden email]"
>>>
>>> <
>>>>>>>
>>>>>>>
>>>>>>> [hidden email]>
>>>>>>>>
>>>>>>>>
>>>>>>>> Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not
>>>
>>> working
>>>>>>>
>>>>>>>
>>>>>>> for readVECT
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> I think that using v.external -f (instead of v.in.ogr -f) can fix
> this
>>>>>>>
>>>>>>>
>>>>>>> issue (didn't try yet)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> execGRASS("v.external", flags = "f", intern = TRUE)
>>>>>>>> [1] "ARCGEN"         "AVCBin"         "AVCE00"
>>>>>>>> [4] "AeronavFAA"     "AmigoCloud"     "BNA"
>>>>>>>> [7] "CAD"            "CSV"            "CSW"
>>>>>>>> [10] "Carto"          "Cloudant"       "CouchDB"
>>>>>>>> [13] "DGN"            "DXF"            "EDIGEO"
>>>>>>>> [16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
>>>>>>>> [19] "GML"            "GPKG"           "GPSBabel"
>>>>>>>> [22] "GPSTrackMaker"  "GPX"            "GeoJSON"
>>>>>>>> [25] "GeoRSS"         "Geoconcept"     "Geomedia"
>>>>>>>> [28] "HTF"            "HTTP"           "Idrisi"
>>>>>>>> [31] "JML"            "JPEG2000"       "KML"
>>>>>>>> [34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
>>>>>>>> [37] "MySQL"          "ODBC"           "ODS"
>>>>>>>> [40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
>>>>>>>> [43] "OGR_SDTS"       "OGR_VRT"        "OSM"
>>>>>>>> [46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
>>>>>>>> [49] "PDF"            "PGDUMP"         "PGeo"
>>>>>>>> [52] "PLSCENES"       "PostgreSQL"     "REC"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> in a quick check, there is no difference in available formats.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Roger Bivand
>>>> Department of Economics, Norwegian School of Economics,
>>>> Helleveien 30, N-5045 Bergen, Norway.
>>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>>> Editor-in-Chief of The R Journal,
> https://journal.r-project.org/index.html
>>>> http://orcid.org/0000-0003-2392-6140
>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>> _______________________________________________
>>>> grass-stats mailing list
>>>> [hidden email]
>>>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>>>
>>>
>>
>> --
>> Roger Bivand
>> Department of Economics, Norwegian School of Economics,
>> Helleveien 30, N-5045 Bergen, Norway.
>> voice: +47 55 95 93 55; e-mail: [hidden email]
>> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
>> http://orcid.org/0000-0003-2392-6140
>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Veronica Andreo
Hello again,

I come back to this thread beacuse the issue was solved for readVECT, but I now realize (when trying to write vectors back into GRASS after some processing in R) that writeVECT shows the same problem, i.e. the only driver working is ESRI Shapefile (all smooth, no errors), but driver = "SQLite" throws the same error as reported for readVECT at the begining of this thread. Would it be possible to fix also writeVECT?

Here an example:

> library(rgrass7)
Loading required package: sp
Loading required package: XML
GRASS GIS interface loaded with GRASS version: GRASS 7.3.svn (2017)
and location: eu_laea

> bbox <- readVECT("bbox_greece", driver = "SQLite")
WARNING: No attribute table found -> using only category numbers as attributes
Exporting 1 area (may take some time)...
 100%
v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
(SQLite format).
OGR data source with driver: SQLite
...
WARNING: No attribute table found -> using only category numbers as attributes
Exporting 1 area (may take some time)...
 100%
v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
(SQLite format).

> writeVECT(bbox, "bbox_from_R", driver = "SQLite")
Error: driver %in% candDrivers is not TRUE

> writeVECT(bbox, "bbox_from_R", driver = "ESRI Shapefile")
... all goes fine...

Sorry for bothersome and thanks much in advance!

best,
Vero

ps: sessionInfo() and ogrDrivers() are the same as before.

2017-10-11 15:03 GMT+02:00 Roger Bivand <[hidden email]>:
OK, thanks, will revise at next release.


Roger

On Wed, 11 Oct 2017, Markus Metz wrote:

Dear Roger,

On Wed, Oct 11, 2017 at 2:36 PM, Roger Bivand <[hidden email]> wrote:

Dear Markus,

I can't see how to get the same strings out without conditioning,

with

ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"),
"[", 1)))

because for v.in.ogr -f and GDAL >= 2.0, GRASS < 7.3 presents for example:

GML (rw): GML
SQLite (rw): SQLite
ESRI Shapefile (rw): ESRI Shapefile
GeoJSON (rw): GeoJSON

(readOGR used the string following ":" )

The structure of the output of r.in.gdal -f and v.in.ogr -f is

<short name> (<read/write flags>): <description>

readOGR must use the string preceding "(". Anything following ":" is a
description which can change any time. Before GDAL 2.0, there was nothing
else but the short name for OGR drivers, therefore the short name was used
as description.


and >= 7.3:

GML (rw+): Geography Markup Language (GML)
SQLite (rw+): SQLite / Spatialite
ESRI Shapefile (rw+): ESRI Shapefile
GeoJSON (rw+): GeoJSON

where the string after ":" is different.

the string before the read/write flags, i.e. before "(" is identical.

If we can depend on all GRASS < 7.3 having the same short name position,
yes, I could avoid conditioning by changing the string processing to suit
= 7.3 and apply it to all previous; I chose not to modify the string
processing for < 7.3 to avoid any problems I can't readily check.

For all versions of GRASS 7 and all versions of GDAL, the short name
position has been and continues to be the first position. For v.in.ogr -f,
the short name may also appear after ":", but only if there is no long name.

Best regards,

Markus


Best wishes,

Roger


On Wed, 11 Oct 2017, Markus Metz wrote:

Dear Roger,

On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]>
wrote:


New version submitted to CRAN; until then:

install.packages("rgrass7", repos="http://R-Forge.R-project.org")

should pick up the latest version; #3425 closed. Please report back

whether this works ... (conditioning on GRASS version to create
comparable
driver name strings).

I don't think there is a need to condition on the GRASS version, see my
suggestion in #3425

Markus M


Roger


On Wed, 11 Oct 2017, Roger Bivand wrote:

Thanks for trying to contribute. The GH site is not the rgrass7

development site - that is SVN on R-forge (GH is a very preliminary trial
site for using sf vector representation in R, and maybe raster raster
representation (or forthcoming stars), instead of sp classes).


GRAS 7.2.2 works OK with the current logic checks; I can reproduce the

issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c
returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there is no
such change. Could the GRASS developer responsible for this obvious
regression provide an additional flag in v.in.ogr (and v.external,
v.out.ogr) to permit backwards compatibility? See line 387, needs to
change


#if GDAL_VERSION_NUM >= 2000000

to add a !backwards_compatible test too.

I'll hold off trying to fix this in rgrass7 because it is a regression.

I can add the backwards_compatibility=TRUE flag to readVECT() once it is
exposed.


This is:

https://trac.osgeo.org/grass/ticket/3425

Roger

On Tue, 10 Oct 2017, Ahmadou Dicko wrote:

In the readVECT function, internally v.in.ogr is used to list the

supported

vector format and it is compared the format available using rgdal (or

sf).

However, using v.external instead of v.in.ogr fix this single problem
because of the way the output is different (in form).
For example, if you use v.in.ogr you will have to compare


SQLite_/_Spatialite


(GRASS) to SQLite (R) and they are not the same.

I tried to send a PR, let me know if it works

https://github.com/rsbivand/rgrass7/pull/1

Best,

On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]>

wrote:


Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
Von: "Ahmadou Dicko" <[hidden email]>
An: "Helmut Kudrnovsky" <[hidden email]>
Cc: "Roger Bivand" <[hidden email]>, "
[hidden email]"

<


[hidden email]>


Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not

working


for readVECT



Hi everyone,

I think that using v.external -f (instead of v.in.ogr -f) can fix
this


issue (didn't try yet)




execGRASS("v.external", flags = "f", intern = TRUE)
[1] "ARCGEN"         "AVCBin"         "AVCE00"
[4] "AeronavFAA"     "AmigoCloud"     "BNA"
[7] "CAD"            "CSV"            "CSW"
[10] "Carto"          "Cloudant"       "CouchDB"
[13] "DGN"            "DXF"            "EDIGEO"
[16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
[19] "GML"            "GPKG"           "GPSBabel"
[22] "GPSTrackMaker"  "GPX"            "GeoJSON"
[25] "GeoRSS"         "Geoconcept"     "Geomedia"
[28] "HTF"            "HTTP"           "Idrisi"
[31] "JML"            "JPEG2000"       "KML"
[34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
[37] "MySQL"          "ODBC"           "ODS"
[40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
[43] "OGR_SDTS"       "OGR_VRT"        "OSM"
[46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
[49] "PDF"            "PGDUMP"         "PGeo"
[52] "PLSCENES"       "PostgreSQL"     "REC"



in a quick check, there is no difference in available formats.










--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: <a href="tel:%2B47%2055%2095%2093%2055" value="+4755959355" target="_blank">+47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal,
https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats



--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: <a href="tel:%2B47%2055%2095%2093%2055" value="+4755959355" target="_blank">+47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en


--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: <a href="tel:%2B47%2055%2095%2093%2055" value="+4755959355" target="_blank">+47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats


_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Markus Metz-3
Hi Vero,

On Thu, Oct 19, 2017 at 9:26 PM, Veronica Andreo <[hidden email]> wrote:
>
> Hello again,
>
> I come back to this thread beacuse the issue was solved for readVECT, but I now realize (when trying to write vectors back into GRASS after some processing in R) that writeVECT shows the same problem, i.e. the only driver working is ESRI Shapefile (all smooth, no errors), but driver = "SQLite" throws the same error as reported for readVECT at the begining of this thread. Would it be possible to fix also writeVECT?

in both readVECT and writeVECT in the file vect_link.R, replace
    ogrDGRASSs <- gsub(" ", "_", sapply(strsplit(ogrDGRASS, ": "), "[", 2))
with
    ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"), "[", 1)))

this works with all versions of GRASS 7 and all versions of GDAL.

Markus M


>

> Here an example:
>
> > library(rgrass7)
> Loading required package: sp
> Loading required package: XML
> GRASS GIS interface loaded with GRASS version: GRASS 7.3.svn (2017)
> and location: eu_laea
>
> > bbox <- readVECT("bbox_greece", driver = "SQLite")
> WARNING: No attribute table found -> using only category numbers as attributes
> Exporting 1 area (may take some time)...
>  100%
> v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
> (SQLite format).
> OGR data source with driver: SQLite
> ...
> WARNING: No attribute table found -> using only category numbers as attributes
> Exporting 1 area (may take some time)...
>  100%
> v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
> (SQLite format).
>
> > writeVECT(bbox, "bbox_from_R", driver = "SQLite")
> Error: driver %in% candDrivers is not TRUE
>
> > writeVECT(bbox, "bbox_from_R", driver = "ESRI Shapefile")
> ... all goes fine...
>
> Sorry for bothersome and thanks much in advance!
>
> best,
> Vero
>
> ps: sessionInfo() and ogrDrivers() are the same as before.
>
> 2017-10-11 15:03 GMT+02:00 Roger Bivand <[hidden email]>:
>>
>> OK, thanks, will revise at next release.
>>
>>
>> Roger
>>
>> On Wed, 11 Oct 2017, Markus Metz wrote:
>>
>>> Dear Roger,
>>>
>>> On Wed, Oct 11, 2017 at 2:36 PM, Roger Bivand <[hidden email]> wrote:
>>>>
>>>>
>>>> Dear Markus,
>>>>
>>>> I can't see how to get the same strings out without conditioning,
>>>
>>>
>>> with
>>>
>>> ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"),
>>> "[", 1)))
>>>
>>>> because for v.in.ogr -f and GDAL >= 2.0, GRASS < 7.3 presents for example:
>>>>
>>>> GML (rw): GML
>>>> SQLite (rw): SQLite
>>>> ESRI Shapefile (rw): ESRI Shapefile
>>>> GeoJSON (rw): GeoJSON
>>>>
>>>> (readOGR used the string following ":" )
>>>
>>>
>>> The structure of the output of r.in.gdal -f and v.in.ogr -f is
>>>
>>> <short name> (<read/write flags>): <description>
>>>
>>> readOGR must use the string preceding "(". Anything following ":" is a
>>> description which can change any time. Before GDAL 2.0, there was nothing
>>> else but the short name for OGR drivers, therefore the short name was used
>>> as description.
>>>
>>>>
>>>> and >= 7.3:
>>>>
>>>> GML (rw+): Geography Markup Language (GML)
>>>> SQLite (rw+): SQLite / Spatialite
>>>> ESRI Shapefile (rw+): ESRI Shapefile
>>>> GeoJSON (rw+): GeoJSON
>>>>
>>>> where the string after ":" is different.
>>>
>>>
>>> the string before the read/write flags, i.e. before "(" is identical.
>>>
>>>> If we can depend on all GRASS < 7.3 having the same short name position,
>>>
>>> yes, I could avoid conditioning by changing the string processing to suit
>>>>
>>>> = 7.3 and apply it to all previous; I chose not to modify the string
>>>
>>> processing for < 7.3 to avoid any problems I can't readily check.
>>>
>>> For all versions of GRASS 7 and all versions of GDAL, the short name
>>> position has been and continues to be the first position. For v.in.ogr -f,
>>> the short name may also appear after ":", but only if there is no long name.
>>>
>>> Best regards,
>>>
>>> Markus
>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Roger
>>>>
>>>>
>>>> On Wed, 11 Oct 2017, Markus Metz wrote:
>>>>
>>>>> Dear Roger,
>>>>>
>>>>> On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]>
>>>
>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> New version submitted to CRAN; until then:
>>>>>>
>>>>>> install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>>>>>>
>>>>>> should pick up the latest version; #3425 closed. Please report back
>>>>>
>>>>>
>>>>> whether this works ... (conditioning on GRASS version to create
>>>
>>> comparable
>>>>>
>>>>> driver name strings).
>>>>>
>>>>> I don't think there is a need to condition on the GRASS version, see my
>>>>> suggestion in #3425
>>>>>
>>>>> Markus M
>>>>>>
>>>>>>
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>> On Wed, 11 Oct 2017, Roger Bivand wrote:
>>>>>>
>>>>>>> Thanks for trying to contribute. The GH site is not the rgrass7
>>>>>
>>>>>
>>>>> development site - that is SVN on R-forge (GH is a very preliminary trial
>>>>> site for using sf vector representation in R, and maybe raster raster
>>>>> representation (or forthcoming stars), instead of sp classes).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> GRAS 7.2.2 works OK with the current logic checks; I can reproduce the
>>>>>
>>>>>
>>>>> issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c
>>>>> returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there is no
>>>>> such change. Could the GRASS developer responsible for this obvious
>>>>> regression provide an additional flag in v.in.ogr (and v.external,
>>>>> v.out.ogr) to permit backwards compatibility? See line 387, needs to
>>>
>>> change
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> #if GDAL_VERSION_NUM >= 2000000
>>>>>>>
>>>>>>> to add a !backwards_compatible test too.
>>>>>>>
>>>>>>> I'll hold off trying to fix this in rgrass7 because it is a regression.
>>>>>
>>>>>
>>>>> I can add the backwards_compatibility=TRUE flag to readVECT() once it is
>>>>> exposed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is:
>>>>>>>
>>>>>>> https://trac.osgeo.org/grass/ticket/3425
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>> On Tue, 10 Oct 2017, Ahmadou Dicko wrote:
>>>>>>>
>>>>>>>> In the readVECT function, internally v.in.ogr is used to list the
>>>>>
>>>>>
>>>>> supported
>>>>>>>>
>>>>>>>>
>>>>>>>> vector format and it is compared the format available using rgdal (or
>>>>>
>>>>>
>>>>> sf).
>>>>>>>>
>>>>>>>>
>>>>>>>> However, using v.external instead of v.in.ogr fix this single problem
>>>>>>>> because of the way the output is different (in form).
>>>>>>>> For example, if you use v.in.ogr you will have to compare
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> SQLite_/_Spatialite
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> (GRASS) to SQLite (R) and they are not the same.
>>>>>>>>
>>>>>>>> I tried to send a PR, let me know if it works
>>>>>>>>
>>>>>>>> https://github.com/rsbivand/rgrass7/pull/1
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]>
>>>>>
>>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>>>>>>> Von: "Ahmadou Dicko" <[hidden email]>
>>>>>>>>>> An: "Helmut Kudrnovsky" <[hidden email]>
>>>>>>>>>> Cc: "Roger Bivand" <[hidden email]>, "
>>>
>>> [hidden email]"
>>>>>
>>>>>
>>>>> <
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not
>>>>>
>>>>>
>>>>> working
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> for readVECT
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> I think that using v.external -f (instead of v.in.ogr -f) can fix
>>>
>>> this
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> issue (didn't try yet)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> execGRASS("v.external", flags = "f", intern = TRUE)
>>>>>>>>>> [1] "ARCGEN"         "AVCBin"         "AVCE00"
>>>>>>>>>> [4] "AeronavFAA"     "AmigoCloud"     "BNA"
>>>>>>>>>> [7] "CAD"            "CSV"            "CSW"
>>>>>>>>>> [10] "Carto"          "Cloudant"       "CouchDB"
>>>>>>>>>> [13] "DGN"            "DXF"            "EDIGEO"
>>>>>>>>>> [16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
>>>>>>>>>> [19] "GML"            "GPKG"           "GPSBabel"
>>>>>>>>>> [22] "GPSTrackMaker"  "GPX"            "GeoJSON"
>>>>>>>>>> [25] "GeoRSS"         "Geoconcept"     "Geomedia"
>>>>>>>>>> [28] "HTF"            "HTTP"           "Idrisi"
>>>>>>>>>> [31] "JML"            "JPEG2000"       "KML"
>>>>>>>>>> [34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
>>>>>>>>>> [37] "MySQL"          "ODBC"           "ODS"
>>>>>>>>>> [40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
>>>>>>>>>> [43] "OGR_SDTS"       "OGR_VRT"        "OSM"
>>>>>>>>>> [46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
>>>>>>>>>> [49] "PDF"            "PGDUMP"         "PGeo"
>>>>>>>>>> [52] "PLSCENES"       "PostgreSQL"     "REC"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> in a quick check, there is no difference in available formats.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Roger Bivand
>>>>>> Department of Economics, Norwegian School of Economics,
>>>>>> Helleveien 30, N-5045 Bergen, Norway.
>>>>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>>>>> Editor-in-Chief of The R Journal,
>>>
>>> https://journal.r-project.org/index.html
>>>>>>
>>>>>> http://orcid.org/0000-0003-2392-6140
>>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>>> _______________________________________________
>>>>>> grass-stats mailing list
>>>>>> [hidden email]
>>>>>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Roger Bivand
>>>> Department of Economics, Norwegian School of Economics,
>>>> Helleveien 30, N-5045 Bergen, Norway.
>>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>>> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
>>>> http://orcid.org/0000-0003-2392-6140
>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>
>>>
>>
>> --
>> Roger Bivand
>> Department of Economics, Norwegian School of Economics,
>> Helleveien 30, N-5045 Bergen, Norway.
>> voice: +47 55 95 93 55; e-mail: [hidden email]
>> Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
>> http://orcid.org/0000-0003-2392-6140
>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>> _______________________________________________
>> grass-stats mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>
>

_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Roger Bivand
On Fri, 20 Oct 2017, Markus Metz wrote:

> Hi Vero,
>
> On Thu, Oct 19, 2017 at 9:26 PM, Veronica Andreo <[hidden email]>
> wrote:
>>
>> Hello again,
>>
>> I come back to this thread beacuse the issue was solved for readVECT, but
> I now realize (when trying to write vectors back into GRASS after some
> processing in R) that writeVECT shows the same problem, i.e. the only
> driver working is ESRI Shapefile (all smooth, no errors), but driver =
> "SQLite" throws the same error as reported for readVECT at the begining of
> this thread. Would it be possible to fix also writeVECT?
>
> in both readVECT and writeVECT in the file vect_link.R, replace
>    ogrDGRASSs <- gsub(" ", "_", sapply(strsplit(ogrDGRASS, ": "), "[", 2))
> with
>    ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"),
> "[", 1)))
>
> this works with all versions of GRASS 7 and all versions of GDAL.

Please try:

install.packages("rgrass7", repos="http://R-Forge.R-project.org")

which incorporates the change in both places, not just one as before (svn
revision 63 on R-Forge, spgrass project).

Roger

>
> Markus M
>
>
>>
>> Here an example:
>>
>>> library(rgrass7)
>> Loading required package: sp
>> Loading required package: XML
>> GRASS GIS interface loaded with GRASS version: GRASS 7.3.svn (2017)
>> and location: eu_laea
>>
>>> bbox <- readVECT("bbox_greece", driver = "SQLite")
>> WARNING: No attribute table found -> using only category numbers as
> attributes
>> Exporting 1 area (may take some time)...
>>  100%
>> v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
>> (SQLite format).
>> OGR data source with driver: SQLite
>> ...
>> WARNING: No attribute table found -> using only category numbers as
> attributes
>> Exporting 1 area (may take some time)...
>>  100%
>> v.out.ogr complete. 1 feature (Polygon type) written to <bbox_greece>
>> (SQLite format).
>>
>>> writeVECT(bbox, "bbox_from_R", driver = "SQLite")
>> Error: driver %in% candDrivers is not TRUE
>>
>>> writeVECT(bbox, "bbox_from_R", driver = "ESRI Shapefile")
>> ... all goes fine...
>>
>> Sorry for bothersome and thanks much in advance!
>>
>> best,
>> Vero
>>
>> ps: sessionInfo() and ogrDrivers() are the same as before.
>>
>> 2017-10-11 15:03 GMT+02:00 Roger Bivand <[hidden email]>:
>>>
>>> OK, thanks, will revise at next release.
>>>
>>>
>>> Roger
>>>
>>> On Wed, 11 Oct 2017, Markus Metz wrote:
>>>
>>>> Dear Roger,
>>>>
>>>> On Wed, Oct 11, 2017 at 2:36 PM, Roger Bivand <[hidden email]>
> wrote:
>>>>>
>>>>>
>>>>> Dear Markus,
>>>>>
>>>>> I can't see how to get the same strings out without conditioning,
>>>>
>>>>
>>>> with
>>>>
>>>> ogrDGRASSs <- gsub(" ", "_", trimws(sapply(strsplit(ogrDGRASS, " [(]"),
>>>> "[", 1)))
>>>>
>>>>> because for v.in.ogr -f and GDAL >= 2.0, GRASS < 7.3 presents for
> example:
>>>>>
>>>>> GML (rw): GML
>>>>> SQLite (rw): SQLite
>>>>> ESRI Shapefile (rw): ESRI Shapefile
>>>>> GeoJSON (rw): GeoJSON
>>>>>
>>>>> (readOGR used the string following ":" )
>>>>
>>>>
>>>> The structure of the output of r.in.gdal -f and v.in.ogr -f is
>>>>
>>>> <short name> (<read/write flags>): <description>
>>>>
>>>> readOGR must use the string preceding "(". Anything following ":" is a
>>>> description which can change any time. Before GDAL 2.0, there was
> nothing
>>>> else but the short name for OGR drivers, therefore the short name was
> used
>>>> as description.
>>>>
>>>>>
>>>>> and >= 7.3:
>>>>>
>>>>> GML (rw+): Geography Markup Language (GML)
>>>>> SQLite (rw+): SQLite / Spatialite
>>>>> ESRI Shapefile (rw+): ESRI Shapefile
>>>>> GeoJSON (rw+): GeoJSON
>>>>>
>>>>> where the string after ":" is different.
>>>>
>>>>
>>>> the string before the read/write flags, i.e. before "(" is identical.
>>>>
>>>>> If we can depend on all GRASS < 7.3 having the same short name
> position,
>>>>
>>>> yes, I could avoid conditioning by changing the string processing to
> suit
>>>>>
>>>>> = 7.3 and apply it to all previous; I chose not to modify the string
>>>>
>>>> processing for < 7.3 to avoid any problems I can't readily check.
>>>>
>>>> For all versions of GRASS 7 and all versions of GDAL, the short name
>>>> position has been and continues to be the first position. For v.in.ogr
> -f,
>>>> the short name may also appear after ":", but only if there is no long
> name.
>>>>
>>>> Best regards,
>>>>
>>>> Markus
>>>>
>>>>>
>>>>> Best wishes,
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On Wed, 11 Oct 2017, Markus Metz wrote:
>>>>>
>>>>>> Dear Roger,
>>>>>>
>>>>>> On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <[hidden email]>
>>>>
>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> New version submitted to CRAN; until then:
>>>>>>>
>>>>>>> install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>>>>>>>
>>>>>>> should pick up the latest version; #3425 closed. Please report back
>>>>>>
>>>>>>
>>>>>> whether this works ... (conditioning on GRASS version to create
>>>>
>>>> comparable
>>>>>>
>>>>>> driver name strings).
>>>>>>
>>>>>> I don't think there is a need to condition on the GRASS version, see
> my
>>>>>> suggestion in #3425
>>>>>>
>>>>>> Markus M
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 11 Oct 2017, Roger Bivand wrote:
>>>>>>>
>>>>>>>> Thanks for trying to contribute. The GH site is not the rgrass7
>>>>>>
>>>>>>
>>>>>> development site - that is SVN on R-forge (GH is a very preliminary
> trial
>>>>>> site for using sf vector representation in R, and maybe raster raster
>>>>>> representation (or forthcoming stars), instead of sp classes).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> GRAS 7.2.2 works OK with the current logic checks; I can reproduce
> the
>>>>>>
>>>>>>
>>>>>> issue in 7.3 (latest); there is a change in vector/v.in.ogr/main.c
>>>>>> returning the DriverLongName for GDAL >= 2.0; in GRASS 7.2.2, there
> is no
>>>>>> such change. Could the GRASS developer responsible for this obvious
>>>>>> regression provide an additional flag in v.in.ogr (and v.external,
>>>>>> v.out.ogr) to permit backwards compatibility? See line 387, needs to
>>>>
>>>> change
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> #if GDAL_VERSION_NUM >= 2000000
>>>>>>>>
>>>>>>>> to add a !backwards_compatible test too.
>>>>>>>>
>>>>>>>> I'll hold off trying to fix this in rgrass7 because it is a
> regression.
>>>>>>
>>>>>>
>>>>>> I can add the backwards_compatibility=TRUE flag to readVECT() once it
> is
>>>>>> exposed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is:
>>>>>>>>
>>>>>>>> https://trac.osgeo.org/grass/ticket/3425
>>>>>>>>
>>>>>>>> Roger
>>>>>>>>
>>>>>>>> On Tue, 10 Oct 2017, Ahmadou Dicko wrote:
>>>>>>>>
>>>>>>>>> In the readVECT function, internally v.in.ogr is used to list the
>>>>>>
>>>>>>
>>>>>> supported
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> vector format and it is compared the format available using rgdal
> (or
>>>>>>
>>>>>>
>>>>>> sf).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, using v.external instead of v.in.ogr fix this single
> problem
>>>>>>>>> because of the way the output is different (in form).
>>>>>>>>> For example, if you use v.in.ogr you will have to compare
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> SQLite_/_Spatialite
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (GRASS) to SQLite (R) and they are not the same.
>>>>>>>>>
>>>>>>>>> I tried to send a PR, let me know if it works
>>>>>>>>>
>>>>>>>>> https://github.com/rsbivand/rgrass7/pull/1
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> On Tue, Oct 10, 2017 at 9:29 PM, Helmut Kudrnovsky <[hidden email]>
>>>>>>
>>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>>>>>>>> Von: "Ahmadou Dicko" <[hidden email]>
>>>>>>>>>>> An: "Helmut Kudrnovsky" <[hidden email]>
>>>>>>>>>>> Cc: "Roger Bivand" <[hidden email]>, "
>>>>
>>>> [hidden email]"
>>>>>>
>>>>>>
>>>>>> <
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [hidden email]>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Betreff: Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not
>>>>>>
>>>>>>
>>>>>> working
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> for readVECT
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> I think that using v.external -f (instead of v.in.ogr -f) can fix
>>>>
>>>> this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> issue (didn't try yet)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> execGRASS("v.external", flags = "f", intern = TRUE)
>>>>>>>>>>> [1] "ARCGEN"         "AVCBin"         "AVCE00"
>>>>>>>>>>> [4] "AeronavFAA"     "AmigoCloud"     "BNA"
>>>>>>>>>>> [7] "CAD"            "CSV"            "CSW"
>>>>>>>>>>> [10] "Carto"          "Cloudant"       "CouchDB"
>>>>>>>>>>> [13] "DGN"            "DXF"            "EDIGEO"
>>>>>>>>>>> [16] "ESRI_Shapefile" "ElasticSearch"  "GFT"
>>>>>>>>>>> [19] "GML"            "GPKG"           "GPSBabel"
>>>>>>>>>>> [22] "GPSTrackMaker"  "GPX"            "GeoJSON"
>>>>>>>>>>> [25] "GeoRSS"         "Geoconcept"     "Geomedia"
>>>>>>>>>>> [28] "HTF"            "HTTP"           "Idrisi"
>>>>>>>>>>> [31] "JML"            "JPEG2000"       "KML"
>>>>>>>>>>> [34] "MSSQLSpatial"   "MapInfo_File"   "Memory"
>>>>>>>>>>> [37] "MySQL"          "ODBC"           "ODS"
>>>>>>>>>>> [40] "OGR_GMT"        "OGR_GRASS"      "OGR_PDS"
>>>>>>>>>>> [43] "OGR_SDTS"       "OGR_VRT"        "OSM"
>>>>>>>>>>> [46] "OpenAir"        "OpenFileGDB"    "PCIDSK"
>>>>>>>>>>> [49] "PDF"            "PGDUMP"         "PGeo"
>>>>>>>>>>> [52] "PLSCENES"       "PostgreSQL"     "REC"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> in a quick check, there is no difference in available formats.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Roger Bivand
>>>>>>> Department of Economics, Norwegian School of Economics,
>>>>>>> Helleveien 30, N-5045 Bergen, Norway.
>>>>>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>>>>>> Editor-in-Chief of The R Journal,
>>>>
>>>> https://journal.r-project.org/index.html
>>>>>>>
>>>>>>> http://orcid.org/0000-0003-2392-6140
>>>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>>>> _______________________________________________
>>>>>>> grass-stats mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Roger Bivand
>>>>> Department of Economics, Norwegian School of Economics,
>>>>> Helleveien 30, N-5045 Bergen, Norway.
>>>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>>>> Editor-in-Chief of The R Journal,
> https://journal.r-project.org/index.html
>>>>> http://orcid.org/0000-0003-2392-6140
>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>
>>>>
>>>
>>> --
>>> Roger Bivand
>>> Department of Economics, Norwegian School of Economics,
>>> Helleveien 30, N-5045 Bergen, Norway.
>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>> Editor-in-Chief of The R Journal,
> https://journal.r-project.org/index.html
>>> http://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>> _______________________________________________
>>> grass-stats mailing list
>>> [hidden email]
>>> https://lists.osgeo.org/mailman/listinfo/grass-stats
>>
>>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Helmut Kudrnovsky
>Please try:
>
>install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>
>which incorporates the change in both places, not just one as before (svn
>revision 63 on R-Forge, spgrass project).

tested with above install.packages cmd:

> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 15063)

Matrix products: default

locale:
[1] C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] rgrass7_0.1-11 XML_3.98-1.9   sp_1.2-5

loaded via a namespace (and not attached):
[1] compiler_3.4.0  grid_3.4.0      lattice_0.20-35
>

it works here on winGRASS.



-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Stats-f4049448.html
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: rgrass7 - SQLite and GML drivers not working for readVECT

Veronica Andreo
Yup, works now. Thanks Roger! And thanks MarkusM as well! :)

best,
vero

2017-10-20 21:31 GMT+02:00 Helmut Kudrnovsky <[hidden email]>:
>Please try:
>
>install.packages("rgrass7", repos="http://R-Forge.R-project.org")
>
>which incorporates the change in both places, not just one as before (svn
>revision 63 on R-Forge, spgrass project).

tested with above install.packages cmd:

> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 15063)

Matrix products: default

locale:
[1] C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] rgrass7_0.1-11 XML_3.98-1.9   sp_1.2-5

loaded via a namespace (and not attached):
[1] compiler_3.4.0  grid_3.4.0      lattice_0.20-35
>

it works here on winGRASS.



-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Stats-f4049448.html
_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats


_______________________________________________
grass-stats mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-stats
12