Metadata: Normalize GPS coordinates to be within a common range to avoid frontend errors

[refactoriel]

What does not work as described in the documentation?

There are a few thumbnail photos on the map at locations that I've never been to (see red labels in screenshot). If I click on one of the thumbnails I get the notification "no photos found", so I can't check if these photos really have erroneous coordinates.

How can we reproduce it?

Don't know yet, since I can't find the photos that cause it.

What behavior do you expect?

Thumbnails should only appear at locations that are present in photos' geo locations.

What could be the cause of your problem?

Maybe an extraction of the location data? However, it's odd that the link to the photo is broken.

Can you provide us with example files for testing, error logs, or screenshots?

Which software versions do you use?

• PhotoPrism Architecture & Build Number (ARM64, 220121-2b4c8e1f-Linux-aarch64)
• Database Type & Version (MariaDB)
• Operating System Types & Versions (Linux)
• Browser Types & Versions (Firefox, Chrome,...)

On what kind of device is PhotoPrism installed?

• Device / Processor Type (Rockpro64)
• Physical Memory & Swap Space (in 4 GB)
• Storage Type (SSD)
• anything else that might be helpful

[lastzero]

You can disable location estimates in Settings > Library

[refactoriel]

Disabling location estimation doesn't fix it.

I understand that location estimation is based on other photos with a similar time stamp. However, I've never been even close to the North Pole or the other marked locations. The estimations should be close to other photos' locations, right?
The other thing is that I can't navigate to those incorrectly placed photos by clicking them.

[lastzero]

Disabling it won't instantly remove already estimated locations. Without seeing the specific files and metadata, it's a lot of (ineffective) guesswork. The algorithm may for example not work well in certain edge cases. We can only test with what we have.

[refactoriel]

Alrighty, will wait for a bit for them to disappear.

Yeah sorry, it's also frustrating for me to not find the referenced photos. I had thought you might have some pointers of how to find them.

Will report back if anything changes or I have an idea.

[xarantolus]

Hi, I recently encountered this issue with a photo I took.
Photoprism and other exif viewers show a latitude of 213.64001 and longitude of 103.48, the photo appears at a random location next to Australia:

Clicking the image just shows a No pictures found message at the bottom, the request GET http://localhost:2342/api/v1/geo/view?near=prjzt7kebyeij1vc&count=1000 has status code 200 but returns an empty array [].

The photo was actually taken at approximately 48.26679, 11.67530, however it appears that my phone camera app didn't save the correct location.

Another interesting point is the following message in the browser console when opening the "Places" map:

Uncaught (in promise) Error: Invalid LngLat latitude value: must be between -90 and 90
    qc http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    convert http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    setSouthWest http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    Hc http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    convert http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    cameraForBounds http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    fitBounds http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    search http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    promise callback*search http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    onMapLoad http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    renderMap http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    fire http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    _render http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    _frame http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    frame http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    triggerRepaint http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2
    _render http://localhost:2342/static/build/app.8b96715ec332728e9a6e.js:2

My guess is that this problem is caused by cameras/phones setting wrong exif location data, but there might be some way to adjust/ignore invalid data that photoprism could do.

The image shown above is in this zip file buggy_panorama.zip (image sha256 is 1d06f0b3bf4fb614abfa5358ff4e5476587e34d41c06e4753f47bcb712660949), it triggers the described behavior on the latest photoprism Docker image. I have changed the actual image content, but the exif data is the same as the original photo and triggers the same behavior.

Disabling location estimates does not seem to change the behavior.

[graciousgrey]

Thanks for reporting @xarantolus .

@DanBenHa assumed this issue is caused by invalid lat/lng values you might be able to find the affected files in the database by sorting the photos table by lat or lng to see if there are invalid values.

Might be the same issue as #2728

[lastzero]

The problem with latitude and longitude is that the earth is round. So technically they are unlimited if you just keep going. Some device and software developers implicitly or explicitly fail if the values are not within a certain range, while others just keep working. Then there are all kinds of users with different expectations. Some don't want us to validate or change their original metadata, others expect us to handle and fix even the craziest edge cases. It COULD well be worth normalizing position metadata and ideally providing a complete developer guide just for geodata.

[lastzero]

Here's a check I once added after Google developers insisted on supporting higher longitudes and latitudes. This could eventually lead to a denial of service attack, as the calculations might lead to very high CPU usage (so I prevented this by adding this check - but not because it was mathematically impossible):

photoprism/pkg/pluscode/pluscode.go

Lines 43 to 54 in 015826d

	// EncodeLength returns the plus code for the given coordinates.
	func EncodeLength(lat, lng float64, length int) (plusCode string, err error) {
	if lat < -90 || lat > 90 {
	return "", fmt.Errorf("latitude out of range (%f)", lat)
	}
	if lng < -180 || lng > 180 {
	return "", fmt.Errorf("longitude out of range (%f)", lng)
	}
	return olc.Encode(lat, lng, length), nil
	}

