[GRASS-stats] rgrass7 - SQLite and GML drivers not working for readVECT
Roger Bivand
Roger.Bivand at nhh.no
Fri Oct 20 12:17:00 PDT 2017
On Fri, 20 Oct 2017, Markus Metz wrote:
> Hi Vero,
>
> On Thu, Oct 19, 2017 at 9:26 PM, Veronica Andreo <veroandreo at gmail.com>
> 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 <Roger.Bivand at nhh.no>:
>>>
>>> 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
>>> _______________________________________________
>>> 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
More information about the grass-stats
mailing list