3

I have in my Attribute Table two columns, one with dates and one with times (running in increments of one hour), so each feature has a basically a date and hour. My date and time columns.

The example above shows multiple features at one point in time, but there are thousands of features and about 30 hours/timesteps.

I'm trying to get QGIS' Time Manager to read both into itself.

I tried creating a new column of data. I created a 22-character wide string and populate the column with

concat("DATE",' ', "TIME")

and it outputs the following

The output columns.

The second column I used

concat("DATE",'T', "TIME")

just to try this way as well.

So the output looks okay and I try to load the layer into QGIS, choosing one of my new columns. It defaults to "SECONDS FROM EPOCH (float)" and the slider starts at the beginning of UNIX time, 1970-01-01.

When I try to force Time Manager to '%Y-%m-%d %H:%M:%S' or '%Y-%m-%dT%H:%M:%S', it fails and gives me the following error.

The error from Time Manager

I saw this question from several months ago that seems to be similar to my problem but it doesn't look like they got a solution. Wondering if anyone can help me? I thought strings would work but perhaps I'm missing something.

EDIT: Here are the fields I have and their properties. Is there a difference between 'String' and 'string'? I created all the original fields in Fortran and I notice the new fields I made in QGIS are labelled as 'string'.

My fields and their types.

Interestingly, if I set Time Manager to treat the data as "SECONDS FROM EPOCH (float)" (i.e. manually setting it, rather than letting it figure it out), I get the following error

Odd error.

Some data to reproduce the issue can be found here, I'll leave it for about a day.

  • If I remember correctly, it required a couple of - complex cause to reproduce the issue DPSSpatial had posted. I mean I could see it when (1) using Spatialite or Virtual Field and (2) choosing wrong field in the settings. As you see, (2)nd did not apply to DPSSpatial's case apparently. Perhaps your OS environment and/or data source type have something similar? – Kazuhito Jul 31 '18 at 11:01
  • I saw your post on their question, I'm definitely selecting the correct fields and layer. I've also updated the post with the field properties and types. I've also been using GIS for only half a year, I don't really know what Spatialite is and I tried this with Virtual Fields but the results are the same. In the OP, those fields are not virtual. – stackman Jul 31 '18 at 16:18
  • Thanks for your clarification, I do agree both cases are robust and nothing about human errors. But it is still challenging without reproducible examples. Is it possible for you to share a dummy example derived from your FORTRAN work? (...not your real data, just a sample; and only if it is not too much trouble) – Kazuhito Aug 1 '18 at 11:36
  • Thanks for the reply. Of course, I'm embarrassed I didn't sooner, in my hurry to make some deadlines. I also found another (roundabout) solution, which I will post as an answer, but I won't accept it for now. The OP has been updated with a Dropbox link. – stackman Aug 2 '18 at 16:10
  • Your test data is missing the .dbf part of the ShapeFile. – HeikkiVesanto Aug 2 '18 at 16:32
0

This works fine for me.

But bearing in mind that it is really slow.

To create the date_time field I used:

"DATE" || ' ' || "TIME"

Double quote signify fields and single quotes text.

After creating that field, turn off editing and allow it to save. This took a very long time for me, with 500k features. I let it run overnight.

Then it worked fine in TimeManager, although slowly.

Exported images can be found here:

https://imgur.com/a/XUcAd57

  • 1
    I will accept this answer. I have not tried it as I already changed my software a bit and found another solution that works better for me, as mentioned in my answer. Thanks for your help! – stackman Aug 15 '18 at 19:38
3

The solution that I managed to implement involved the process with which I write these files. So the solution is a roundabout method and doesn't directly address the issue.

Initially, I was writing a separate date and time column (of type String), 10 bytes wide and 8 bytes wide, respectively. I was under the impression the Shapefile format restricts database fields to a width of 10 bytes. It turns out that, for string/char at least, I was able to output a single column of both Date and Time, 19 bytes wide. Time Manager had no qualms about reading this column, even though the other methods I tried in the OP resulted in identical output (including when I checked and compared the binary of each .dbf).

So in the end I found a solution to my problem but it skirts the actual issue.

  • ShapeFile column names are restricted to 10 characters but a string field can contain up to 255. – HeikkiVesanto Aug 2 '18 at 16:29
  • So it seems. I must have misread or something the first time I was learning this. Thanks fr the info! – stackman Aug 2 '18 at 16:44
  • Great. I'm glad you solved it...yes something might be hanging in the air...not sure. btw Many thanks to @HeikkiVesanto for great help! – Kazuhito Aug 3 '18 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.