[GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

I will contact Aruna to check about the videos...

I just repeated inefficient from:



On 5 March 2014 14:30, Sören Gebbert <soerengebbert at googlemail.com> wrote:

> Hi Yann,
>
> 2014-03-05 9:48 GMT+01:00 Yann Chemin <ychemin at gmail.com>:
> > Yes Soeren, such a pity, I missed all your temporal fun!
> > As usual, have to do it the hard way...
>
> I am sorry for that. Are the videos of the workshop ready yet?
>
> >
> > Thanks,
> > I will set up the input file, inefficient, but my data is not regular in
> > time...
>
> Well, TGRASS was designed to support irregular time, hence using an
> input file with thousands of maps with irregular time stamps is the
> most efficient way to register IMHO.
>
> Why is it in your case inefficient?
>
> Cheers
> Soeren
>
> >
> >
> >
> > On 5 March 2014 14:15, Sören Gebbert <soerengebbert at googlemail.com>
> wrote:
> >>
> >> Hi,
> >> such a pity you were not in the TGIS workshop.
> >> However, there can be gaps between time intervals.
> >> Hence the end time of a time interval can be start time of a potential
> >> successor or the start time of a gap.
> >> But gaps are not stored explicitly, they are computed by topological
> >> analysis
> >>
> >> I would suggest that you create an input text file that lists all maps
> >> with time stamps that should be registered
> >> If you call t.register for each single map the registration will be
> >> very inefficient and slow
> >> Example of an input file with gaps between map intervals:
> >> mapA|2001-05-10|2001-05-11
> >> mapB|2001-05-15|2001-05-16
> >>
> >> Best regards
> >> Soeren
> >>
> >> 2014-03-05 9:29 GMT+01:00 Yann Chemin <ychemin at gmail.com>:
> >> > Thank you Soeren,
> >> >
> >> > If I want to register an irregular set of daily maps (missing days),
> >> > will
> >> > the end date need to be the next day (say 5 days after this image, 2
> >> > days
> >> > after in the next image)?
> >> >
> >> > Cheers,
> >> > Yann
> >> >
> >> >
> >> > On 5 March 2014 12:14, Sören Gebbert <soerengebbert at googlemail.com>
> >> > wrote:
> >> >>
> >> >> Hi Yann,
> >> >> if you need support for time zones you have to use postgresql as
> >> >> backend. Unfortunately sqlite does not support time zones. A work
> >> >> around would be to ignore the time zone and use t.shift to temporally
> >> >> shift the created STRDS by 5h and 30 min to UTC time after
> registering
> >> >> the maps. I should notice this in the help page, i don't know why i
> >> >> missed that ..???!!!
> >> >>
> >> >> The next thing is that TGRASS uses time intervals in which the end
> >> >> time is not part of the time interval, but the start time of a
> >> >> successor. That means that you do not need to know how many days in a
> >> >> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
> >> >>
> >> >> Best regards
> >> >> Soeren
> >> >>
> >> >> 2014-03-05 6:36 GMT+01:00 Yann Chemin <ychemin at gmail.com>:
> >> >> > Hi,
> >> >> >
> >> >> > input line is:
> >> >> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00
> +0530"
> >> >> > end="2004
> >> >> > -05-10 23:59:59 +0530"
> >> >> >
> >> >> > temporal says:
> >> >> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> >> >> > convert_timestamp
> >> >> >     hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> >> >> > ValueError: invalid literal for int() with base 10: '00+05'
> >> >> >
> >> >> > Manual says following format accepted:
> >> >> > start=string
> >> >> > Valid start date and time of the first map. Format absolute time:
> >> >> > "yyyy-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> >> >> > end=string
> >> >> > Valid end date and time of all map. Format absolute time:
> "yyyy-mm-dd
> >> >> > HH:MM:SS +HHMM", relative time is of type integer).
> >> >> >
> >> >> > yann
> >> >> > --
> >> >> > ----
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > ----
> >
> >
> >
> >
> > --
> > ----
>



-- 
----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140305/a492056c/attachment.html>