Feed the map from metadata

[JBPressac]

Hello,
It seems that the plugin only allows to add locations on the maps by hand. Is there any project to connect the map to metedata like dc:coverage (which may contain geolocation data).
Thanks,

[andrisi]

@zerocrates we'd be very interested in using this feature. We have a database with hundreds of items which all have an address, so putting them on a map based on a field, and running it through OpenStreetMap's Nominatim or GMaps would be great. Do you plan to add this feature or geocoding will be limited to helping with manual marker positioning. Thanks a million.

[ousekjarr]

Looks like this was partially solved by #2 and yet nothing has been done to include this over the last 10 years. Similarly, I have a large collection of digital images from cell phones which have GPS co-ordinates in the image metadata - ideally I would like each image to be automatically interrogates for GPS metadata on save, and a location automatically added to the item.

Is this a dead plugin?

Omeka already displays the embedded metadata in the side panel for an item, and shows these details:
Embedded Metadata

mime_type: image/jpeg
video
dataformat: jpg
lossless: false
bits_per_sample: 24
pixel_aspect_ratio: 1
resolution_x: 4032
resolution_y: 3024
compression_ratio: 0.18915759462221
jpg
exif

FILE

FileName: 544143e42b57de426a656269ca33bb01.jpg
FileDateTime: 1672837085
FileSize: 6919064
FileType: 2
MimeType: image/jpeg
SectionsFound: ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS

COMPUTED

html: width="4032" height="3024"
Height: 3024
Width: 4032
IsColor: 1
ByteOrderMotorola: 1
ApertureFNumber: f/1.6
Thumbnail.FileType: 2
Thumbnail.MimeType: image/jpeg

IFD0

Make: Apple
Model: iPhone 12
Orientation: 6
XResolution: 72
YResolution: 72
ResolutionUnit: 2
Software: 15.4
DateTime: 2022:05:28 19:32:17
HostComputer: iPhone 12
YCbCrPositioning: 1
Exif_IFD_Pointer: 228
GPS_IFD_Pointer: 2234

THUMBNAIL

Compression: 6
XResolution: 72
YResolution: 72
ResolutionUnit: 2
JPEGInterchangeFormat: 2578
JPEGInterchangeFormatLength: 19784

EXIF

ExposureTime: 0.0019230769230769
FNumber: 1.6
ExposureProgram: 2
ISOSpeedRatings: 32
ExifVersion: 232
DateTimeOriginal: 2022:05:28 19:32:17
DateTimeDigitized: 2022:05:28 19:32:17
UndefinedTag:0x9010: +01:00
UndefinedTag:0x9011: +01:00
UndefinedTag:0x9012: +01:00
ComponentsConfiguration: ���
ShutterSpeedValue: 9.0231759484265
ApertureValue: 1.3561438092556
BrightnessValue: 7.2080968191068
ExposureBiasValue: 0
MeteringMode: 5
Flash: 16
FocalLength: 4.2
SubjectLocation
940
1650
697
697
MakerNote: Apple iOS
SubSecTimeOriginal: 432
SubSecTimeDigitized: 432
FlashPixVersion: 100
ColorSpace: 65535
ExifImageWidth: 4032
ExifImageLength: 3024
SensingMethod: 2
SceneType: �
ExposureMode: 0
WhiteBalance: 0
FocalLengthIn35mmFilm: 26
SceneCaptureType: 0
UndefinedTag:0xA432
1625285/1048571
21/5
8/5
12/5
UndefinedTag:0xA433: Apple
UndefinedTag:0xA434: iPhone 12 back dual wide camera 4.2mm f/1.6
UndefinedTag:0xA460: 2

GPS

GPSLatitudeRef: N
GPSLatitude
53/1
57/1
2046/100
GPSLongitudeRef: W
GPSLongitude
1/1
4/1
4554/100
GPSAltitudeRef: 0
GPSAltitude: 126303/9779
GPSSpeedRef: K
GPSSpeed: 0/1
GPSImgDirectionRef: T
GPSImgDirection: 712333/4096
GPSDestBearingRef: T
GPSDestBearing: 712333/4096
UndefinedTag:0x001F: 39091/8251

computed
latitude: 53.955683333333
longitude: -1.0793166666667
altitude: 12.915737805502

[zerocrates]

The specific pull request you're referring to applies to a quite old version of the plugin, and so can't really be used currently. It and some successors have the additional problem that they rely (as this plugin previously did) on Google's mapping and geolocation/geocoding APIs, which have in the meantime switched to a paid model, so the plugin no longer uses them. We should close the PR for clarity that we don't plan to include it.

In general I don't really see this coming in as a feature that includes geocoding, though I could see it happening for coordinates. The geocoding features that are currently in the plugin are set up just for use in Javascript, and the plugin doesn't do anything to try to account for, say, a bulk import or other process that could result in lots of requests to a geocoding API over a short period of time. The roughly equivalent feature that exists in Mapping, the Omeka S mapping/geolocation module, and allows for setting map marker coordinates from a bulk import, similarly only works with coordinate pairs.

Your specific request isn't quite the same thing. Dealing with files with embedded metadata for Geolocation is a little tricky, thanks to a couple separate things. Geolocation works on items and only allows one location per item, while you can have arbitrarily many files for an item, each potentially with a location. None of this is insurmountable, but it just calls for some decisions to be made about how it should work. Of course, since the embedded data is already coordinates, that sidesteps any issues related to geocoding.

[ousekjarr]

Understood, thanks - with the vast majority of photos these days having embedded GPS data, it seems a useful feature. My thought was that hooking into the item save process to identify if the metadata contains coordinates should be relatively simple. If an item has more than one file, maybe provide a config option to skip it, or use the location from the first file only, or the first file which has a location? What would also be useful is a way to retrospectively apply this location data to already created items, but that requires a batch processing system which can handle queueing, load management, etc in case there are thousands or millions of images to be checked.