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

Wed Oct 11 06:03:00 PDT 2017

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 <Roger.Bivand at nhh.no> 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 <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
>

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