Accept geo: URI in search and/or other parameter

[ghost]

It appears I cannot provide geo: URIs in the search field on the website, openstreetmap.org (try with something like "geo:13.4125,103.8667" as suggested in RFC5870 https://tools.ietf.org/html/rfc5870 ).

Such a feature would be very useful for automated linking from client software, websites etc. There is of course the possibility of directly linking to /#map=$z/$lat/$lon - but that's not standardized anywhere. Accepting a geo: URI would be great for wider compatibility.

For example, I could then setup a default handler in Mozilla Firefox for example so when clicking a geo: URI it could offer openstreetmap.org as a handler (like how the web-based IRC client Mibbit is offered for irc: links)

I wrote on the dev mailing list for OSM about this and hope that once geo: URIs can be linked, we can give a patch to Mozilla and hopefully see implementation pretty soon for clickable geo: links.

[tomhughes]

Why not make the handler strip the geo prefix before doing the search? That will already work fine.

Searching for a URI seems like a fairly weird thing to do...

[ghost]

On 2016-01-01 14:06, Tom Hughes wrote:

Why not make the handler strip the geo prefix before doing the search? That will already work fine.

Because it is a URI in its entirety and thus much more distinguishable from just a generic search term :)

Also for the reason specified further down in my original email as it can easily be used directly as a protocol handler in Mozilla Firefox. When sending the URI to a third party service (Mibbit, OSM.org...) the 'geo:' prefix is a good, easy and generic way to relay important information.

So as Mozilla Firefox would like to send the full geo: URI OSM.org should reasonably accept it, assuming this interoperability is desired.

Searching for a URI seems like a fairly weird thing to do...

It could just as well be its own parameter (parsed after URL decoded since it can contain '?', '&' etc.) or just used in place of the parameters after '#' or something else. My proposal is just to make it easy to provide a geo: URI to the web interface via a parameter so it can be explicitly linked from an external resource.

I don't know which solution would be the smoothest to implement as I don't know the openstreetmap.org codebase. I'd be willing to write a patch if I get nudged in the right direction though, so I don't have to start from scratch in understanding it :)

Mikael Nordfeldth https://blog.mmn-o.se/ XMPP/mail: mmn@hethane.se OpenPGP Fingerprint: AE68 9813 0B7C FCE3 B2FA 727B C7CE 635B B52E

[tomhughes]

I assumed a "protocol handler" was a piece of code, that would be able to process the URI as part of handling it.

It is just another URL that you can substitute into then?

[ghost]

On 2016-01-01 14:54, Tom Hughes wrote:

I assumed a "protocol handler" was a piece of code, that would be able to process the URI as part of handling it.

Ah, no I meant of course (as you now understand but for anyone else reading) the mechanism in a browser (or other) that registers when you're clicking a hyperlink which protocol this goes to (http, irc, gopher or - in this case - geo).

It is just another URL that you can substitute into then?

Yes, the way it is added for irc: and ircs: in Firefox can be seen in this commit: https://hg.mozilla.org/mozilla-central/rev/e144dd6cd801

The default set of protocol handlers for irc:

gecko.handlerService.schemes.irc.0.name=Mibbit gecko.handlerService.schemes.irc.0.uriTemplate=https://www.mibbit.com/?url=%s

So if we get them to add OSM.org it would be something like:

[...]uriTemplate=https://www.openstreetmap.org/search?query=%s

or something else (like '/#%s' or '/geouri?%s' or however it's desirable to accept the geo: URI).

Mikael Nordfeldth XMPP/mail: mmn@hethane.se OpenPGP fpr: AE68 9813 0B7C FCE3 B2FA 727B C7CE 635B B52E 9B31

[danstowell]

It seems to me that triggering a search is not really what you want to do, since a "geo:" query has one definite result that you want to go directly to. You don't really want to trigger a search for those co-ordinates. Even though OSM knows to offer the direct co-ordinates as the first result, you still get a results page rather than the map you wanted. Therefore I'd suggest it's a bit meaningless to try to overload this into the search feature.

BUT I agree that it would be nice if OSM could understand geo: URIs, especially given the example of firefox default handlers. One option might be to add a separate new parameter. An alternative might be to overload the #map= parameter so it understands geo: URIs as a special case, so the template would be:

     uriTemplate=https://www.openstreetmap.org/#map=%s

This overloading might not be favoured by the main OSM devs, especially as that parameter is core functionality. But one argument in its favour is that if a geo URI is specified then we don't really want a rival #map location to be specified - since then we'd have to decide which one wins.

(This is all assuming that the feature is desirable and that mozilla etc don't want to preprocess the query for us...)

[treestryder]

I stumbled onto this thread, while looking for a way to open "geo:" uri scheme links, much like they work on my phone. I agree with this request to add the ability to search for geo: uris, as that was one of the first things I tried.

It may be possible to do one better. In my search, I also found that using the Javascript function navigator.registerProtocolHandler Firefox will present to users the option to setup a protocol handler. This would make geo: links clickable and I believe Firefox also extends the registration to the operating system.

(edit: Just realized that @ghost had already mentioned setting up a protocol handler.)

[sfkeller]

@tomhughes AFAIK the (Web-based) protocol handler should work almost as a one-liner as explained in the website given from @treestryder (at least in FF). It's the OSM website which has to do the registering. I've provided a webpage here which shows some geo URIs to test: http://umap.osm.ch/en/map/open-tourism-hackdays-arosa_883 Don't know, what the user experience is, since it seems that he's prompted at least once when the website (OSM.org) is opened the first time.