I see now that the last bit of code was already included in the long line of code, so you can ignore that last command:

magick mogrify -sampling-factor 4:2:2 *

I should write a diary entry about it, but I never get around to it… 🙄

I use the Windows command-line, because it is quicker to just copy & paste code than clicking many buttons when there are many images to correct. (So I don’t know if there are any graphic programs that can do the same.)

There are two ways to go about this:

1. Insert parameters into the image (metadata) to indicate how much the camera was tilted. This is very fast, as it doesn’t modify the actual image, but in my last test Mapillary didn’t support this at all and Panoramax mis-interpreted some of the parameters.
2. Modify the actual image. This requires resampling the whole image and takes much more time, but it’s also much better supported as you basically create a new, corrected, image.

So I do the last, and I use the following apps: ffmpeg (https://www.ffmpeg.org), Exiftool (https://exiftool.org), and for Panoramax I also need ImageMagick (https://imagemagick.org). In addition I use RenderStuffs 360° Panorama Viewer (https://renderstuff.com/tools/360-panorama-web-viewer/) to view my images.

On the command-line, change into a folder that contains the photos (eg, cd 2025-01-01 if 2025-01-01 is the name of the folder). The converted images will be put in a subfolder convert, the original images won’t be modified, so that I can re-run the process if I discover I made a mistake. Here comes the magic:

md convert & cd convert & (for %a in (..\*.jpg) do ffmpeg -hide_banner -loglevel warning -i "%a" -vf v360=pitch=<pitch>:roll=<roll>:yaw=<yaw>:output=e -update 1 -qscale:v 2 -y "%~nxa") & magick mogrify -sampling-factor 4:2:2 * & exiftool -TagsFromFile ..\%f.jpg -overwrite_original .

Here you need to replace <pitch>, <roll> and <yaw> with the amount of tilt the images need to be corrected. You’re using the same amounts for the whole folder, so split up the folder if the tilt changed halfway. Pitch is the degrees the photo needs to be tilted up, from 90 to -90. If for example the camera was pointing straight up to the sky, you enter -90 for <pitch>, to correct the image downwards. Roll is tilt left/right, from 90 to -90, which corrects a slanted horizon (enter a positive roll to turn the horizon clockwise) and yaw is looking left/right, from 180 to -180, which corrects a straight road not going to the center of the image (enter a positive yaw to move the centre of the image to the right).

Now comes a final problem, Panoramax has trouble reading some of the rotated images. I need to run the following command in the folder of converted images:

magick mogrify -sampling-factor 4:2:2 *

It’s been a few months ago that I last did some adjusting, so I hope everything still works as it did back then.

Kudos to David G. of Trek View for his article that pointed me in the right direction: https://www.trekview.org/blog/calculating-heading-of-gopro-video-using-gpmf-part-2/

So cool, great to see some more track in the Netherlands on Panoramax. I’m making tracks around Eindhoven, whenever I’m in the country. (Only the last time on Panoramax.)

the metal on the holder hinge shrunk and the camera tilted back, so that footage was fairly useless.

Since it’s a 360 camera, any tilt (in any direction) can be corrected. I’m doing that before I upload my images, with a combination of ffmpeg, ImageMagik and ExifTool.

^^ Forgot to mention, both of those apps allow to turn off the screen during capture, which results in less battery use, less overheating, and more privacy for you.

@apm-wa, vacations are a great opportunity to take Mapillary photos! ;-)

I have also been struggling a lot with the Mapillary app before with my older phones. You might want to try alternative apps for collecting the photos, but then you must geotag and upload the photos yourself afterwards. I have had great success with DailyRoads Voyager (very stable, but limited to one photo every 5 seconds) and Hidden Camera Snapshot (now removed from the Play Store, don’t know why).

Congratulations! The world needs more photos, especially in those places where the commercial ones don’t come. 😁

Sadly, the images all link to the default Berlin view of BBBike.org. To get the proper URL to link to, you should click the “Share” link in the bottom right, and copy the URL from there.

@d1g mapping at night/holidays sounds like a great way to be confused for a potential burglar scouting a street for victims :-)

Thanks @GITNE and @taopeng! I’ve updated my description with links to Mapillary’s GitHub repository.

And the street names in Brussels are labeled as “<French name> - <Dutch name>”. (Where it just says “ - “ in my original comment.)

Looks like the comment system ate my “<lng>” codes. Everywhere you read “name:”, it should have been “name:<lng>”.

There is one big difference between “name” and “name:". The "name" field (if my interpretation is correct!) is supposed to contain the name as it is displayed at the location, while the "name:" fields are for the names as the are actually used in various languages.

For an extreme example, if I were so creative to advertise my fantasy bookshop everywhere with it’s name written in runes, then the “name” field should contain those runes. Of course, nobody knows how to pronounce these runes, so the shop will also have a local, pronounceable name, which would be recorded in the “name:" field.

For a more practical example, in some multiple-language countries, certain names are always recorded as a combination of multiple languages. A good example are the street names in Brussels (the capital of Belgium, a Dutch & French speaking country), which are labeled as “ - ". This is what goes into the "name" field, while the "name:fr" and "name:nl" fields contain the individual names for each language.

In reality, I don’t think there is any global algorithm that can determine what should go into the “name” field.

But I do think that any “name:" field that contains the exact same string as the "name" field (as in the example Athalis gave), should just be discarded.

I have to agree with _sev, the OpenMapSurfer style is not getting the recognition it deserves. In my opinion this style solves many of the problems listed in this discussion:

London: http://129.206.74.245/?zoom=17&lat=51.49149&lon=-0.27424&layers=B00000FFFF - At Z16 more information than GM, but more readable than OSM - At Z15 most one-way arrows are still visible, while they are gone in both OSM and GM. I’d say clearer road hierarchy even than GM, though the residential roads could have been more dimmed. - At Z13-10 more chaotic than GM, but mostly because of all the road number labels.

Rural: http://129.206.74.245/?zoom=13&lat=53.2118&lon=-1.7971&layers=B00000FFFF At Z13, OpenMapSurver is again a clear winner over both OSM and GM.

High density residential roads: http://129.206.74.245/?zoom=14&lat=4.62854&lon=-74.18337&layers=B00000FFFF Clearly better than OSM, and personally I think a bit better than GM.

Mountain map: http://129.206.74.245/?zoom=15&lat=48.77591&lon=-121.81464&layers=B00000FFFF Here, OSM is a clear winner, though OMS comes close.

High building density: http://129.206.74.245/?zoom=15&lat=-29.32611&lon=27.51527&layers=B00000FFFF Bit better than OSM, GM is much better.

Roads vs canals: http://129.206.74.245/?zoom=13&lat=51.29423&lon=3.14257&layers=B00000FFFF OMS is better than either OSM or GM.

Not purely road-related, but from Z9 and down, OSM is really terrible, both aesthetically and practically, and I think OpenMapSurfer is better than even GM: http://129.206.74.245/?zoom=7&lat=51.70458&lon=20.03954&layers=B00000FFFF (of course the capital city is clearly identifiable) http://129.206.74.245/?zoom=5&lat=53.67525&lon=17.18309&layers=B00000FFFF (a bit too busy in some countries, but still gives a clear overview)

In my opinion, just inheriting the OpenMapSurfer style fixes 90% of the problems the default OpenStreetMap style is struggling with…