Problem with the command line tools [Solved]

Contributing and equipment Command line tools
1

I have been using Commandlinetools (CLT) for many months. Since I have little experience with command line, Python, etc., I had to painstakingly find the command line to edit and upload the images. Many questions in the forum and some trial and error was necessary to get the Mapillary tools to work successfully.

Now the Mapillary tools seem to have received an update and nothing is as it once was.
I am now only getting error messages when trying to upload images.

So far I have used the following command and options for view direction correction and upload:

C:\Users\ … \Python\Python310\Scripts\mapillary_tools.exe process_and_upload --advanced --import_path d:/m --user_name yxz --overwrite_EXIF_direction_tag --keep_duplicates --interpolate_directions

But now the following error message appears:

mapillary_tool: error: unrecognized arguments: --advanced --import_path --keep_duplicates

Path and mapillary tools are ok. The command
C:\Users\ … \Python\Python310\scripts\mapillary_tools.exe process --advanced --help
shows me the help about command and command options.

My request is for someone to tell me a suitable syntax of the CLT.

Whereby the following processing steps should be done:

  1. View direction correction with view direction (compass) from image to image.
  2. Supposed duplicates should be kept. I take photos on foot, about every 5m. I guess every now and then photos are mistaken for duplicates because the distance is so small.
  3. I don’t want the sequence to be split into 2 or more sequences just because I have 7m or 8m spacing between images now and then.

I don’t want to use the desktop uploader because it hangs twice every time I try to upload. Once after reading in the photos and then again after correcting the viewing direction. I then always have to quit and restart the program.

It would be nice if someone could write me a suitable command line.

I can’t find any reasonable documentation with the help of which I could solve the problem. The examples on Github have become unhelpful as of late. The output of the --help call above is not very enlightening for laymen.

With kind regards

2

The --advanced argument was removed and therefore no longer needed. Remove this for the help comamnd and you will see the full help/syntax text. eg mapillary_tools process -help or mapillary_tools process_and_upload -help

The import path is the final command line argument. (no – required)

Viewing the interpolated direction can be done via the json file created in the root of the import directory.

Duplicate inclusion could be done by making --duplicate_distance very small. It is however defaulted to 0.1m

This makes your command line (best guess)
C:\Users\ … \Python\Python310\Scripts\mapillary_tools.exe process_and_upload --user_name yxz --overwrite_EXIF_direction_tag --duplicate_distance 0 --interpolate_directions d:/m

I suggest however that you run “process” only after an original image backup as a test (omitting the username)

2 Likes
3

Works again :slightly_smiling_face:… your guess was right.
I was able to process and upload the sequence.
What still irritates me is that 14 of the 148 photos have the viewing direction 0. Do you have an idea what could be the cause?

