I see that 'v.in.ascii -help' says that we should try using the -t or the
-r flag if the data to import is too large to avoid memory problems. I
have a pretty large bathymetry (GEBCO) data to import of ~220 Mb, so I
tried the -t flag first, and after a few minutes v.in.ascii is using huge
amounts of memory, blocking the system anyway. I haven't tried using the
-r flag to import only a subset, which would mean import the whole file in
several calls and merge the maps afterwards. Before I try that, I wanted
to ask what other users are doing in these cases. Thanks in advance for
any suggestions.
I see that 'v.in.ascii -help' says that we should try using the -t or
the -r flag if the data to import is too large to avoid memory
problems. I have a pretty large bathymetry (GEBCO) data to import of
~220 Mb, so I tried the -t flag first, and after a few minutes
v.in.ascii is using huge amounts of memory, blocking the system
anyway. I haven't tried using the -r flag to import only a subset,
which would mean import the whole file in several calls and merge the
maps afterwards. Before I try that, I wanted to ask what other users
are doing in these cases. Thanks in advance for any suggestions.
Use r.in.xyz
the vector engine has problems trying to maintain topology for more than
1-3 million features.
> IIUC, this will create a raster, calculating a statistic for points
> in each grid cell defined in my current region. So the trick is to
> set the grid resolution the same as the input, and then set the
> statistic to "mean" (hence returning same value as the point)
> correct? Thanks.
Yes.
This does seem right, although something's odd with the display; it
suggests some land values are the same as those on the ocean. I
presume this has to do with the color function.
r.colors rules for etopo2, srtm, and terrain should all break at 0.
The "elevation" and default "rainbow" rule do not.
I'd also like to "filter" (exclude) depth values > 0, but haven't
found the right module.
r.in.xyz:
zrange Filter range for z data (min,max)
or use r.maplcalc:
r.mapcalc 'newmap = if(oldmap > 0, null(), oldmap)'
r.mapcalc 'sea_mask = if(elev <= 0)'
On Fri, 23 Mar 2007 16:36:58 +1200,
Hamish <hamish_nospam@yahoo.com> wrote:
[...]
r.colors rules for etopo2, srtm, and terrain should all break at 0. The
"elevation" and default "rainbow" rule do not.
Thanks. Using etopo2 was exactly what I needed.
It seems some problem occurred when reprojecting the raster from the
geographic location to my Albers equal area projection location, because
values for lat 70 or thereabouts are missing
(http://members.shaw.ca/sluque/earctic.png). These values are definitely
there in the original geographic location. Maybe I'm still not setting an
appropriate projection:
-PROJ_INFO-------------------------------------------------
name : Albers Equal Area
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : aea
ellps : wgs84
a : 6378137.0000000000
es : 0.0066943800
f : 298.2572235630
lat_0 : 65.0000000000
lat_1 : 70.0000000000
lat_2 : 75.0000000000
lon_0 : -130.0000000000
x_0 : 0.0000000000
y_0 : 0.0000000000
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1.0
It seems some problem occurred when reprojecting the raster from the
geographic location to my Albers equal area projection location,
because values for lat 70 or thereabouts are missing
(http://members.shaw.ca/sluque/earctic.png). These values are
definitely there in the original geographic location.
Are you 100% sure? test with:
g.region rast=bathy_map
r.univar bathy_map
and check the NULL cell count.
Maybe I'm still not setting an appropriate projection:
-PROJ_INFO-------------------------------------------------
name : Albers Equal Area
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : aea
ellps : wgs84
a : 6378137.0000000000
es : 0.0066943800
f : 298.2572235630
lat_0 : 65.0000000000
lat_1 : 70.0000000000
lat_2 : 75.0000000000
lon_0 : -130.0000000000
x_0 : 0.0000000000
y_0 : 0.0000000000
-PROJ_UNITS------------------------------------------------
unit : meter
units : meters
meters : 1.0
If the error is at 70N, and lat_1 = 70N, perhaps there is a bug there?
If so it would be a very rare one, as this code is very well tested and
AEA is a pretty common projection.
My gut guess is some sort of aliasing problem with r.in.xyz where the
g.region settings at import do not exactly match the original data's
grid resolution and some cells do not get any data. Try r.in.xyz with
method=n and check for cells with 0 or 2 data points in them around the
problematic 70N.
On Fri, 23 Mar 2007 19:09:14 +1200,
Hamish <hamish_nospam@yahoo.com> wrote:
[...]
My gut guess is some sort of aliasing problem with r.in.xyz where the
g.region settings at import do not exactly match the original data's
grid resolution and some cells do not get any data.
You were right, the GEBCO data doesn't seem to have the nominal 1 minute
resolution, and setting it to slightly less than that (1 min 1 sec) solved
the issue. The result looks nice
(http://members.shaw.ca/sluque/arctic.png). Thanks for your advice!
On Fri, 23 Mar 2007 16:36:58 +1200,
Hamish <hamish_nospam@yahoo.com> wrote:
[...]
r.colors rules for etopo2, srtm, and terrain should all break at 0. The
"elevation" and default "rainbow" rule do not.
Thanks. Using etopo2 was exactly what I needed.
It seems some problem occurred when reprojecting the raster from the
geographic location to my Albers equal area projection location,
Although you have solved the problem, as I can see from the following
posts, you might consider reprojecting vector points *first* into
Albers, using cs2cs (PROJ.4 reprojection tool), then import the
reprojected points into Albers location with r.in.xyz. If you try that,
can you post to the list if rasters resulting from either approach
differ somewhat?
Seb wrote:
> On Fri, 23 Mar 2007 16:36:58 +1200,
> Hamish <hamish_nospam@yahoo.com> wrote:
>
> [...]
>
>> r.colors rules for etopo2, srtm, and terrain should all break at 0.
> The
>> "elevation" and default "rainbow" rule do not.
>
> Thanks. Using etopo2 was exactly what I needed.
>
> It seems some problem occurred when reprojecting the raster from the
> geographic location to my Albers equal area projection location,
Although you have solved the problem, as I can see from the following
posts, you might consider reprojecting vector points *first* into
Albers, using cs2cs (PROJ.4 reprojection tool), then import the
reprojected points into Albers location with r.in.xyz. If you try
that, can you post to the list if rasters resulting from either
approach differ somewhat?
to do that, with ascii x,y,z file in the AEA location:
