[GRASS-user] Estimating import time for large data file

rshepard · May 28, 2020, 3:25pm

I'm trying to import (using v.in.ogr) a rather large file (1.22G *.shp and
4.5M *.dbf). I see a lot of system disk reads, low cpu usage, but after a
half-hour it appears to have stopped processing.

I'm running Slackware-14.2/x86_64 on a desktop with an AMD Ryzen7 2700 CPU
(8 cores/16 threads) and 32G DDR4 memory. GRASS-7.9.dev is configured to
enable largefile and use openmp.

1. Can I do more to facilitate import of this large, statewide wetlands
data set?

2. Is there a way to estimate the time import would take? If so, I'll start
it using screen and let it run in the background, overnight if necessary.

3. Is there a realtime progress monitor that informs me grass is chewing on
the import or stuck somewhere?

The GUI layer manager shows the map needs cleaning for many (most? all?)
polygons when it eventually is imported, but that's to be addressed later.

Regards,

Rich

mlennert · May 29, 2020, 9:20am

On 28/05/20 17:25, Rich Shepard wrote:

I'm trying to import (using v.in.ogr) a rather large file (1.22G *.shp and
4.5M *.dbf). I see a lot of system disk reads, low cpu usage, but after a
half-hour it appears to have stopped processing.

Importing such a large file can take a lot of time because of the cleaning in order to get it into GRASS GIS' topological format.

I'm running Slackware-14.2/x86_64 on a desktop with an AMD Ryzen7 2700 CPU
(8 cores/16 threads) and 32G DDR4 memory. GRASS-7.9.dev is configured to
enable largefile and use openmp.

1. Can I do more to facilitate import of this large, statewide wetlands
data set?

2. Is there a way to estimate the time import would take? If so, I'll start
it using screen and let it run in the background, overnight if necessary.

I think it really depends on the specific file in terms of geometry complexity and cleanliness, so difficult to pre-determine. I regularly launch large import jobs overnight.

3. Is there a realtime progress monitor that informs me grass is chewing on
the import or stuck somewhere?

The GUI layer manager shows the map needs cleaning for many (most? all?)
polygons when it eventually is imported, but that's to be addressed later.

You should see an information about its progress in the different cleaning steps (note that some cleaning is repeated).

If you are sure you do not want to do any polygon cleaning during import, you can use the -c flag. But you will have to handle the result with care.

Moritz

rshepard · May 29, 2020, 12:37pm

On Fri, 29 May 2020, Moritz Lennert wrote:

Importing such a large file can take a lot of time because of the cleaning in order to get it into GRASS GIS' topological format.

Moritz,

I assumed it would taka a while, but it seemed to be stuck. Perhaps because
that polygon was large, complex, and needed a lot of cleaning.

I think it really depends on the specific file in terms of geometry
complexity and cleanliness, so difficult to pre-determine. I regularly
launch large import jobs overnight.

Then that's what I'll do tonight: I'll start it running in screen before I
log off and let it do it's thing for as long as it wants.

You should see an information about its progress in the different cleaning
steps (note that some cleaning is repeated).

I was using the GUI because I needed to create a new location and have
forgotten how to create a new location and mapset from the command line.

If you are sure you do not want to do any polygon cleaning during import, you can use the -c flag. But you will have to handle the result with care.

Actually, I much prefer to let GRASS clean as it goes.

Thanks very much for the knowledge.

Stay well,

Rich

mlennert · May 29, 2020, 12:51pm

On 29/05/20 14:37, Rich Shepard wrote:

On Fri, 29 May 2020, Moritz Lennert wrote:

Importing such a large file can take a lot of time because of the cleaning in order to get it into GRASS GIS' topological format.

Moritz,

I assumed it would taka a while, but it seemed to be stuck. Perhaps because
that polygon was large, complex, and needed a lot of cleaning.

I think it really depends on the specific file in terms of geometry
complexity and cleanliness, so difficult to pre-determine. I regularly
launch large import jobs overnight.

Then that's what I'll do tonight: I'll start it running in screen before I
log off and let it do it's thing for as long as it wants.

You should see an information about its progress in the different cleaning
steps (note that some cleaning is repeated).

I was using the GUI because I needed to create a new location and have
forgotten how to create a new location and mapset from the command line.

grass --help is your friend

grass -c epsg:4326 GISDBASE/LOCATION

replace GISDBASE and LOCATION with the respective names

-c can also be used with a file:

-c /path/to/georeferenced/file

Another, untested, path for possibly speeding up import: use ogr2ogr with the -simplify option to first simplify the geometry, if that is possible in your case. Would be interesting to benchmark v.in.ogr alone against ogr2ogr -simply + v.in.ogr.

Moritz