Example:

  "MAPSequenceUUID": "17b79849-77f1-4cef-b361-da60d3663073"
},
{
    "MAPLatitude": 49.369015170001624,
    "MAPLongitude": 9.104262499999999,
    "MAPCaptureTime": "2021_12_05_14_21_51_000",
    "filename": "1\\DSC06538.JPG",
    "MAPCompassHeading": {
        "TrueHeading": 197.58391611673574,
        "MagneticHeading": 197.58391611673574
    },
    "MAPOrientation": 1,
    "MAPDeviceMake": "SONY",
    "MAPDeviceModel": "E PZ 16-50mm F3.5-5.6 OSS",
    "MAPMetaTags": {
        "strings": [
            {
                "key": "mapillary_tools_version",
                "value": "0.8.0"
            }
        ]
    },
    "MAPSequenceUUID": "17b79849-77f1-4cef-b361-da60d3663073"
},
{
    "MAPLatitude": 49.36898367000375,
    "MAPLongitude": 9.104247170018683,
    "MAPCaptureTime": "2021_12_05_14_22_00_000",
    "filename": "1\\DSC06540.JPG",
    "MAPCompassHeading": {
        "TrueHeading": 0.0,
        "MagneticHeading": 0.0
    },
    "MAPOrientation": 1,
    "MAPDeviceMake": "SONY",
    "MAPDeviceModel": "E PZ 16-50mm F3.5-5.6 OSS",
    "MAPMetaTags": {
        "strings": [
            {
                "key": "mapillary_tools_version",
                "value": "0.8.0"
            }
        ]
1 Like
4

I would be guessing sorry!

There is also a duplicate angle argument (5deg default) that may be affecting your case. Did the upload summary show 14 duplicates?

5

I have counted again exactly. There are 16 pictures.
Would it be helpful if I email you the json file?

6

I have found an anomaly.
The viewing direction of the photo is always 0 degrees if the following image has the same coordinates.
This is quite understandable.
However, I have certainly changed my location between the two photos.
I guess I will have to check the way I assign GPS data to my photos.

7

I have now checked the log file of my GPS data logger.
The device has indeed logged the same position over and over again in a time frame of 23 seconds.
There are two photos in this time frame. In these seconds I have moved at least 10m.
Such sequences occur in the log file again and again and then cause the error in determining the viewing direction of those pictures.

8

Yeah it wasn’t clear to me how your photos got their position info. I assume (looking at the command line) that you write the position EXIF data before running the tools?

And how good is the GPS device? Any sky obstructions? The granularity of the date/time saved image can also affect things.

9

I use a GPS data logger Solmeta GMax which is plugged into the hot shoe of the camera. Data logger and camera have no connection. I write the position data from the log file of the Solmeta afterwards with the program Geosetter into the Exif file of the photos.
I use the data logger already for about 2 years. So far it has worked reliably and is also one of the most accurate GPS devices I know.
The area where I photographed is not critical in terms of GPS reception.
Writing an unchanged position in the log file over such a long period of time rather suggests a malfunction of the data logger?

1 Like
10

Perhaps… and only generalising

Does the logger/log have an NMEA output? If so the GPRMC sentence mode indicator will read “N” for invalid and “A” for valid. (last field before checksum) This may manifest as repeating the last valid position until it locks again.

As a backup and test facility it may be worth running a GPS logger additionally on a nearby mobile phone. If the track drops out on both it may be an interference source. If only the Solmetta then possibly review firmware, power and settings?

11

Strange … what does “flash” mean?

$GPRMC,125615.00,A,4922.32129,N,00906.63566,E,0.000,263.29,051221,D6F
$PTNTHPR,298.0,N,44.4,N,1.2,N00
$GPGGA,125614.00,4922.32129,N,00906.63566,E,1,11,0.95,257.34,M,47.98,M,59
$GPGSA,A,3,13,14,05,30,15,07,20,1.29,0.95,0.8804
$GPRMC,125616.00,A,4922.32129,N,00906.63566,E,0.000,263.29,051221,D6C
$PTNTHPR,298.0,N,44.5,N,1.2,N01
$GPGGA,125615.00,4922.32129,N,00906.63566,E,1,11,0.95,257.34,M,47.98,M,58
$GPGSA,A,3,13,14,05,30,15,07,20,1.29,0.95,0.8804
flash
$GPRMC,125617.00,A,4922.32129,N,00906.63566,E,0.000,263.29,051221,D6D
$PTNTHPR,298.1,N,44.6,N,1.7,N06
$GPGGA,125616.00,4922.32129,N,00906.63566,E,1,11,0.95,257.34,M,47.98,M,5B
$GPGSA,A,3,13,14,05,30,15,07,20,1.29,0.95,0.8804
$GPRMC,125618.00,A,4922.32129,N,00906.63566,E,0.000,263.29,051221,D62
$PTNTHPR,295.5,N,42.2,N,-1.5,N22
$GPGGA,125617.00,4922.32129,N,00906.63566,E,1,11,0.95,257.34,M,47.98,M,5A
$GPGSA,A,3,13,14,05,30,15,07,20,1.29,0.95,0.8804
$GPRMC,125619.00,A,4922.32129,N,00906.63566,E,2.070,269.23,051221,D66
$PTNTHPR,283.7,N,47.5,N,-14.9,N1D
$GPGGA,125618.00,4922.32129,N,00906.63566,E,1,11,0.95,257.34,M,47.98,M,55
$GPGSA,A,3,13,14,05,30,15,07,20,1.29,0.95,0.8804

12

flash memory full maybe? plugged into flashgun shoe? shutter release flashgun signal? Maybe a “flash” log event gets created for a shutter release? sorry I have no idea. “D” in the GPRMC line however may mean valid differential (DGPS) data. “A” means autonomous.

13

I checked older tracks for this error. The GPS data logger has been writing this error in log files again and again for months. I had never noticed it. Only now, by the problems with the CLT, I have checked the logfiles of the CLT more exactly and have noticed this error. Sequences in which no location changes are registered or recorded by the GPS data logger are not frequent, but are present again and again.
I followed your suggestion to carry a second GPS data logger for checking. With this device the recordings are correct. Unfortunately, the Qstarz data logger is not as accurate as the Solmeta data logger in determining the location.
I need to figure out a solution.
Regarding the original problem, everything is working again as usual. I can use the CLT again. I thank you very much for your help. I wish you a Merry Christmas.
Thank you.

1 Like