Repository navigation
docs(maps): explain where the location data comes from - #575
Conversation
The folder view and the sidebar panel only show files that carry `oc:location`, which the search service writes when its Tika extractor reads the GPS data. With the default `basic` extractor no picture ever gets a location, and nothing in the README said so. Document the two settings that enable it, the forced rescan that existing files need, and the 20 MiB extraction limit.
| To enable it, point the search service to an [Apache Tika](https://tika.apache.org/) server: | ||
|
|
||
| ```yaml | ||
| SEARCH_EXTRACTOR_TYPE: tika | ||
| SEARCH_EXTRACTOR_TIKA_TIKA_URL: http://tika:9998 | ||
| ``` | ||
|
|
||
| In [opencloud-compose](https://github.com/opencloud-eu/opencloud-compose) this is what `search/tika.yml` adds. | ||
|
|
||
| Files uploaded after that get their location within seconds. Files that were indexed before keep none, because unchanged files are skipped when the index is rebuilt, so force a rescan: | ||
|
|
||
| ```bash | ||
| opencloud search index --all-spaces --force-rescan --insecure | ||
| ``` | ||
|
|
||
| `--insecure` is needed when the internal gRPC services run without TLS, which is the default. The search service only extracts metadata from files up to 20 MiB by default (`SEARCH_CONTENT_EXTRACTION_SIZE_LIMIT`, in bytes), so larger pictures get no location. |
There was a problem hiding this comment.
I feel like we should just link to the docs here, no need to duplicate content we already have: https://docs.opencloud.eu/docs/dev/server/services/search/information#tika
There was a problem hiding this comment.
Fair point, the Tika setup and the forced rescan are already covered there, so I've cut the section down to what that page doesn't say: that the maps app depends on it. The page never mentions location or GPS, which is what the user in opencloud-eu/opencloud#3587 was missing. The setup and the rescan are now links to it.
One thing the docs command doesn't have is --insecure: against the default setup, opencloud search index failed for me with tls: first record does not look like a TLS handshake without it. If that's worth fixing in services/search/README.md, I can open a PR there.
There was a problem hiding this comment.
That would be awesome, thanks!
The Tika setup and the forced rescan are already documented in the search service docs. Keep only what they don't say, that the maps app reads the location the Tika extractor writes, and link to the Tika and re-indexing sections for the rest.
Description
Adds a "Location data" section to the maps README. The folder view and the sidebar panel only show files that carry
oc:location, which OpenCloud's search service writes when its Tika extractor reads the GPS data. With the defaultbasicextractor no picture ever gets a location, so the folder view says "No files with location data" even for photos with EXIF GPS, and nothing in the README pointed to the search service.The section explains that the location comes from the search service's Tika extractor, and links to the search service docs for enabling Tika and for the forced rescan that already indexed files need.
Related Issue
No issue. This came up in opencloud-eu/opencloud#3587, where the user asked what kind of location data the maps app expects and suggested documenting the answer here.
How Has This Been Tested?
opencloudeu/opencloud-rolling:8.0.1,apache/tika:latest(4.0.0), and the maps app shipped by opencloud-compose withfolderViewEnabled: true, using a JPEG with EXIF GPS.oc:locationin PROPFIND.opencloud search index --all-spaces --insecureskips it as unchanged. With--force-rescanit gets its coordinates and the pin shows up in the folder view. Without--insecurethe command fails withtls: first record does not look like a TLS handshake.basicdefault was checked againstmainof opencloud-eu/opencloud, and the README passesprettier --checkwith@opencloud-eu/prettier-config.Types of changes