Geolocation - where is the exact data gone

Helllo there

I started adding geolocation tot my files. I uses exact locations I can find using google. When I enter them in the geolocation flied I can se that they are translated tot readle text which is not exact. But no harm done I thought, the original data is there. What I put in stays. Yes? Well NO to my dismay as it seems. I just copied the contents of the geo location field to another file and found to my horror (2 days of work so far) that the geolocation is off. Way off, its is a center of a town and not the place a few miles down the road. It seems as if it takes the text and then reverses that to a geolocation. Where is my data? I presume that data I put in manually isn’t altered or deleted by the software. Expanded upon is ok. But I cannot find a way to get back to my original, exact, input. So I hope I’m wrong and the data is still there, but unreachable. How to proceed?
Thanks in advance.

The internal data isn’t altered at all, the user interface just displays a readable version of it.

Which is incorrect. I want access to the original data. When I copy the contents of the geolocation field the original content is not copied. Because as I stated I I get a different location somewhere in the vicinity. And as a rule. Software should NOT shield information from me I put in myself. Really? So how do I access my input?
The map is no help either. Right clicking does not reveal any info. So I’m clueless.

A toggle would do nicely. Toggle between actual input and supposed “user friendly” display. Configurable. So I can choose to always have the exact input. The map shows me were it is. So I don’t need a readable text.

Greetings Frans

Hard to tell what you’ve exactly entered (coordinates?) but the altitude, longitude and latitude are accessible via AppleScript and could be e.g. copied that way to the clipboard.

My input is:

50.20764369611933, 4.5917474517534265

Which is the location of an object I photographed in 2004. Now when I enter it it translates to: Philippeville, Namen, België which is an IDENTICATION of the location.

If I copy this back to google maps I end up somewhere else.The DT3 map does not zoom to the file which is in focus. It just shows all of the pins. And when I get it to show a pin I cannot access the figures I put in. So?

Needing AppleScript to get my input back?

Maybe I should resort to another custom meta data field. I repeat my statement. Data which is put in by the user should not be shielded from that user. So why should I use AppleScript?

The right pin on the picture is my original input. The left pin is what you get if you copy the contents of the geolocation field to another file inside DT3.

The issue is repeatable. Add a geolocation to a file. Press enter.
Create new file. Use copy paste inside Devonthink to copy contents of geolocation entered previously.
Result is the same as in previous picture. (With the same data you get the same results. At least that is consequent.) See picture in previous message.

Greetings Frans

That’s probably the best workaround currently, especially if you prefer a text field which just stores the entered text. Or use this script to copy it to the clipboard:

tell application id "DNtp"
	if (count of selected records) is 1 then
		set theRecord to selected record 1
		set theCoordinates to (longitude of theRecord as string) & " - " & (latitude of theRecord as string)
		set the clipboard to theCoordinates as string
	end if
end
1 Like

Thnx. I just started learning AppleScript. Just put the library of DT on my screen. Not exactly Perl :upside_down_face::upside_down_face:

But anyway if I can read the properties in AppleScript I should be able to copy them to another file. Which is what I want to do. Geolocation is readonly (figures, is derived). But longitude and attitude not? So I have to figure out how to set from the clipboard.

geolocation is the automatically resolved, readable version (the one shown in the Info inspector for example), only longitude, latitude and altitude can be changed via AppleScript.

Thnx again.

And a tip for people with the same problem. Don’t use - (minus) as in the code example provided between latitude and longitude but a , (comma). I just found out that a minus is legit in coordinates, but you do find yourself in another place if pasted into google maps (in my testcase in the ocean south of the west of England, which is not near Belgium).

I’m sorry, this was just a quickly entered script without any real testing.

Is appreciated.

Still have a minor problem. When my manual input was:

52.11100769043, 5.294924259186

The script returns

52,11100769043, 5,294924259186

The dots have become comma’s and the output useless. Google maps or any other map application does not understand that (on my machine). It has nothing to do with system settings. No settings to be found in DT3 to correct this. So WHY is my input altered??? Don’t touch user input aargh. If you feel a need to change it, store both.(check Lightroom).
Not every number is a number. There are semantics involved. And not everyone uses American notation. And yes I do prefer my software to be English speaking and not translated because a) translation are very poor to my language as a rule. So poor as sometimes to be not understandable. , b) you need the correct English term to search on the internet. And translating back does not always give you the right term.
But I do like local time and notation settings for data (well for date I use iso yyyy-mm-dd). So english speaking does not mean English formatted.

(I found an 850- page book on AppleScript so I will figure it out. )

For reference: script now is (latitude comes before longitude seems to be the convention):
tell application id “DNtp”

if (count of selected records) is 1 then

set theRecord to selected record 1

set theCoordinates to (latitude of theRecord as string) & ", " & (longitude of theRecord as string)

set the clipboard to theCoordinates as string

end if

end tell

As I see it, we’re talking about the numbers’s representation here. This is probably determined by your systems preferences (“language & region”). Check what is set there under “more options” and then “Number separators”.
If you could pass your information “as is”, i.e. its internal representation, it would work flawlessly, I’m sure. That would mean foregoing the use of set the clipboard to theCoordinates as string and using some kind of direct AppleScript call into Google Maps (or Apple Maps). This is apparently not possible because not even Apple support AppleScripting Maps, far less Google.
Also, if Google et al were aware of the fact that other regions have different number formats then the US, that would definitely help. But little hope there.
There’s a discussion of this topic here: internationalization - Applescript: decimal sign issues with different Locales - Stack Overflow
What you could try to do is to replace the commas in the string representation to a dot before concatenating. Unfortunately, this is quite contrived in AppleScript (Does AppleScript have a replace function? - Stack Overflow).
I’d rewrite the whole thing in JavaScript like so

