I agree, that it can't be done correctly, but the same holds true for GPS-interpolation. Modern cameras are smart phones with better optics anyway. Or, do the right thing, and connect a GPS device to your camera or use a camera with a built-in GPS. You can always grab and shift a file marker on the map to 'correct' it. And how many points your track contains, the distance between the points, the absolute and relative distance between the clock in the camera and the clock in the tracker. Besides, the math is not that simple, depending on how precise you want to be and whether or not you consider the earth a sphere or an ellipsoid. But it could also be more like 1000 or 860m. I agree with the interpolation of point A and B (I think linear interpolation - easy math).īut I don't understand why you can't do the same for the altitude? Why do you have to use the median (which is for two data points the same as the arithmetic mean)?Ī time diff of six minutes between two points can mean six meter altitude change or 300 meters or none, with a 100m peak in-between - depending on whether you traveled by foot, bike, motor cycle, plane or UFO (shhhh).Ī is at 600m.
Only a few set of coordinates, easily managed by a few map panel locations Thank good I'm mostly shooting in the same buildings. For that I can only use the median value between B.alt and A.alt. ExifTool seems to do the same, although there is no info around.īut it makes sense to me. I think this is what GeoSetter means with interpolation.
The file should get the coordinate that matches a line between A and B, and then 20 seconds "in" that line. The file falls between point A (12:00:00) and B (12:00:50) which have a time difference of 50 seconds and 10 meters.Īssigning point A to the file would not be correct. I think I will also add (silent) interpolation (If I figure out the math, that is). I see a number of questions in the Lr forums, but most seem to be answered by "Did you set the time zone correctly to match your iPhone?". Still, millions of people seem to be able to work with Lr. The documentation of the Lr Map panel is not very informative at all. And there is no info about toerances they use, interpolation they perform etc. I wonder if I should make this an option.Īdobe Lr has no options at all. I have added a 5 minute before/after threshold and this works. Performance is awesome (5000 points processed in 2 seconds).
This is how an imported GPX track looks in the IMatch 2017 Map panel: It's the (apparently) easy parts who take most of the time.Īnyway, I now have routines who can convert and match a wide range of different timestamp formats, and this will be used to figure out which images in the scope fall on which track point. Iskren Ivov Chernev.Īll this took 5 times as long as writing a JavaScript class that can import a GPX file. So I had to sit back and learn about all this, and learn about the moment.js JavaScript library written by the cool Mr. While working with sample files I have collected over time I found many different date and time formats in the metadata. Again.īut EXIF/XMP metadata may use UTC or local time zones. One of the obstacles I had to overcome where the time formats. I know that this will be very welcome for many users. This will make it super easy to geo-code your files if you work with an external tracker.
#GPSBABEL TRACK POINTS BADLY ORDERED CODE#
Right now I'm writing code that can figure out (by the timestamp) which images in the current scope (file window contents) match the track log and then assigns the GPS coordinates from the track log to these files. I've also tested my import class with all track logs I have here, and some I've created on-line just for testing. Today I've implemented the routines which can render the imported GPX data on the map to show the track log.
#GPSBABEL TRACK POINTS BADLY ORDERED FREE#
If you have track logs in other formats, there are plenty of free on-line tools which can convert them for you. My class supports track logs, routes and waypoints!īoth standard GPX and modern GPX formats are supported. And it has some awesome new features that have been often requested and were now possible to do.Īs a final touch, I yesterday decided to look into how hard it could be to implement an import function for GPX track log files.Īfter studying the official documentation, I was able to create a small JavaScript class which can import data from GPX files! This was the easy part. The new Map Panel is built using the latest OpenLayers and Google Maps versions, uses IMWS to communicate with the IMatch database and is just great. One of the key features is the All New Map Panel (see related posts here: ). I'm working at all ends to get IMatch 2017 "round and ready" for shipping.
0 kommentar(er)