rshepard · May 29, 2020, 1:19pm

On Fri, 29 May 2020, Moritz Lennert wrote:

grass --help is your friend

Moritz,

Good to know; I never tried this.

grass -c epsg:4326 GISDBASE/LOCATION
replace GISDBASE and LOCATION with the respective names
-c can also be used with a file:
-c /path/to/georeferenced/file

Thanks for the reminder.

Another, untested, path for possibly speeding up import: use ogr2ogr with
the -simplify option to first simplify the geometry, if that is possible
in your case. Would be interesting to benchmark v.in.ogr alone against
ogr2ogr -simply + v.in.ogr.

I'll consider doing this test. When I run a shell script, or the command for
a long running process, I use the 'time' tool with it.

Regards,

Rich

neteler · May 31, 2020, 3:01pm

On Fri, May 29, 2020 at 2:52 PM Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 29/05/20 14:37, Rich Shepard wrote:
> On Fri, 29 May 2020, Moritz Lennert wrote:

...

Another, untested, path for possibly speeding up import: use ogr2ogr
with the -simplify option to first simplify the geometry, if that is
possible in your case. Would be interesting to benchmark v.in.ogr alone
against ogr2ogr -simply + v.in.ogr.

ogr2ogr
-simplify <tolerance>
Distance tolerance for simplification. Note: the algorithm used
preserves topology per feature, in particular for polygon geometries,
but not for a whole layer.

... keep in mind that AFAIK this may damage the topology (i.e. gaps
and slivers may arise between polygons).
So, select the <tolerance> with care...

Markus

rshepard · May 31, 2020, 4:21pm

On Sun, 31 May 2020, Markus Neteler wrote:

ogr2ogr
-simplify <tolerance>
Distance tolerance for simplification. Note: the algorithm used
preserves topology per feature, in particular for polygon geometries, but
not for a whole layer.

Markus,

Thanks for confirming this approach.

... keep in mind that AFAIK this may damage the topology (i.e. gaps
and slivers may arise between polygons).
So, select the <tolerance> with care...

Given that I have no experience selecting tolerances for simplfy please
suggest what I should read to make an informed first guess.

Regards,

Rich

neteler · May 31, 2020, 6:50pm

Rich,

On Sun, May 31, 2020 at 6:31 PM Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Sun, 31 May 2020, Markus Neteler wrote:

> ogr2ogr
> -simplify <tolerance>
> Distance tolerance for simplification. Note: the algorithm used
> preserves topology per feature, in particular for polygon geometries, but
> not for a whole layer.

Markus,

Thanks for confirming this approach.

I didn't confirm at all
It was just an information or warning.

> ... keep in mind that AFAIK this may damage the topology (i.e. gaps
> and slivers may arise between polygons).
> So, select the <tolerance> with care...

Given that I have no experience selecting tolerances for simplfy please
suggest what I should read to make an informed first guess.

I'd stick to submeter but I don't know what data you are working with
nor what their resolution/scale is...

Markus

rshepard · May 31, 2020, 7:13pm

On Sun, 31 May 2020, Markus Neteler wrote:

I didn't confirm at all It was just an information or warning.

Markus,

Using ogr2ogr was what Moritz suggested.

I'd stick to submeter but I don't know what data you are working with
nor what their resolution/scale is...

This is what the *.prj file has to offer:

PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
PROJECTION["Mercator_Auxiliary_Sphere"],
PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],
PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]

How sub a submeter would be a good start?

Regards,

Rich

hellik · May 31, 2020, 8:46pm

Rich Shepard wrote

On Sun, 31 May 2020, Markus Neteler wrote:

I didn't confirm at all It was just an information or warning.

Markus,

Using ogr2ogr was what Moritz suggested.

I'd stick to submeter but I don't know what data you are working with
nor what their resolution/scale is...

This is what the *.prj file has to offer:

PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
PROJECTION["Mercator_Auxiliary_Sphere"],
PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],
PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]

How sub a submeter would be a good start?

is it

EPSG:3857 [1] [2]

?

keep in mind the scope of this projection is Web mapping and visualisation
applications, not heavy GIS processing.

from [1]

"Remarks: Uses spherical development of ellipsoidal coordinates. Relative to
WGS 84 / World Mercator (CRS code 3395) errors of 0.7 percent in scale and
differences in northing of up to 43km in the map (equivalent to 21km on the
ground) may arise. "

better to use a projection appropriate to your working area.

[1] http://epsg.io/3857
[2] https://en.wikipedia.org/wiki/Web_Mercator_projection

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

rshepard · May 31, 2020, 9:03pm

On Sun, 31 May 2020, Helmut Kudrnovsky wrote:

is it
EPSG:3857 [1] [2]
?

Helmut,

