Dear all,
i would like to create a new branch from trunk to integrate the
suggested temporal extension[1].
The integration of the time dimension into grass7 requires changes in
the underlying libraries, several modules, additional files and config
entries in mapsets and the $GISBASE/etc directory. Main goal is an
integration approach without breaking any compatibility in the API or
module usage.
I do not want to work on a private or google code copy, but to enable
other developers to follow or join the integration progress and to
test the implementation.
I think the effort to implement time in grass7 to a usable state will
take more than 6 months. In case it is stable, usable and all
developer agree, we can merge the changes back into the main trunk of
grass7.
I will always try to merge changes from trunk into the new branch to
keep it be up to date.
My questions are:
* Do i have the agreement of the developer and the PSC to create a new
branch for time integration?
* What do i have to consider creating a new branch?
** Is something like this:
svn copy https://svn.osgeo.org/grass/grass/trunk
https://svn.osgeo.org/grass/grass/branches/temporal_grass7 -m "New
branch for temporal GIS implementation"
sufficient?
Thanks and best regards
Soeren
[1] http://trac.osgeo.org/grass/wiki/Grass7/TemporalExtension
On Mon, Aug 22, 2011 at 11:10 AM, Soeren Gebbert
<soerengebbert@googlemail.com> wrote:
Dear all,
i would like to create a new branch from trunk to integrate the
suggested temporal extension[1].
The integration of the time dimension into grass7 requires changes in
the underlying libraries, several modules, additional files and config
entries in mapsets and the $GISBASE/etc directory. Main goal is an
integration approach without breaking any compatibility in the API or
module usage.
I would try to avoid having yet another branch, three is maybe already
one too much. IMHO, the most important question is whether we want to
add the time dimension in GRASS. If this finds sufficient support, I
would rather opt to modify trunk directly because compatibility will
be maintained when adding the temporal extension and trunk can be used
as before. In this case, another branch may cause more trouble than
good.
+1 for adding time dimension
my2c
Markus M
I do not want to work on a private or google code copy, but to enable
other developers to follow or join the integration progress and to
test the implementation.
I think the effort to implement time in grass7 to a usable state will
take more than 6 months. In case it is stable, usable and all
developer agree, we can merge the changes back into the main trunk of
grass7.
I will always try to merge changes from trunk into the new branch to
keep it be up to date.
My questions are:
* Do i have the agreement of the developer and the PSC to create a new
branch for time integration?
* What do i have to consider creating a new branch?
** Is something like this:
svn copy https://svn.osgeo.org/grass/grass/trunk
https://svn.osgeo.org/grass/grass/branches/temporal_grass7 -m "New
branch for temporal GIS implementation"
sufficient?
Thanks and best regards
Soeren
[1] http://trac.osgeo.org/grass/wiki/Grass7/TemporalExtension
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2011/8/22 Markus Metz <markus.metz.giswork@googlemail.com>:
I would try to avoid having yet another branch, three is maybe already
one too much. IMHO, the most important question is whether we want to
add the time dimension in GRASS. If this finds sufficient support, I
would rather opt to modify trunk directly because compatibility will
be maintained when adding the temporal extension and trunk can be used
as before. In this case, another branch may cause more trouble than
good.
+1 for adding time dimension
bearing in mind the number of active GRASS developers I agree with MarkusM.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Aug 22, 2011 at 7:19 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/8/22 Markus Metz <markus.metz.giswork@googlemail.com>:
I would try to avoid having yet another branch, three is maybe already
one too much. IMHO, the most important question is whether we want to
add the time dimension in GRASS. If this finds sufficient support, I
would rather opt to modify trunk directly because compatibility will
be maintained when adding the temporal extension and trunk can be used
as before. In this case, another branch may cause more trouble than
good.
+1 for adding time dimension
bearing in mind the number of active GRASS developers I agree with MarkusM.
I also agree to not create a new branch but modify trunk directly.
In our discussions during Soeren's seminar at FEM
http://gis.cri.fmach.it/news/20/15/Seminar-announcement-S-Gebbert-10-Aug-2011---FEM---Adding-the-time-dimension-to-GRASS-GIS-for-field-based-applications-A-unified-snapshot-approach/
recently he confirmed that no relevant API changes are expected, so things
should not break (although they are allowed to in trunk).
Markus
Hi,
thank all of you for your suggestions and support.
The reason why i would like to create a branch is the experimental
character of the implementation.
I have a big picture about what is needed, but no detailed
implementation concept. I would like to experiment
with different implementation approaches. This is IMHO nothing to be
done in trunk, as it might break compilation
or several modules because of library changes ... .
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
I also agree to not create a new branch but modify trunk directly.
In our discussions during Soeren's seminar at FEM
http://gis.cri.fmach.it/news/20/15/Seminar-announcement-S-Gebbert-10-Aug-2011---FEM---Adding-the-time-dimension-to-GRASS-GIS-for-field-based-applications-A-unified-snapshot-approach/
I can send the (modified) presentation slides in a private mail to
anyone who is interested (please contact me). The slides are not yet
ready for publishing.
Best regards
Soeren
I'd be interested in seeing what you have in mind. It's hard to say whether or not a separate branch of GRASS is desirable. To me it seems like a better idea to discuss a set of time-related concepts in the dev list to see how these could best be integrated into GRASS. Adding and testing features a few at a time in the development trunk, with input from other devs seems to me like a better way to proceed than to start something completely new that would then be hard to merge back in later.
Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
On Aug 22, 2011, at 2:07 PM, Soeren Gebbert wrote:
Hi,
thank all of you for your suggestions and support.
The reason why i would like to create a branch is the experimental
character of the implementation.
I have a big picture about what is needed, but no detailed
implementation concept. I would like to experiment
with different implementation approaches. This is IMHO nothing to be
done in trunk, as it might break compilation
or several modules because of library changes ... .
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
I also agree to not create a new branch but modify trunk directly.
In our discussions during Soeren's seminar at FEM
http://gis.cri.fmach.it/news/20/15/Seminar-announcement-S-Gebbert-10-Aug-2011---FEM---Adding-the-time-dimension-to-GRASS-GIS-for-field-based-applications-A-unified-snapshot-approach/
I can send the (modified) presentation slides in a private mail to
anyone who is interested (please contact me). The slides are not yet
ready for publishing.
Best regards
Soeren
Hi,
2011/8/22 Soeren Gebbert <soerengebbert@googlemail.com>:
The reason why i would like to create a branch is the experimental
character of the implementation.
I have a big picture about what is needed, but no detailed
implementation concept. I would like to experiment
with different implementation approaches. This is IMHO nothing to be
done in trunk, as it might break compilation
or several modules because of library changes ... .
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
in this case I could imagine special branch but only for a short-term
period, in other words merge to trunk ASAP.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Tue, Aug 23, 2011 at 8:57 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/8/22 Soeren Gebbert <soerengebbert@googlemail.com>:
The reason why i would like to create a branch is the experimental
character of the implementation.
...
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
in this case I could imagine special branch but only for a short-term
period, in other words merge to trunk ASAP.
Soeren, would you be able to keep "your" branch in sync with the pace
of changes happening in trunk?
Markus
Hi,
2011/8/23 Markus Neteler <neteler@osgeo.org>:
The reason why i would like to create a branch is the experimental
character of the implementation.
...
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
in this case I could imagine special branch but only for a short-term
period, in other words merge to trunk ASAP.
Soeren, would you be able to keep "your" branch in sync with the pace
of changes happening in trunk?
Thats the idea, to have a temporary trunk for time integration being
in sync with the main trunk. So the
merge of the temporal extension into trunk will be much easier.
The branch should only exist for experimenting and rapid development
and merged ASAP.
Best regards
Soeren
On Tue, Aug 23, 2011 at 10:32 AM, Soeren Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
2011/8/23 Markus Neteler <neteler@osgeo.org>:
The reason why i would like to create a branch is the experimental
character of the implementation.
...
The goal is not to break grass and its functionality, but as i am not
absolutely sure about the implementation, i can not assure this.
Using trunk i must be much more careful and disciplined .... making it
harder to be creative.
in this case I could imagine special branch but only for a short-term
period, in other words merge to trunk ASAP.
Soeren, would you be able to keep "your" branch in sync with the pace
of changes happening in trunk?
Thats the idea, to have a temporary trunk for time integration being
in sync with the main trunk. So the
merge of the temporal extension into trunk will be much easier.
I had a private branch of trunk for more than a year when developing
and testing new vector topology. It was not always easy to keep it
working, although I only had to svn up to get in sync with the
official trunk. This is not so easy when creating a real branch of
trunk in svn. But if you feel more comfortable with a separate branch
for experimenting then do it. I wanted to warn, but of course will
assist you whatever your decision.
Markus M
The branch should only exist for experimenting and rapid development
and merged ASAP.
Best regards
Soeren
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
[snip]
I had a private branch of trunk for more than a year when developing
and testing new vector topology. It was not always easy to keep it
working, although I only had to svn up to get in sync with the
official trunk. This is not so easy when creating a real branch of
trunk in svn. But if you feel more comfortable with a separate branch
for experimenting then do it. I wanted to warn, but of course will
assist you whatever your decision.
After some experimenting and the development of simple prototypes
(getting very frustrated with the db library ... ) i decided to use
python for all the temporal logic, library and modules. The
modification in GRASS core libraries will be minimized. Only a few C
library functions are planed in the future, implementing the
INSERT/UPDATE/DELETE SQL queries for raster, vector and raster3d maps
in the location specific time and metadata database.
The consequence is:
* Using sqlite3 exclusively, no support for other databases as backend
(Unfortunately the implementation of trigger and temporal logic is
database specific ...)
* Implementation of all the temporal logic in python
* Using an OO approach to reflect the theory of generalized fields
[Liu and Goodchild 2008]
* Using sqlite3 python library directly to have full datatype support
and python based sqlite3 user functions
* Using a location wide database rather than a mapset specific one, to
store the temporal and metadata information for all mapsets, primary
key will be "name@mapset"
Because of the minimized footprint of this approach in the GRASS core
libraries, i decided to implement the temporal GIS extension in trunk.
So no new branch is needed.
Thanks for all your suggestions and comments.
Cheers
Soeren
Markus M
The branch should only exist for experimenting and rapid development
and merged ASAP.
Best regards
Soeren
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev