View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000144 | GeoSetter | Image Data | public | 2008-01-21 08:48 | 2008-02-21 22:21 |
| Reporter | ingvar | Assigned To | Friedemann | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.2.5 release | ||||
| Target Version | Fixed in Version | 2.3.2 beta | |||
| Summary | 0000144: Wrong time zone from Webservice | ||||
| Description | I have photos from the Read Centre of Australia – Uluru, Ayers Rock, Alice Springs (Australia). When I use Webservice to retrieve time zone and write to the file I get GST+11 written to the file while it should be GST+7.30 Unless I do something strange this is bug in database. GPS coordinates are wrong too. Have never seen similar problem in other locations. | ||||
| Tags | No tags attached. | ||||
| related to | 0000128 | resolved | Friedemann | darstellung bei unterbruch des trackings |
|
|
I think I don't understand: You say that GPS coordinates are wrong... If they're wrong, then the result may be an incorrect time zone. Where did you get the coordinate from? By using the embedded map? |
|
|
Thanks for your response. Sorry for not being clear. GPS track is fine, but problem is that pictures got inadequate GPS coordinates (not corresponding to the place where they were taken) because time zone of clock is out of synch. When I choose to request timezone from WEBservice time zone written to the file was GMT+11 which is wrong (Darwin is GMT+ 9.30). This is reason why GPS coordinates for each photo are not the ones where picture was taken and wrong time zone get written to the JPG file too. After long trying I think I know how to get it work. I have to unselect checkbox “request Time Zone by using WEbservice…” select Time zone manually to GMT+9.30 Darwin and then it works correctly. However this solution does not write time zone to file at all. Most importantly it does indicate that program does not select correct Time Zone from Webservice – otherwise there would be no difference whether I set time zone manually or automatically. So there is bug! Well I did some experiments. First of all my GPS track started with data from Sydney GMT+11 time zone, so probably program read first coordinates in the GPS track an selected time zone from there. So I deleted part of GPS track containing data from Sydney leaving exclusively data from Uluru. It did change the result. Now automatic Time Zone is +10.30 which is to be written to file data which is still wrong, but closer (you remember GMT+9.30 Darwin is the correct one). Checking unchecking daylight Saving time checkbox does not help and after all it should not change time zone itself – so time zone is wrong. By the way remeber - daylight saving goes in oposite direction in Southern hemisphare. Now another problem you might wish to think about – how to handle GPS tracks with several time zones? There is circular dilemma – if you don’t know time zone of photo, you don’t know the GPS coordinates, without knowing GPS coordinates you can not find time zone for particular photo. Solution: if program finds coordinates corresponding to several time zones – why not ask user which one to use? This is major problem indeed and I am not sure what Geosetter is doing when synchronising time. Before I have used locr GPS Photo 1.2.2 which I think solves all those complicated time adjustment problems elegantly. It is very easy – there is Time Adjust functions where you adjust camera time to system time (system – is meant computer system time on which one is currently working). The rest happens by itself: I suppose program knows time zone of computer and thus now knows GMT time at which each photo was taken and thus synchronize easily and correctly with GPS coordinates and GMT timestamp. Neither user nor program needs to set or know anything else or try to extract TimeZone from GPS coordinates. Your function – Adjust by image content is great too except that again it requires time zone of image where that particular image was taken and it is not known before you can assign GPS coordinates to it, which again you can’t do before you know the Time Zone! See again the same circular argument? Your system might work fine if you work within the same time zone (system=computer, camera, Photo taken), but it gets unsolvable if you do real travelling. Your function Adjust Image Data and Time for Synch …for correcting difference between camera and GPS time. Well GPS time originally is in GMT as far I know while camera time might be the local time at particular Time Zone. So it is reasonable to do as follows: Adjust Image date to current computer system time (computer time where Time Zone is known and users might easily estimate themselves what the time difference at particular location was compare to the computer time). Sorry - I might have made wrong assumptions and be mistaken how your program works in above description of problem, but one is clear – there are errors in handling data. At the end I want tell how much I like Geosetter! I think Geaosetter is the very best software at the moment. Fabulous, I am very pleased. Many thanks for excellent program. Ingvar |
|
|
Hi Ingvar, you didn't mention which kind of track file you're using. Is it GPX? You're right, GeoSetter only requests the time zone for the first coordinate in the track. Then it assumes that the time zone wouldn't change. BUT: In the current official version, GeoSetter handles a GPX file as one track, but a GPX file can contain several tracks. So this may be your problem. Are you sure that your track is really one track which spans over several time zones? In my opinion, it wouldn't be a problem if a track is located in more than one time zones if the camera clock hasn't been adjusted each time the time zone has changed. If you want to, you can send me you track file to support@geosetter.de, then I can tell you if this is the problem. But I'll release a new version of GeoSetter hopefully soon, then we will see if it will handle your track file in a better way. |
|
|
Hi! Sorry for all trouble. I use QSTARZ BT-Q1000 GPS data logger. The track is supposed to be NMEA and GeoSetter displays track(s) on a map correctly, so I did not suspect any problems. It does consist of several tracks (locr GPS Photo 1.2.2 does recognize several tracks in this particular file). “Several tracks” means that GPS device has been switched off between places. The attached file is the modified one where I manually deleted part corresponding to Sydney, so this track must be containing data only from Northern Territory, Australia GMT+9.30 Darwin Time zone. As I said GeoSetter thinks that time zone is GMT+10.30. Please consider another possibility of time synchronization the same as locr GPS Photo 1.2.2 is using - to tell what was the time difference between current computer system time and camera time when photo was taken – it may also solve problem of daylight saving time which might go in two opposite directions in Northern and Southern hemisphere and some countries and states do have daylight saving while others don’t and it may change from year to year. As I explained previously, it may not be too difficult to remember what time difference between computer system time (home country) was with camera clock during travel (country where pictures where taken). Paradoxically if camera clock was not changed in country of travel to local time (which happens to many people) then synchronization with GPS track does not need any adjustments at all – it works straight away. The system GeoSetter is using is much more intelligent - getting time zone accordingly to track location and giving option to compensate for daylight saving time and then for differences between camera time and local time. It is very smart and potentially functional, while fool-proof straight forward system might do the same job with no adjustments at all. Sorry for bombarding with so much information. Another minor issue. Setting time zone manually is fine too, however, Geosetter does not allow to write this info to file – only automatically acquired time zone will be written. Why not have option to write to file manually selected time zone too? There is potentially another problem lurking from around the corner. When this happens and time zone is written to file Geosetter still does not know what time zone camera clock was using at the moment when picture was taken. For example camera clock was GMT+10 (Sydney) but picture was taken in Uluru GMT+9.30 then time gets written to file and interpreted as GMT+9.30 while in fact camera was still at GMT+10 thus time and time zone on image when picture was taken gets totally confusing and wrong data are written to the file. Suggested solution: for writing Time Zone info to image introduce option – time zone of camera is the same where picture was taken, or select time zone used by camera clock manually. Then correct time and local time zone could be written to file. The cameras I have been using Canon G7 and Nikon D80 are aware of time zones, but whether this info is passed on with picture file data, I suspect not, or Geosetter can not read it. If it could do it, then mismatch between camera time zone and time zone where this camera took picture could be corrected automatically. Wow this so complicated! As I said locr GPS Photo has avoided all that in one easy step. Thank you very very much! Ingvar PS I uploaded GPS data file |
|
|
Hi Ingvar, > It does consist of several tracks (locr GPS Photo 1.2.2 > does recognize several tracks in this particular file). > "Several tracks" means that GPS device has been switched > off between places. unfortunately in NMEA files there's no indicator for a new track begin. I don't know how Locr recognizes a new track begin. Either I could use a time offset or a distance offset. If a time offset will be exceeded without a new recorded coordinate, I could interpret a new track begin. The same could be done if a specified distance has been exceeded. Perhaps a combination of both would make sense. In my opinion this would solve potential problems regarding the recognized time zone. > Wow this so complicated! As I said locr GPS Photo has > avoided all that in one easy step. yes, I know it is complicated, but I think it depends on the situation. Perhaps a similar additional option as in Locr would make sense. But the the dialog would get more and more options. The Locr mechanism assumes that the images had been taken in the same time zone as the software is installed in, doesn't it? If you have recorded a track in San Francisco with the camera's clock adjusted to San Francisco local time and then you would return home, perhaps to Berlin in Germany, and adjust your camera clock now to your local home time in Berlin before synchronizing, Locr wouldn't find the correct positions, but GeoSetter would - or should ;-) Right now you can disable the automatic recognition of time zone in GeoSetter, set the time zone manually to 0 and then you can adjust the needed value on bottom of the dialog. It's neraly the same as in Locr, isn't it? |
|
|
Thank you for your response, I really appreciate it. I love your software, it is brilliant, therefore I spend time writing about those issues. I was able to manage data manually. Still I think you did not answer the question why automatically acquired time zone is wrong? My track had only one single time zone which is GMT+9.30, but it writes +10.30 in the file. For Sydney which is GMT+10 GeoSetter at some stage wrote GMT+11 if I am not mistaken. So there is shift by 1 hour and this problem is in database and it is not related to my particular data, I suppose. Can you explain why my track generated wrong time zone? I have never been in time zone +10.30. And would you consider option writing time zone to the file data even if it is manually selected? Sorry about too much comparison to locr. Notice - in locr dialog Camera time when picture was taken is considered, fact that you change camera time back to your home country after travel is irrelevant, but I see what you mean. I don't know whether locr develops really thought about it this way when they made this function, but it deffinitely works elegantly in most cases. Assumption that camera and computer are in the same zone is very useful. Have a look at several scenarios: 1. Many photos are taken in the same country where you live or same time zone. 2. On a travel, for example me, – I always take my laptop with me for storage of photos, so I do set time in computer and camera to local time, so again it works perfectly. 3. Thirdly there are lazy people who never change clock on a camera even if travelling, they wouldn’t need any adjustments to get correct GPS coordinates either. There are some other categories which might need very simple adjustments: 4. Camera time was local, but then you come home and geotag photos. Easy – just find out how different local time was from your current time. Is it true that Geaosetter, in contrast to Locr, is more intelligent and is supposed do this job for you automatically (am I right?), but at the moment something is wrong how time zone is found? As I said my whole GPS file contains only one time zone, but it does not work either. Please check the database! Remember another thing – sometimes GPS device does not find satellites at some locations and then logged data refer to the GPS default coordinates – all zeros, this probably may fool your automatic Time zone detection as well. This is also minor problem how GeoSetter displays tracks – it does not always remove those zero coordinates referring to the point in ocean west from Africa (0;0) if I understand right. Just for future consideration: have option to change time when photo was taken to local and corrected time – because if you synchronize photos with GPS you have to correct for time zone, daylight savings and small clock imperfections – so at the end you must have exact local time when picture was taken – why loose it and not have option to overwrite original data with this corrected time when picture was taken and add time zone info as well? But then backup copy of original data is absolute MUST. Thanks Ingvar |
|
|
> Still I think you did not answer the question why automatically > acquired time zone is wrong? My track had only one single time > zone which is GMT+9.30, but it writes +10.30 in the file. Yes, I didn't answer because I didn't have the time by now to find it out ;-) But now: GeoSetter gets the time zone by using this http://ws.geonames.org/timezone?lat=-25.24655400&lng=130.98789400 It returns 2 values, +9:30 for Daylight Saving Time and +10:30 for Greenwich Mean Time. Because in my eyes I cant't consider Daylight Saving Time (I don't know when it starts and when it ends), I take the value for GMT. If you know, that local time was Daylight Saving Time, you have to check the corresponding option in the dialog. Or do you think that the values returned by geonames are wrong? For Sydney, by using this call http://ws.geonames.org/timezone?lat=-33.867139&lng=151.207114 I get +11. But it seems that you're right, I just found this one http://www.weltzeit.de/zeitzonenkarte.php where I can see that Sydney is +10 instead of +11. So I'm confused now and don't know what to do. Is it a bug on geonames, or is it a bug in my brain??? Perhaps you or somebody else who's reading this may help me out... > Just for future consideration: have option to change time when > photo was taken to local and corrected time - because if you > synchronize photos with GPS you have to correct for time zone, > daylight savings and small clock imperfections - so at the end > you must have exact local time when picture was taken - why > loose it and not have option to overwrite original data with > this corrected time when picture was taken and add time zone > info as well? But then backup copy of original data is absolute > MUST. Excuse me, I think I don't understand... Could you please try again to describe what you mean? Perhaps with an example? Why or when is backup copy a MUST? |
|
|
One more remark: I have no problem to add functionalety to get synchronization easier, I only have to understand what to do :-) |
|
|
I just found this one: http://twiki.org/cgi-bin/xtra/tzdate?tz=Australia/Sydney It uses http://en.wikipedia.org/wiki/Zoneinfo whi So it seems, +11 is ok for Sydney, like GeoSetter reports ist... |
|
|
Good morning! I appreciate your concern so much! It just proves again that your program is best available at the moment, and I hope it will keep it’s position. Well now I got a bit confused too. I understood that time zone is something that does not change and is something inherent. So whatever daylight saving is at the moment, I thought time zone does not change. However on top of it there is daylight saving time. The trick in my case is that Sydney is +10 time zone, however daylight savings time (now it is summer in Sydney) offsets time to +11, however, I would still say that time zone is the same +10. Another strange thing is, that during European summer Sydney is in winter time which would be at +10, however, Europe changes to summer time and time difference relative to European cities changes by 2 hours. But that’s not important as we are interested only in GMT. I think there is problem in terminology. I am not sure, but I think TimeZone is something that does not change in regard to summer time. However term GMT offset shows real time difference with GMT. The GMT offset value should be used in GPS coordinate synchronization, but it is not the value which should be written to the file and referred to as TIME ZONE, because Sydney’s time zone is always +10. It confuses even more because your program has time zone and in addition daylight savings time correction, thus I did assume it uses standard TIMEZONE plus daylight savings time, however, what it does is it gets GMT offset which is already corrected for daylight savings time and asks whether user wants to correct for daylight savings once more... Anyway, now I understand why program works this way - it does make more sense to add to file GMT offset rather than Time zone. So I suggest you to call it GMT offset rather than TimeZone. The rest is fine. Just for fun you might have additional keyword added to file telling in what the time zone pictures was taken which may not be the same as GMT time offset. The funny thing about Darwin is that the state of Northern Territory does not change to summer daylight saving time while Sydney (state New South Wales) does. So GMT offset for Darwin should be +9.30 which is the same as it’s time zone +9.30. Any values reported for Darwin +10.30 are WRONG!!! Under no circumstances GMT for Darwin this year could be GMT+10.30 because these is no daylight saving this year: http://www.timeanddate.com/worldclock/city.html?n=72 In Conclusion I think this is what confuses you too that instead of time zone, databases you use, are returning GMT offset. So you have to know whether database reports current GMT time offset or just plane TimeZone which needs to be further corrected for Daylight savings time. In regard to Darwin, there is simply error in the database because it wrongly assumes that there is summer time there. >Excuse me, I think I don't understand... Could you please try again to describe what >you mean? Perhaps with an example? Why or when is backup copy a MUST? This is minor and another topic regarding correction of wrong camera clock. I just thought that if program starts changing original time data from camera, then if one does a mistake, at some stage he/she are never able to recover what the original values where. If it overwrites those data, then there are two options to avoid loss of data – one is to create backup copy of file (this is appreciated by many users of locr, not me though :-), or probably just have that original camera time info be written somewhere in keywords to be able to restore it. Thank you so much for your response. You are greatest! I am leaving now for conference, but I will be back in a week to continue discussion, if necessary. I think we are clearing it up. |
|
|
Hi! Citation from Wikipedia http://en.wikipedia.org/wiki/Coordinated_Universal_Time Time zones around the world are expressed as positive or negative offsets from UTC. Local time is UTC plus the time zone offset for that location, plus an offset (typically +1) for daylight saving time, if in effect. UTC replaced Greenwich Mean Time on 1 January, 1972 as the basis for the main reference time scale or civil time in various regions. UTC is also referred to by the military and civil aviation as Zulu time (Z). |
|
|
Hi Ingvar, I don't think that there is a problem in terminology. I absolutely agree with you, that a location can have only one time zone which doesn't depend on DST. In my opinion the problem is geonames, because it mixes up GMT (UTC) and DST in your case. That's all. Which value would you choose here (http://ws.geonames.org/timezone?lat=-25.24655400&lng=130.98789400 ), DST or GMT? I take the GMT value, which is wrong... > Time zones around the world are expressed as positive > or negative offsets from UTC. Local time is UTC plus > the time zone offset for that location, plus an offset > (typically +1) for daylight saving time, if in effect. > UTC replaced Greenwich Mean Time on 1 January, 1972 > as the basis for the main reference time scale or civil > time in various regions. I know, I know, I know ;-) But please tell me what am I doing wrong? |
|
|
The documentation of the time zone request (http://www.geonames.org/export ) says the following: Webservice Type : REST Url : ws.geonames.org/timezone? Parameters : lat,lng; Result : the timezone at the lat/lng with gmt offset (1. January) and dst offset (1. July) Example http://ws.geonames.org/timezone?lat=47.01&lng=10.2 I don't understand the additional information regarding "1. January" and "1, July"... :-/ |
|
|
I found out what to do. I have to implement the time zone functionalety for myself by using the TZ Data Base (http://www.twinsun.com/tz/tz-link.htm ). I only can use the time zone id from geonames webservice. See this discussion: http://forum.geonames.org/gforum/posts/list/758.page |
|
|
Hi Friedemann, Thank you very much. I really appreciate that! Can't wait to see how it works. Ingvar |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-01-21 08:48 | ingvar | New Issue | |
| 2008-01-21 19:37 | Friedemann | Status | new => assigned |
| 2008-01-21 19:37 | Friedemann | Assigned To | => Friedemann |
| 2008-01-21 20:00 | Friedemann | Note Added: 0000302 | |
| 2008-01-21 20:00 | Friedemann | Status | assigned => feedback |
| 2008-01-22 10:24 | ingvar | Note Added: 0000306 | |
| 2008-01-22 21:15 | Friedemann | Note Added: 0000308 | |
| 2008-01-23 01:53 | ingvar | File Added: ULURU.nma | |
| 2008-01-23 01:55 | ingvar | Note Added: 0000309 | |
| 2008-01-23 22:12 | Friedemann | Note Added: 0000311 | |
| 2008-01-23 23:26 | Friedemann | Relationship added | related to 0000128 |
| 2008-01-24 04:42 | ingvar | Note Added: 0000312 | |
| 2008-01-24 21:25 | Friedemann | Note Added: 0000316 | |
| 2008-01-24 21:27 | Friedemann | Note Added: 0000317 | |
| 2008-01-24 23:37 | Friedemann | Note Added: 0000318 | |
| 2008-01-25 02:29 | ingvar | Note Added: 0000319 | |
| 2008-01-26 01:49 | ingvar | Note Added: 0000326 | |
| 2008-01-26 03:14 | Friedemann | Note Added: 0000328 | |
| 2008-01-26 03:15 | Friedemann | Note Edited: 0000328 | |
| 2008-01-26 03:21 | Friedemann | Note Added: 0000330 | |
| 2008-01-26 03:22 | Friedemann | Note Edited: 0000330 | |
| 2008-01-26 03:22 | Friedemann | Note Edited: 0000330 | |
| 2008-01-27 00:59 | Friedemann | Note Added: 0000336 | |
| 2008-01-27 00:59 | Friedemann | Status | feedback => acknowledged |
| 2008-02-01 06:14 | ingvar | Note Added: 0000368 | |
| 2008-02-21 22:21 | Friedemann | Status | acknowledged => resolved |
| 2008-02-21 22:21 | Friedemann | Fixed in Version | => 2.3.2 beta |
| 2008-02-21 22:21 | Friedemann | Resolution | open => fixed |
