The photo exposure value will often overrun the focal length value in the info-panel when the number
of decimal digits is more than a few long. By convention, there shouldn't be any decimal digits in the
denominator so this fix rounds the denominator value before display. In addition, this fix increases
the number of decimal digits read from the photo exif metadata to improve the precision of the exposure value
to match what exiftool and other exif viewers display.
This enables to extract common string into a map and only reference their values.
This is expected to bring a further 43% savings on search results. Altogether leading to a 50% reduction.
#437
* Removing ids from DTO as it is not needed on the client side. ~4% saving
* Removing orientation information from DB and server response. ~3% saving
* removing altitude from GPS data and reducing GPS, exposure and fstop precision ~3%
Altogether 10% saving expected.
#437
Changed back `continue wpoints_loop` to `break wpoints_loop` because it causes an infinite loop once `wpt_i` reaches `wpoints.length` and `wpoints[wpt_i]` is undefined , yet it continues to loop for some reason. Break is not nice because there could be defined values for bigger wpt_i
Attempt to understand why with `console.log(wpoints.length)`.
Removed unnecessary comments; replaced `break wpoints_loop` with `continue wpoints_loop` which caused infinite loops, let's see if it still happens and if I can fix it...
Removed input parameter tagname, hardcoded instead the array tagnames=['trkpt,'wpt'] , and iterated through this array to get elements from the XML file at once and gather them in coordinates[ ] = [ track_path_points[ ], wpoints_points[ ] ].
In addition to path from getMapPath(), get wpoints from getMapPoints() and plot them on the marker layer.
Somehow the for loop `wpoints_loop` tends to continue infinitely, forcing stop with `break wpoints_loop` for now.