(() => {
const curApp = Application.currentApplication();
curApp.includeStandardAdditions = true;
const app = Application("DEVONthink 3");
const sel = app.selectedRecords();
if (sel.length !== 1) return;
const rec = sel[0];
const lat = rec.latitude().toString().replace(',','.');
const long = rec.longitude().toString().replace(',','.');
curApp.setTheClipboardTo(`${lat}, ${long}`);
})()

Note: I didn’t test that. A less error-prone way might be to use this approach: Number.prototype.toLocaleString() - JavaScript | MDN. And I don’t mean to say that it can’t be done in AppleScript.

Was the first thing I checked. Systemwide language is local and settings for metrics and notation also. But then again. My systemwide setting for eml files is outlook. My setting in mail from apple is outlook default but DT stubbornly keeps using apple mail for opening an eml-file inside DT3. So I wonder where DT reads it’s information from.

But systemwide local settings would mean that clipboard should use local settings. But DT3 is English (no local language and unwanted as I pointed out.) Applescript seems ancient and is “English-like” so maybe I shouldn’t be surprised?

I will try to read and put it as a string in a meta-data field. See what happens if I skip the clipboard.

Unfortunately, this is quite contrived in AppleScript

Whereas in perl this is a oneliner. So shell call to perl from within AppleScript? Another question to figure out. (found that zsh does not work the same as bash :frowning: Even standard globbing doesn’t). (It does seem I have a scope creep. Don’t I? :slight_smile: )

Thanks for the links

Greetings Frans

If you could pass your information “as is”, i.e. its internal representation, it would work flawlessly,

Test without clipboard. Immediate copy to meta-data field within same script. Same result. Comma’s instead of points.

Script used:
tell application id “DNtp”

if (count of selected records) is 1 then

set theRecord to selected record 1

set theCoordinates to (latitude of theRecord as string) & ", " & (longitude of theRecord as string)

set the clipboard to theCoordinates as string

add custom meta data theCoordinates for “GPS” to theRecord

end if

end tell

I guess the “as string” is the culprit.

Outlook is your default email client but Apple Mail seems to be the default app for .eml files. This can be changed in the Finder’s info window.

The following line converts the numbers to a string and causes this, using the result in a different way doesn’t change this:

set theCoordinates to (latitude of theRecord as string) & ", " & (longitude of theRecord as string)

But this should work:

set theCoordinates to my numberToString(latitude of theRecord) & ", " & my numberToString(longitude of theRecord)

on numberToString(theNumber)
	set theStr to (theNumber as string)
	set theOffset to offset of "," in theStr
	set theStr to ((characters 1 thru (theOffset - 1) of theStr) as string) & "." & ((characters (theOffset + 1) thru -1 of theStr) as string)
	return theStr
end numberToString

This can be changed in the Finder’s info window.

Done that a zillion times. Is of no use.

Thnx for the appelscript code. I found another solution, (my first macscript - lol) but yours is better, shorter, a solution to the problem. So I will adopt the script.

My version was:

– llmv.scpt: change comma’s to dots in a string

– Created by Frans Johan on 2021-02-25, borrowed ideas from Christian Grunenberg and McUsril on macscripter.

(* Revision: 2021-02-25 FJR (YYYY-MM-DD)

Initial version.

*)

– Copyright ©: none, feel free to reuse an redistribute.

try

tell application “DEVONthink 3”

set thisSelection to the selection

if thisSelection is {} then error “Please select some contents.”

tell application “DEVONthink 3”

repeat with theRecord in thisSelection

set theCoordinates to my comma2dot(latitude of theRecord as string) & ¬

", " & my comma2dot(longitude of theRecord as string)

add custom meta data theCoordinates for “latlon” to theRecord

end repeat

end tell

end tell

on error error_message number error_number

if the error_number is not -128 then

try

display alert “DEVONthink” message error_message as warning

on error number error_number

if error_number is -1708 then display dialog error_message buttons {“OK”} default button 1

end try

end if

end try

on comma2dot(aText)

script c2d

property commaText : {}

end script

local dotText

set dotText to {}

set commaText to every character of aText

repeat with i from 1 to (length of commaText)

if item i of commaText is not “,” then set end of dotText to item i of commaText

if item i of commaText = “,” then set end of dotText to “.”

end repeat

return (dotText as text)

end comma2dot

Could you please post your script code included in three backticks like so:
```
script
```
Your way of simply pasting it as normal text renders it nearly illegible.

Not here: I have DT talking in German to me. Except the help, but that is expected. I just wanted to write that AppleScript is the good guy, because it respects the locale settings – apparently it’s behaving weirdly here, because other languages (I tried C and Perl) use the US convention for outputting floating point numbers. Unless one goes the extra mile and tells them to respect the locale:

perl -e 'use locale; POSIX::setlocale; my $x=3.7; printf "%f", $x;'
> 3,700000

Nope. You do an explicit conversion to string here: ... as string. I was talking about sending latitude/longitude to another program as is, i.e. as floating point numbers. But given the lack of support for scripting in Maps, this argument is mute anyway.
BTW: Did you even try the JavaScript I posted? It’s not Perl, of course, but a lot more to the point then AppleScript, in my opinion.