[GRASS-stats] rgrass7 - SQLite and GML drivers not working for readVECT
Veronica Andreo
veroandreo at gmail.com
Thu Oct 19 12:26:02 PDT 2017
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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-stats/attachments/20171019/2caed921/attachment-0001.html>
More information about the grass-stats
mailing list