I've no idea. This dataset was downloaded from the Oregon Geospatial
Enterprise Office (clever name, eh?). The introductory page is here:
<https://www.oregon.gov/geo/Pages/sdlibrary.aspx>\.

Oregon provides data in three projections:

# Oregon state standard:
EPSG 2838 NAD83(HARN) <http://www.spatialreference.org/ref/epsg/2838/>
proj4: +proj=lcc +lat_1=46 +lat_2=44.33333333333334 +lat_0=43.66666666666666 +lon_0=-120.5 +x_0=2500000 +y_0=0 +ellps=GRS80 +units=m +no_defs

# Oregon lon/lat in Lambert Conformal Conic:
EPSG 2992 +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75 +lon_0=-120.5
+x_0=399999.9999984 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048
+no_defs

# Oregon lon/lat in WGS84.
EPSG 4326: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

I keep all Oregon spatial data using the first projection. But, sometimes a
dataset is in another projection. When I started importing it into
grass-7.9.dev I set the projection based on the .prj file and didn't see the
EPSG code it represented.

Regards,

Rich

hellik · May 31, 2020, 9:59pm

Rich Shepard wrote

On Sun, 31 May 2020, Helmut Kudrnovsky wrote:

is it
EPSG:3857 [1] [2]
?

Helmut,

I've no idea. This dataset was downloaded from the Oregon Geospatial
Enterprise Office (clever name, eh?). The introductory page is here:
<https://www.oregon.gov/geo/Pages/sdlibrary.aspx>.

Oregon provides data in three projections:

# Oregon state standard:
EPSG 2838 NAD83(HARN)
<http://www.spatialreference.org/ref/epsg/2838/>
proj4: +proj=lcc +lat_1=46 +lat_2=44.33333333333334
+lat_0=43.66666666666666 +lon_0=-120.5 +x_0=2500000 +y_0=0 +ellps=GRS80
+units=m +no_defs

# Oregon lon/lat in Lambert Conformal Conic:
EPSG 2992 +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75 +lon_0=-120.5
+x_0=399999.9999984 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048
+no_defs

# Oregon lon/lat in WGS84.
EPSG 4326: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

I keep all Oregon spatial data using the first projection. But, sometimes
a
dataset is in another projection. When I started importing it into
grass-7.9.dev I set the projection based on the .prj file and didn't see
the
EPSG code it represented.

PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],
PROJECTION["Mercator_Auxiliary_Sphere"], <=
PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],
PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]

------------------

C:\>projinfo EPSG:3857
PROJ.4 string:
+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1
+units=m +nadgrids=@null +wktext +no_defs +type=crs

WKT2:2019 string:
PROJCRS["WGS 84 / Pseudo-Mercator",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["Popular Visualisation Pseudo-Mercator",
        METHOD["Popular Visualisation Pseudo Mercator",
            ID["EPSG",1024]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["World - 85┬░S to 85┬░N"],
        BBOX[-85.06,-180,85.06,180]],
    ID["EPSG",3857]]

------------------

C:\>projinfo EPSG:2838
PROJ.4 string:
+proj=lcc +lat_0=43.6666666666667 +lon_0=-120.5 +lat_1=46
+lat_2=44.3333333333333 +x_0=2500000 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs +type=crs

WKT2:2019 string:
PROJCRS["NAD83(HARN) / Oregon North",
    BASEGEOGCRS["NAD83(HARN)",
        DATUM["NAD83 (High Accuracy Reference Network)",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4152]],
    CONVERSION["SPCS83 Oregon North zone (meters)",
        METHOD["Lambert Conic Conformal (2SP)",
            ID["EPSG",9802]],
        PARAMETER["Latitude of false origin",43.6666666666667,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8821]],
        PARAMETER["Longitude of false origin",-120.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8822]],
        PARAMETER["Latitude of 1st standard parallel",46,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8823]],
        PARAMETER["Latitude of 2nd standard parallel",44.3333333333333,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8824]],
        PARAMETER["Easting at false origin",2500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8826]],
        PARAMETER["Northing at false origin",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8827]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["USA - Oregon - SPCS - N"],
        BBOX[43.95,-124.17,46.26,-116.47]],
    ID["EPSG",2838]]

------------------
C:\>projinfo EPSG:2992
PROJ.4 string:
+proj=lcc +lat_0=41.75 +lon_0=-120.5 +lat_1=43 +lat_2=45.5
+x_0=399999.9999984 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=ft
+no_defs +type=crs

