[GRASS-user] syncing two locations

M S mseibel at gmail.com
Fri May 23 06:17:02 EDT 2008

The best solution does seem to be the multiple mapsets, from a single
shared location.  That is really a great way to distribute the
processing, especially given the flexibility of mapsets in a location.


On 5/22/08, Markus Neteler <neteler at osgeo.org> wrote:
> (I take liberty to cc the list again for discussion)
> On Thu, May 22, 2008 at 3:59 PM, M S <mseibel at gmail.com> wrote:
>> That is cool.  I will definitely check out the wiki page.
>> Perhaps I am not using locations or more specifically mapsets as
>> efficiently as I could be.  If I were to use a single location, but
>> with different mapsets, would there be issues with changing the region
>> boundary and/or the cell resolution?
> not at all, all mapsets are independent.
>> For example, in my main area of interest (basin) there were areas I
>> needed to do finer detailed analysis, going from 25 foot cells to 3
>> foot cells (r.in.xyz + r.report helped me find this optimal cell size,
>> great stuff!), would this be an issue within the same location, but
>> using a different mapset?  I had thought that region settings applied
>> to a location.
> no :) to a mapset!
> I have added
> http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#Background
>> I had (perhaps not the best choice, copied the location to another
>> workstation) and changed the region resolution and boundary, and then
>> ran more detailed analysis.
> If you do it serially, no problem. Otherwise it will conflict.
>> Under this scenario, does it still make sense to use a single shared
>> location?
> Most likely.
>> One problem I foresee is with vectors using a single
>> sqlite.db file,
> That's true. You cannot write simultaneously to the same sqlite.db file.
> http://en.wikipedia.org/wiki/SQLite
> "A write access can only be satisfied if no other accesses are
> currently being serviced, otherwise the write access fails with an
> error code (or can automatically be retried until a configurable
> timeout expires). This concurrent access situation would change when
> dealing with temporary tables.
> "
> But just use different names, so multiple sqlite.db files?
>> in two different locations and then getting the vector
>> database out of sync, and unable to rectify this with syncing the
>> locations.  It seems that reprojecting the data into the location is
>> one way to deal with this single DB issue.
> I feel that it's making things worse.
>> Most all of what I'm doing
>> is time-consuming raster analysis though, and on the first sync,
>> things seemed to work as expected.
> OK fine.
> Please let's collect ideas in the wiki how to deal with vector data
> and related DBs when processing in parallel.
> Markus
>> Mark
>> On 5/21/08, Markus Neteler <neteler at osgeo.org> wrote:
>>> On Wed, May 21, 2008 at 5:58 PM, M S <mseibel at gmail.com> wrote:
>>>> I have two GRASS workstations performing various lidar and basin
>>>> operations.  My idea was to distribute the processing on various
>>>> machines.
>>>> As new data gets created in each location on each computer, when all
>>>> processes are done, I would like to re-sync the locations to be the
>>>> same.
>>> I did massive MODIS map processing on a cluster and used
>>> one location only in a shared network directory. Therein multiple
>>> mapsets with a final g.copy job to the mapset keeping the results.
>>> I have documented it here:
>>> http://grass.osgeo.org/wiki/Parallel_GRASS_jobs#PBS
>>> Markus
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
> --
> Open Source Geospatial Foundation
> http://www.osgeo.org/
> http://www.grassbook.org/

More information about the grass-user mailing list