[GRASS-user] syncing two locations

[M S]

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.


Mark

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/
>