Mapillary and EXIF:GPSAlitude don't mix

Imagery, data, and integrations
1

I feared this wouldn’t go very smooth, so uploaded a sequence in two parts, this is the “troublesome part”

http://www.geoarchief.nl/mapillary.html?key=M-aKMlUI2-odDkiwCw9Rkw&zoom=.1
or if you want on mapillary:

[update] new urls, no change (see lower for reason)

First of all I must say I had quite a bit of work restoring/building all the EXIF data correctly. This because the stitch software of the YI destroys all EXIF data… I restored/generated (via GPX and what I saw in the original unstitched image) this:

Filename - RFile_02072.jpg (this is the last frame of the sequence linked above)
ImageDescription - XIAOYI
Make - XIAOYI
Model - YI360
DateTimeOriginal - 2019:05:23 19:20:18
GPS information: -
GPSVersionID - 2.3.0.0
GPSLatitudeRef - N
GPSLatitude - 52 55 32.005924 (52.925557)
GPSLongitudeRef - E
GPSLongitude - 6 3 1.403281 (6.050390)
GPSAltitude - 8.29 m
GPSImgDirection - 62.59

When I red the EXIF instruction correctly I also should have set ‘GPSAltitudeRef’ (to zero). This is the only value it can contain, setting ‘GPSAltitude’ goes fine with my Perl program, but attempting to set GPSAltitudeRef gives an warning and does not set the value (also not automatically with the setting of GPSAltitude).

Now the “don’t mix part”:
The API doesn’t do anything with the altitude, now I see a heap of images running in circles (check the first link)

Clicking the arrows mingle trough the images as if I actually did run in circles

Pressing “play” goes awesome by the way :wink:

In other words, or Mapillary really needs the setting ‘GPSAltitudeRef’, but I think Mapillary doesn’t factor in Altitude into the programming… could you?
[update] GPSAltitudeRef correctly added now, no change

2

GPSAltitudeRef is “byte” whereas GPSAltitude is “rational”. (If significant)

3

I searched a bit further… and found the answer here.

I must not set 0 or 1, but the textual value:
0 = Above Sea Level
1 = Below Sea Level
(didn’t expect that)

I’ll upload that sequence once more, but I don’t expect it will make a difference, but one never knows…

[edit]
I wanted to place an image on FaceBook, and it didn’t see the 360 setting… after some searching I added this:
ProjectionType => ‘equirectangular’,
CroppedAreaLeftPixels => ‘0’,
CroppedAreaTopPixels => ‘0’,
UsePanoramaViewer => ‘true’,
CroppedAreaImageWidthPixels => 5760,
CroppedAreaImageHeightPixels => 2880,
FullPanoWidthPixels => 5760,
FullPanoHeightPixels => 2880,

(settings thanks to this piece of software )

[edit2]
Asuming human use, a minimum delta of 2 meters would be ideal to trigger “next layer”. The layer you’re on is zero and if the delta of several images is more (or less) then 2 meters accept that as the local new layer.

4

I am not sure if Mapillary takes into account elevation data at all, since imagery is recommended/presumed to be street level, and hence 2d-projected

5

With the experience above one qould indeed think so. But also with SfM and “street level imagery” Altitude can have quite an impact… thinking about bridges and tunnels… and “it gets exciting” when an other track can cross over or under it…

So I’dd tink it would be smart to factor elevation into the equation (on some level)?

6

I am definitely not arguing against it, but the platform might be a bit limited in that regard - as you mention, detections at junctions/bridges are in 2D.
maybe some day - shouldn’t be difficult if exif already has the data

7

Exactly why I put in the time to add that piece of information. But I fear a lot of GPX->imageEXIF applications are only fixating on latitude and longitude…

8

I’d suspect altitude from a GPS is not sufficiently accurate for bridges etc. It runs about 3x less accurate than the horizontal. ie +/- 10-20m

Also as it stands IME when using the tools, altitude is only written into the long mapillary specific EXIF tag. In fact when using video_process no other EXIF tags are written by default.