On Wed, Sep 14, 2016 at 4:59 PM, Rich Shepard <rshep...@appl-ecosys.com> wrote:
> On Wed, 14 Sep 2016, Helmut Kudrnovsky wrote:
>
>> http://www.gdal.org/drv_openfilegdb.html
>
>
>   Based on this line I get potentially useful information from grass:
> "A specific .gdbtable file (including "system" tables) can also be opened
> directly."
>
>   Still cannot use the directory as the input target:
>>
>> v.in.ogr input=~/data/grassdata/or-trans/
>
> ERROR: Unable to open data source </home/rshepard/data/grassdata/or-trans/>
>
> However, a single .gdbtable file produces this output:
>
>> v.in.ogr input=~/data/grassdata/or-trans/a00000001.gdbtable
>
> WARNING: All available OGR layers will be imported into vector map
>          <GDB_SystemCatalog>

Using CLI, what is the output of
v.in.ogr input=~/data/grassdata/or-trans/a00000001.gdbtable -l
?

> ERROR: Projection of dataset does not appear to match current location.
>
>        GRASS LOCATION PROJ_INFO is:
>        name: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
>        datum: nad83harn
>        ellps: grs80
>        proj: lcc
>        lat_1: 44.33333333333334
>        lat_2: 46
>        lat_0: 43.66666666666666
>        lon_0: -120.5
>        x_0: 2500000
>        y_0: 0
>        no_defs: defined
>
>        Import dataset PROJ_INFO is:
>        Dataset proj = 0 (unreferenced/unknown)
>
>        In case of no significant differences in the projection definitions,
>        use the -o flag to ignore them and use current location definition.
>        Consider generating a new location with 'location' parameter from
>        input data set.
>
>   This tells me that the source data might be in long-lat and not projected.

This tells you only that the coordinate reference system of the input
data is unknown. It might be Lat/Lon or something else. You can try to
1) import the data into a Lat/Lon location, reproject to the target
location and check if the geolocation is ok
2) ask the data provider about the coordinate reference system for
this data source

Markus M

> Since grass will not display the source files' location name I will move
> them to the WGS84/ long-lat location.
>
>   This still does not import the files. Using the GUI and selecting
> Directory and OpenFileGDB format all files are greyed out and grass won't
> open anything because no file has been selected.
>
>   Changing to File with OpenFileGDB format and selecting a single .gdbtable
> file produces these results:
>
> (Wed Sep 14 07:50:52 2016) v.import
> input=/home/rshepard/data/grassdata/WGS84/odot2014/a00000001.gdbtable
> layer=GDB_SystemCatalog output=GDB_SystemCatalog --overwrite
> WARNING: All available OGR layers will be imported into vector map
> <GDB_SystemCatalog>
> ERROR: Coordinate reference system not available for input
> </home/rshepard/data/grassdata/WGS84/odot2014/a00000001.gdbtable>
> (Wed Sep 14 07:50:52 2016) Command finished (0 sec)
>
>   I'm not ignoring what Stefan, Helmut, and Markus are writing, and I have
> again read the gdal.org web page on ESRI OpenFileGDB, but I'm not getting
> the expected results.
>
>   If there's no available reference system there must be something broken or
> incomplete in the source tarball. I'll contact the repository this morning
> and let you know what I learn.
>
> Thanks,
>
> Rich
>
>
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to