[GRASS-dev] Re: creating location from the command line

Ivan Shmakov ivan at theory.asu.ru
Sun Apr 6 14:08:16 EDT 2008


>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

[...]

 >>> GRASS_BATCH_JOB is a bit of a hack. You would be better off
 >>> bypassing Init.sh altogether.

 >> I wonder, is there a way to create locations non-interactively?

 > g.proj -c location=...

	ACK, thanks.

 >> Or, does GRASS use architecture-dependent formats within its
 >> locations?

 > AFAICT, the core library functions use portable formats; however:

 > 1. Individual modules can write whatever they want under cell_misc.
 > E.g. the fftreal and fftimag files written by i.fft are in host byte
 > order.

	Shouldn't these be fixed?

 > 2. Even when portable formats are used, the precise choice of format
 > may be platform-specific.

 > E.g. the row indices in the raster files can be 4 or 8 bytes,
 > depending up the size of off_t in the code which creates them. The
 > actual size is stored in the file, and the code which reads them can
 > handle the case where the size used in the file doesn't match the
 > off_t used in the code, so long as the actual values fit within an
 > off_t.

	Why not to use 8-byte values unconditionally when writing a
	raster?  (Retaining the ability to read 4-byte values for the
	sake of compatibility.)

	If several formats need to be supported, there should probably
	be a way to choose one at the run time.  (Say, an environment
	variable.)  In particular, this will allow the reading of all of
	these formats to be tested with a single GRASS build.

 > For text formats, there's the issue that the MSVCRT version of
 > printf's %e and %g always use a 3-digit exponent, while other
 > implementations follow ANSI and only use 3 digits where necessary.

	If there's only a small number of ways to store the result,
	several checksums may be specified for the file.

	If the result is largely unpredicable, then it shouldn't
	probably be checked with the test suite in the first place.
	E. g., there seems to be a little point of checking the vector
	created by the current version of `v.random'.



More information about the grass-dev mailing list