[GRASS-stats] rgrass7 - SQLite and GML drivers not working for readVECT

Wed Oct 11 05:36:22 PDT 2017

Dear Markus,

I can't see how to get the same strings out without conditioning, 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 ":" )

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

Best wishes,

Roger

On Wed, 11 Oct 2017, Markus Metz wrote:

> Dear Roger,
>
> On Wed, Oct 11, 2017 at 1:41 PM, Roger Bivand <Roger.Bivand at nhh.no> 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 <hellik at web.de>
> wrote:
>>>>
>>>>>> Gesendet: Dienstag, 10. Oktober 2017 um 23:24 Uhr
>>>>>> Von: "Ahmadou Dicko" <dicko.ahmadou at gmail.com>
>>>>>> An: "Helmut Kudrnovsky" <hellik at web.de>
>>>>>> Cc: "Roger Bivand" <Roger.Bivand at nhh.no>, "grass-stats at lists.osgeo.org"
> <
>>>>>
>>>>> grass-stats at lists.osgeo.org>
>>>>>>
>>>>>> 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: Roger.Bivand at nhh.no
>> 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
>> grass-stats at lists.osgeo.org
>> 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: Roger.Bivand at nhh.no
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