WKT2:2019 string:
PROJCRS["NAD83 / Oregon GIC Lambert (ft)",
    BASEGEOGCRS["NAD83",
        DATUM["North American Datum 1983",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4269]],
    CONVERSION["Oregon GIC Lambert (International feet)",
        METHOD["Lambert Conic Conformal (2SP)",
            ID["EPSG",9802]],
        PARAMETER["Latitude of false origin",41.75,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8821]],
        PARAMETER["Longitude of false origin",-120.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8822]],
        PARAMETER["Latitude of 1st standard parallel",43,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8823]],
        PARAMETER["Latitude of 2nd standard parallel",45.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8824]],
        PARAMETER["Easting at false origin",1312335.958,
            LENGTHUNIT["foot",0.3048],
            ID["EPSG",8826]],
        PARAMETER["Northing at false origin",0,
            LENGTHUNIT["foot",0.3048],
            ID["EPSG",8827]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["foot",0.3048]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["foot",0.3048]],
    USAGE[
        SCOPE["unknown"],
        AREA["USA - Oregon"],
        BBOX[41.98,-124.6,46.26,-116.47]],
    ID["EPSG",2992]]

------------------
C:\>projinfo EPSG:4326
PROJ.4 string:
+proj=longlat +datum=WGS84 +no_defs +type=crs

WKT2:2019 string:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]

------------------

using your projection info by the nice GDAL's testepsg tool:

D:\testproj>testepsg projinfo_rich.prj
Validate Succeeds.
WKT[projinfo_rich.prj] =
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Mercator_1SP"],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0
+x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs"]]

Simplified WKT[projinfo_rich.prj] =
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Mercator_1SP"],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1]]

Old Style WKT[projinfo_rich.prj] = PROJCS["WGS 84 /
Pseudo-Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]],PROJECTION["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1]]
ESRI'ified WKT[projinfo_rich.prj] =
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
    GEOGCS["GCS_WGS_1984",
        DATUM["D_WGS_1984",
            SPHEROID["WGS_1984",6378137.0,298.257223563]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Mercator_Auxiliary_Sphere"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",0.0],
    PARAMETER["Standard_Parallel_1",0.0],
    PARAMETER["Auxiliary_Sphere_Type",0.0],
    UNIT["Meter",1.0]]
PROJ.4 rendering of [projinfo_rich.prj] = +proj=merc +a=6378137 +b=6378137
+lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext
+no_defs

-----------

it seems the projection of your data (+proj=merc) doesn't correpond to the
Enterprise Office's projections you mentioned (+proj=lcc, +proj=lcc,
+proj=longlat)

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

rshepard · May 31, 2020, 11:04pm

On Sun, 31 May 2020, Helmut Kudrnovsky wrote:

it seems the projection of your data (+proj=merc) doesn't correpond to the
Enterprise Office's projections you mentioned (+proj=lcc, +proj=lcc,
+proj=longlat)

Helmut,

That's true. So I created a new location for this huge shapefile. The issue
has nothing to do with the projection but the time to import it. And Moritz
and Markus N. both suggested using ogr2ogr with a simplify value. My
question is how to select that value for a first try.

Thanks very much,

Rich

hellik · June 1, 2020, 5:17am

Rich Shepard wrote

On Sun, 31 May 2020, Helmut Kudrnovsky wrote:

it seems the projection of your data (+proj=merc) doesn't correpond to
the
Enterprise Office's projections you mentioned (+proj=lcc, +proj=lcc,
+proj=longlat)

Helmut,

That's true. So I created a new location for this huge shapefile. The
issue
has nothing to do with the projection but the time to import it. And
Moritz
and Markus N. both suggested using ogr2ogr with a simplify value. My
question is how to select that value for a first try.

Thanks very much,

Rich
_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

I think it is EPSG 3857.

Have you read the wiki entry (from the link I mentioned in a previous mail)?

taken from there:

"While the Web Mercator's formulas are for the spherical form of the
Mercator, geographical coordinates are required to be in the WGS 84
ellipsoidal datum. This discrepancy causes the projection to be slightly
non-conformal. General lack of understanding that the Web Mercator differs
from standard Mercator usage has caused considerable confusion and
misuse.[4]:87 For all these reasons, the United States Department of Defense
through the National Geospatial-Intelligence Agency has declared this map
projection to be unacceptable for any official use.[7]"

thus I suggest, as already before, to use another projection appropriate for
your working area.

regarding values for ogr2ogr, maybe ask also on the GDAL mailing list .

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

rshepard · June 1, 2020, 12:50pm

On Sun, 31 May 2020, Helmut Kudrnovsky wrote:

thus I suggest, as already before, to use another projection appropriate
for your working area.

Helmut,

I haven't clearly communicated. I don't care about the projection of the
source file as long as I can import it into GRASS. Once imported I reproject
it to my state-storage location where it can be used by reprojection
specific to each project. I have no need to use it in its original
projection.

Regards,

Rich