search

david-r-edgar / MapSwitcher

Chrome extension to switch between different mapping websites
MIT License
25 stars 7 forks source link

Open-ended inputs via a link element #28

Open joshuahhh opened 3 years ago

joshuahhh commented 3 years ago

Hello @david-r-edgar! I hope you're well.

tl;dr – I'd like to add an input handler (across all domains) which looks for an element like this in the page head:

<link rel="map-view" href="geo:37.78918,-122.40335?z=12">

If such a link is found, it will work as an input for MapSwitcher.

I'm happy to code this up, if it sounds good to you!

Longer story –

I've been making my own mapping tools lately (Strava Atlas and Elevator, if you want to take a look). I've been missing getting to use MapSwitcher with them. But I don't think it would make any sense to add my peculiar niche tools to the MapSwitcher codebase! Rather, I thought it would be good if a website could advertise itself as offering a map view. Then MapSwitcher could read that off of any site, without needing a special input handler.

As far as I know, there is no existing convention for this. I picked the <link> style above by:

  1. looking for a convention for map views (center + view), and finding the geo: uri scheme (or rather, Android's extension thereof),
  2. figuring, since it's a URI, we might as well use a link tag.

I'm happy to revise this, especially if you know a standard I'm missing.

If MapSwitcher had this, it would be easy for hobby projects like mine to add a (possibly dynamically updated) <link> element and immediately work as MapSwitcher inputs. (Also, people could write extensions or userscripts which would add this <link> element to existing pages.)

Please let me know what you think. Thanks!

(Open-ended outputs are another story... an interesting one!)

joshuahhh commented 3 years ago

An alternative to the <link> I proposed comes from this expired IETF draft from 2007. It proposes

<meta name="geo.position" content="37.78918;-122.40335">

(and some other less relevant keys).

Issues with this:

  1. There's no provision for specifying zoom. If we wanted to use this notation, I might suggest augmenting it with: 
    <meta name="geo.zoom" content="12">
  2. More generally, this is a bit of an abuse of the standard. The meta tag is supposed to say "this page is about a location", but we're just using it to refer to where a map view is centered. So it's no surprise there's no "geo.zoom" already. (I don't mind this too much, if useful things can come of it.)
  3. It doesn't seem like anyone actually uses this standard.

Maybe I'll ask around a bit.

david-r-edgar commented 3 years ago

This is a great idea.

Actually I had previously had the beginnings of thoughts along similar lines, but I didn't know of any existing standard or convention.

I'm not immediately sure which of your suggestions I'd prefer. As you mention, a zoom parameter is definitely desirable. (And if not that, then some other value that allows the scale to be determined.)

One thing to bear in mind is that I've done quite a lot of work on the tabs2 branch - I'm intending it to be the next major release; it just needs a bit more testing, hopefully over the coming days. It refactors lots of the code quite significantly. I imagine that it's best to set up a default extractor which will run against any non-recognised URL, and it can potentially search for whichever of these 'standard' formats matches. If you would like to create a PR, you might prefer to base it on that tabs2 branch.