It's beyond the scope of what we can do to educate the world and normalize/fix this in every single library out there and on every cheap China/Google device.

[cconcannon]

I'm experiencing a related issue to what has been mentioned here. After I uploaded my first batches of photos to a new PhotoPrism deployment, my thumbnails on the UI at /library/places are displayed in correct locations, but when I click a thumbnail, I get the "No Pictures Found" message that has been mentioned above. I am not, as far as I'm aware, seeing any thumbnails in "wrong" places. The "No Pictures Found" experience is happening with every thumbnail.

For what it's worth, all my photos that I've uploaded so far were taken with an iPhone 14 Pro and I'm using Photosync to convert .HEIC to .JPG when syncing via WebDAV to PhotoPrism.

As a specific example, in the screenshot below, the request sent when I click the rendered thumbnail is /api/v1/geo/view?near=prnl6533dr4i0cay&count=1000. The response status is 200, and response body is an empty array. For that particular photo, I extracted the exif data of the image file in my /originals/ folder with imagemagick. Here are all the GPS attributes in the result:

    exif:GPSAltitude: 690386/487
    exif:GPSAltitudeRef: 0
    exif:GPSDestBearing: 422819/1674
    exif:GPSDestBearingRef: T
    exif:GPSHPositioningError: 5191/1096
    exif:GPSImgDirection: 422819/1674
    exif:GPSImgDirectionRef: T
    exif:GPSInfo: 2300
    exif:GPSLatitude: 42/1, 56/1, 4436/100
    exif:GPSLatitudeRef: S
    exif:GPSLongitude: 171/1, 33/1, 243/100
    exif:GPSLongitudeRef: E
    exif:GPSSpeed: 0/1
    exif:GPSSpeedRef: K

[lastzero]

Latitude and longitude do not appear to be out of range at first sight. Since it could still be a problem with the specific files you have, it would be helpful to get samples for testing. See https://photoprism.app/contact for details.

[lastzero]

With these changes, the GPS latitude and longitude are forced to be within a valid range so that the map UI doesn't break. Of course, this is no guarantee that the coordinates will be correct in case your phone has a malfunction. An updated preview build will be available for testing soon.

[lastzero]

Note that the current GPS coordinate "normalization" is only a proof-of-concept. We leave it to contributors to improve this, e.g. by figuring out what best practices exist to correct out-of-range values.

[cconcannon]

Since it could still be a problem with the specific files you have, it would be helpful to get samples for testing

I just sent the file. Sorry for the delay! Hope it helps with testing.

[graciousgrey]

I just sent the file. Sorry for the delay! Hope it helps with testing.

Thank you for sending the file. Do you still see issues with this file when using the preview? For me it is displayed on the map in PhotoPrism at the same location that I get displayed when I enter the coordinates in Google Maps. If I click on the thumbnail on the map it opens without error.

[cconcannon]

Do you still see issues with this file when using the preview?

I'm not sure what you mean by the preview, but if you're talking about the view of the /places url endpoint, then I do see the thumbnail displayed in the correct location (as in the screenshot that I posted in a previous comment). The issue that I'm experiencing for this file and all my other files is that clicking the rendered thumbnail results in the "No Pictures Found" notification.

The API request that gets triggered when I click on the thumbnail is /api/v1/geo/view?near=prnl6533dr4i0cay&count=1000, and the response is status 200 with a body of [].

For me, the photo thumbnails have always been appearing in correct locations. The issue that I've observed is the inability to use the map to zoom in to a location, click a thumbnail photo, and view that photo. Clicking on any photo thumbnail tells me "No Pictures Found". I think the intended behavior would be for the full photo to be displayed in a full screen view, but I'm not sure since I get the same "No Pictures Found" behavior for all photos. This is true for dozens of photos that I've tested, with locations in the US and New Zealand.

I hope that helps clarify. Looking at the source code for a few minutes, I think there's a high likelihood that the source of the empty array is line 57 of photos_search_geo.go, where search.UserPhotosGeo() returns an empty slice.

[lastzero]

Preview 👉 https://docs.photoprism.app/release-notes/#development-preview

[graciousgrey]

The issue that I've observed is the inability to use the map to zoom in to a location, click a thumbnail photo, and view that photo. Clicking on any photo thumbnail tells me "No Pictures Found"

I tested exactly this on our development preview and it worked with your file. So I assume the issue is fixed :)

[lastzero]

Note that you can also use our public demo at demo.photoprism.app to test the preview as it is based on it.

[cconcannon]

I finally got around to testing the preview image and the issue that I reported is fixed! Thanks!!

I did need to re-index my photos, but after the re-indexing was complete, I was able to click photo thumbnails on the /places page and see the full-size images.