[GRASS-stats] Re: [R-sig-Geo] Fail to load a vector layer using
spgrass6
Dylan Beaudette
dylan.beaudette at gmail.com
Wed Dec 15 12:29:57 EST 2010
2010/12/15 Roger Bivand <Roger.Bivand at nhh.no>:
> On Wed, 15 Dec 2010, Pierre Roudier wrote:
>
>> Roger,
>>
>>> The latest (0.6-23) spgrass6 has a fix for a specific problem in the
>>> layer
>>> parameter of v.out.ogr in GRASS7 - I see that you are using the previous
>>> spgrass6. Could you try updating spgrass6?
>>>
>>
>> I did update and got the same error on both GRASS 6.4 and GRASS 7.0
>
> Pierre,
>
> Please use a toy example, with a common data set such as spearfish. You have
> 355021 areas, which must be getting close to maxing out what a shapefile can
> take.
>
> Using GML is almost certainly a bad idea, as everything gets converted to
> text.
>
> The main problem of trying to use other drivers than "ESRI Shapefile" is
> that each driver has very specific requirements of the dsn and olayer
> strings. The interface functions for vector data presuppose "ESRI
> Shapefile", so dsn is a directory, and olayer is the shared file name within
> the directory. This is what you are seeing in the error messages below. ESRI
> Shapefile works with a directory as dsn, GML doesn't; ESRI Shapefile doesn't
> work with a file as dsn, GML does. For GML, KML, and some others, the dsn is
> a file name, and olayer is a placeholder. Providing the driver-specific
> modifications is arguably not a robust way to proceed.
>
> I'm unsure about the advisability of persisting with a driver= argument. I'd
> welcome arguments for or against, and if for, some R code to match the
> drivers to the dsn/olayer formats, that does not presuppose the presence of
> drivers that have external dependencies.
Thanks for taking time to tinker with this possibility. I know this is
asking a lot, but how about providing 2 well-supported drivers: say
shapefiles and sqlite? Then, a simple switch statement could be used
to describe the dsn, as opposed to a more generic option. Maybe this
would introduce too many branches in the code-- but sometimes it would
be really nice to have an alternative to shapefiles during this
process.
> I would suggest that you try to install the GRASS plugin for GDAL/OGR, and
> try to use that, since an intermediate file solution with the standard
> driver seems undesirable.
I would second this.
Cheers,
Dylan
> I'm also very unsure about what you want to do with the data in R.
> Visualising will be painfully slow, and if you need to do analysis on the
> attribute data alone, you may as well transfer just that, not the
> geometries.
>
> Have you considered using a database back-end?
>
> Note that you have problems in ph_cl which require the c flag.
>
> Roger
>
>>
>>> If that doesn't work, please move thread only to grass-stats, and try
>>> using
>>> v.out.ogr to export the vector to the GRASS mapset temporary directory
>>> manually - use g.tempfile to find out what the path to that directory is.
>>> If
>>> v.out.ogr appears to complete without problems, do check the temporary
>>> directory to be sure.
>>>
>>
>> The output of g.tempfile is:
>>
>>
>> /home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/18058.0
>>
>> When using that tempfile for export as Shapefile it fails:
>>
>> v.out.ogr in=ph_cl
>>
>> dsn='/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/18058.0'
>> format=ESRI_Shapefile
>> WARNING: The map contains islands. To preserve them in the output map, use
>> the -c flag
>> ERROR 1:
>> /home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/18058.0
>> is not a directory.
>>
>> ERROR: Unable to open OGR data source
>>
>> '/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/18058.0'
>>
>> However, if I specify the tmp folder that works:
>> v.out.ogr in=ph_cl
>>
>> dsn='/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/'
>> format=ESRI_Shapefile
>>
>> BUT - and that's where it gets tricky, if I want to use the GML
>> driver, this is the opposite situation:
>>
>> v.out.ogr in=ph_cl
>>
>> dsn='/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/'
>> format=GML
>> ERROR 4: Failed to create GML file
>>
>> /home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/.
>> ERROR: Unable to open OGR data source
>>
>> '/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/'
>>
>> While this works:
>>
>> v.out.ogr in=ph_cl
>>
>> dsn='/home/roudierp/Documents/GRASSDATA/NZTM2000/nitrif_inhib/.tmp/A208_RoudierP/18628.0'
>> format=GML
>> Exporting 355021 areas (may take some time)...
>>
>> Any idea?
>>
>> Pierre
>>
>>> Roger
>>>
>>>>
>>>>> And GDAL 1.7.1 is not the current
>>>>> version, which is 1.7.3. Did you install GDAL and/or GRASS from source,
>>>>> or
>>>>> from binaries (in my experience, installing from source ensures more
>>>>> consistency, and the GDAL/OGR GRASS plugins are often the source of
>>>>> problems
>>>>> because of version mismatch).
>>>>
>>>> I installed both GRASS 6.4 and GDAL/OGR from binaries, yes.
>>>>
>>>>> PS. The best list is probably:
>>>>>
>>>>> http://grass.osgeo.org/statsgrass/index.php
>>>>
>>>> OK. I am sending that message to that list, and keep R-sig-geo for
>>>> consistency. Sorry for cross-posting.
>>>>
>>>> Thanks again,
>>>>
>>>> Pierre
>>>>
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> as it is more specific, and also seen by GRASS developers.
>>>>>
>>>>>>
>>>>>> I tried to play with the different options but I did not succeed>
>>>>>> Here's more info about my data and platform:
>>>>>>
>>>>>> Here is the output of v.info for the data I want to load:
>>>>>> GRASS 7.0.svn (NZTM2000):~ > v.info ph_cl
>>>>>>
>>>>>>
>>>>>>
>>>>>> +----------------------------------------------------------------------------+
>>>>>> | Name: ph_cl
>>>>>> |
>>>>>> | Mapset: nitrif_inhib
>>>>>> |
>>>>>> | Location: NZTM2000
>>>>>> |
>>>>>> | Database: /home/roudierp/Documents/GRASSDATA
>>>>>> |
>>>>>> | Title:
>>>>>> |
>>>>>> | Map scale: 1:1
>>>>>> |
>>>>>> | Map format: native
>>>>>> |
>>>>>> | Name of creator: roudierp
>>>>>> |
>>>>>> | Organization:
>>>>>> |
>>>>>> | Source date: Mon Dec 13 11:30:11 2010
>>>>>> |
>>>>>>
>>>>>>
>>>>>>
>>>>>> |----------------------------------------------------------------------------|
>>>>>> | Type of map: vector (level: 2)
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | Number of points: 0 Number of centroids:
>>>>>> 236847
>>>>>> |
>>>>>> | Number of lines: 0 Number of boundaries:
>>>>>> 892041
>>>>>> |
>>>>>> | Number of areas: 355021 Number of islands:
>>>>>> 79124
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | Map is 3D: No
>>>>>> |
>>>>>> | Number of dblinks: 1
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | Projection: Transverse Mercator
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | N: 6190887.80270169 S: 4823266.04395524
>>>>>> |
>>>>>> | E: 2091804.65744429 W: 1170289.3071784
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> | Digitization threshold: 0
>>>>>> |
>>>>>> | Comment:
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>>
>>>>>>
>>>>>>
>>>>>> +----------------------------------------------------------------------------+
>>>>>>
>>>>>> And finally some metadata about the software packages I used:
>>>>>>
>>>>>> here's the sessionInfo():
>>>>>>
>>>>>>> sessionInfo()
>>>>>>
>>>>>> R version 2.12.0 (2010-10-15)
>>>>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>>>>>
>>>>>> locale:
>>>>>> [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
>>>>>> [3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
>>>>>> [5] LC_MONETARY=C LC_MESSAGES=en_GB.UTF-8
>>>>>> [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
>>>>>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>>>>>> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
>>>>>>
>>>>>> attached base packages:
>>>>>> [1] stats graphics grDevices utils datasets methods base
>>>>>>
>>>>>> other attached packages:
>>>>>> [1] spgrass6_0.6-21 XML_3.2-0 rgdal_0.6-31 sp_0.9-74
>>>>>>
>>>>>> loaded via a namespace (and not attached):
>>>>>> [1] grid_2.12.0 lattice_0.19-13
>>>>>>
>>>>>>> library(spgrass6)
>>>>>>
>>>>>> Loading required package: sp
>>>>>> Loading required package: rgdal
>>>>>> Geospatial Data Abstraction Library extensions to R successfully
>>>>>> loaded
>>>>>> Loaded GDAL runtime: GDAL 1.7.1, released 2010/02/08
>>>>>> Path to GDAL shared files: /usr/share/gdal
>>>>>> Loaded PROJ.4 runtime: Rel. 4.7.1, 23 September 2009
>>>>>> Path to PROJ.4 shared files: /usr/share/proj/
>>>>>> Loading required package: XML
>>>>>> GRASS GIS interface loaded with GRASS version: 7.0.svn
>>>>>> and location: NZTM2000
>>>>>>
>>>>>> I got the last CRAN version of sp.
>>>>>>
>>>>>> This runs on a linux machine:
>>>>>> GRASS 7.0.svn (NZTM2000):~ > uname -a
>>>>>> Linux A208_RoudierP 2.6.34.7-0.5-xen #1 SMP 2010-10-25 08:40:12 +0200
>>>>>> x86_64 x86_64 x86_64 GNU/Linux
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Pierre
>>>>>>
>>>>>> _______________________________________________
>>>>>> R-sig-Geo mailing list
>>>>>> R-sig-Geo at r-project.org
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>>
>>>>>
>>>>> --
>>>>> Roger Bivand
>>>>> Economic Geography Section, Department of Economics, Norwegian School
>>>>> of
>>>>> Economics and Business Administration, Helleveien 30, N-5045 Bergen,
>>>>> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
>>>>> e-mail: Roger.Bivand at nhh.no
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Roger Bivand
>>> Economic Geography Section, Department of Economics, Norwegian School of
>>> Economics and Business Administration, Helleveien 30, N-5045 Bergen,
>>> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
>>> e-mail: Roger.Bivand at nhh.no
>>
>
> --
> Roger Bivand
> Economic Geography Section, Department of Economics, Norwegian School of
> Economics and Business Administration, Helleveien 30, N-5045 Bergen,
> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: Roger.Bivand at nhh.no
>
> _______________________________________________
> grass-stats mailing list
> grass-stats at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-stats
>
>
More information about the grass-stats
mailing list