Additionally format SMS location as URI

[Former user]

Very cool app, thanks!

My suggestion is to add some existing location format that other apps recognize, for example as a URI. Adding such a representation to the SMS can make it easier to make sense of them, in particular for distress messages to someone who does not have compass installed.

Currently compass formats the locations in SMS using "HRT" format, for example "SOS 51.23456,12.34567". The SMS app of my Android phone at least (the AOSP SMS app, I presume) misunderstands this format, interpreting latitude and longitude as phone numbers.

My guess is that the compass app's import function does recognize the format, but that requires the receiver to have the compass app installed. That may be the case when going on a treasure hunt with friends, but for the distress call functionality this can not be expected.

This problem is not unique to compass. There are other apps that can share location info via SMS, and have had to choose some format to represent the location. The point is to use a format that the SMS app recognizes.

For example, when sharing a location via SMS, the OSMAnd app writes SMS like this: "Position: http://osm.org/go/0123ABC@R-?m http://download.osmand.net/go?lat=51.23456&lon=12.34567&z=15" (numbers made up, causing them to represent different locations).

The Android SMS app correctly recognizes the URIs as URIs. Clicking on the SMS brings up a chooser, offering both URIs. When I click on one of them, another chooser pops up, letting me choose an app to handle the URI.

For the second URL, interestingly, beside the installed browsers, the OSMAnd app is offered as well. It appears that OSMAnd has somehow registered for that particular type of URI. When I choose OSMAnd to handle the URI, it shows the location on the map, even without an internet connection.

Entering the URL http://download.osmand.net/go?lat=51.23456&lon=12.34567&z=15 in a browser results in a redirect to https://maps.google.com/maps?q=loc:51.23456,12.34567&z=15 so that the location can be shown even without any additional software installed.

For the first URL, only the installed browsers are offered to handle the URI. It appears that OSMAnd has not registered for that particular type of URI.

The first URI is apparently abbreviated, no idea how OSMAnd encoded it (it did that without using the internet, so it is apparently an algorithm). Abbreviating the URI makes it easier to keep the SMS within 140 characters, I suppose.

Entering the URI http://osm.org/go/0123ABC@R-?m in a browser results in a redirect to http://www.openstreetmap.org/?mlat=67.10526064038277&mlon=26.455399990081787#map=17/67.10526/26.45540 so that again the location can be shown even without any additional software installed.

Besides OSMAnd handling one but not the other, the two URIs give the receiver a choice of web services to show the location. Among other things, this should make it more likely that at least one of the services works.

[Aleksey Tulinov]

Please let me explain myself before i go to URI stuff.

First of all, interpreting 51.23456 as a phone number "5123456" is some weird Android doing, i can hardly imagine phone number with dot in it...

Regarding HRT, it is designed to be protocol for humans also understandable by machines. When human receive HRT-encoded message, he should be able to interpret this message with community compass installed or not. If you say that it's hard to do, then this is very disturbing.

Plan was approximately the following:

1. (obviously) If CC is installed, then it can be used to import bookark and then set location
2. If CC is not installed a) SMS might be forwarded to a person with CC installed b) Coordinates might be entered into any other location service (OSM, GMaps, etc, doesn't matter)

Main HRT objectives are:

• Primary: readable by human beings
• Secondary: readable by machines

Therefore keeping location in URI violate objectives priority, unfortunately.

BUT

Regarding alien URIs support, last time i considered this options was in context of automatic locations import as it is done for HRT SMS messages. Automatic import is impossible because of shortened URLs used in many apps and requirement to make implicit HTTP request to discover real URL - this would inevitably raise privacy concerns.

But the way you put it sounds very nice. Registering compass as a handler for alien location URLs is doable and imply explicit user intent. Giving an option to choose export URI format might not be that straightforward due to URLs shortening requirement, as you've mentioned, but might be also possible. Maybe not for all location services out there... No promises.

Note that 1.3.5 compass release is already booked - please don't expect this to be included into it, ETA for alien URIs import/export is basically "when it's done".

[Aleksey Tulinov]

Fixed in 679e88b, ETA is approximately Dec 25 (compass 1.4 release)

[Aleksey Tulinov]

You can find option in Settings->SMS->URL to map, supported backends are somewhat described on this Wiki page: https://bitbucket.org/alekseyt/compass/wiki/Message%20Exchange%20Protocol#markdown-header-extensions

No import of alien URLs in nearest release, might be added in future releases. No short URLs, on the second thought i'm still not convinced in short URLs and implicit HTTP requests.