Page MenuHomePhabricator

Offer a way to extend <maplink> with configurable links to other mapping services
Closed, ResolvedPublic

Description

User should be able to switch to the "detail" view to see the geohack-like template page with the links to other map services and other information.

This could be either a button at the top next to "close", or tabs.

Any full screen map should have this capability. At this point all details screens will be identical and automatic, but the list of the actual services will be configurable per-wiki.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
JGirault renamed this task from Allow <maplink> customization to match GeoHack to Offer a way to extend <maplink> with configurable links to other mapping services.Aug 31 2016, 11:03 AM
JGirault claimed this task.
JGirault updated the task description. (Show Details)
JGirault added a project: Maps-Sprint.
JGirault moved this task from Backlog to In progress on the Maps-Sprint board.

I made a presentation of a very first draft during today's CREDIT.

Here are some screenshots:

DesktopMobileTablet
desktop.png (1×2 px, 848 KB)
desktop-details.png (1×2 px, 778 KB)
iPhone5.png (1×640 px, 388 KB)
iPhone5-details.png (1×640 px, 99 KB)
iPad.png (1×768 px, 444 KB)
iPad-details.png (1×768 px, 437 KB)
iPad-details2.png (1×768 px, 446 KB)

Example of the current GeoHack: https://tools.wmflabs.org/geohack/geohack.php?pagename=San_Francisco&params=37_47_N_122_25_W_type:city(864816)_region:US-CA

This is great! It looks a lot cleaner and easier to use than GeoHack. What's the plan to validate this over GeoHack before it's released? Perhaps trialling it as a beta feature to gather user feedback?

@Deskana, I think this feature will become available on all maps, rather than specifically target the "geohack" link. So when the community is ready, they can simply replace the geohack links in the upper right corner with the simple <maplink> tag, but all other map links and full screen (maximized) map frames will also have this capability.

@Deskana, I think this feature will become available on all maps, rather than specifically target the "geohack" link. So when the community is ready, they can simply replace the geohack links in the upper right corner with the simple <maplink> tag, but all other map links and full screen (maximized) map frames will also have this capability.

Thanks for the explanation! That wasn't clear from the context in the task. That sounds good.

Doing some research or testing might help convince people to switch over, and also might give us pointers to improve this. Are there any plans for that?

well, we will keep implementing this feature for all maplinks/frames, and receive feedback on it. At some point once it is stable and available, we will engage the community on if it matches their expectations. Basically everyone using the new <maplink> feature will be testers of the new functionality :)

Are the Geohack parameters like region:GB and type:airport going to be retained?

@Jc86035, I don't know yet - how would that information be useful for a map? What would you like to see when user sets region:GB or type:airport ? Currently we had no plans to use it, but maybe I'm missing something.

@Yurik: globe:moon (use a different map?), in particular, would definitely be useful (since Geohack does show satellite images of the Moon, Mars and other celestial bodies). Also, dim:1000 and scale:1000 could probably be kept for non-OSM objects.
source:GNS is… does anyone actually use that? region:GB-WSM (region-specific alternate maps) and type:airport should probably be determined using OSM data instead, and GeoJSON's custom markers would supersede type in any case.

region:GB

(for example) causes a set of links to GB specific maps to be at the top of the GeoHack page.

type:airport

sets the default zoom level.

For type:airport, we could introduce per-wiki/language configurable "zoom constants". So an editor could write "zoom=airport", or "zoom=city". I am not exactly sure of the value though - there are two basic ways to create a map. One is data-driven, where the map is positioned and zoomed automatically based on some external data, like a Wikidata query. The other is "by hand" - where the user positions the map by panning and zooming in Visual Editor. Neither of these approaches would use "type".

For region:GB - we could introduce a concept of "link sets", where one will be "default", and others will be listed by the <maplink infolinks="GB" ..., but should we make it manual or automatic or both? We could make these sets of links automatically show up in the info screen if the map's center moves to GB (however we define that "GB")

For type:airport, we could introduce per-wiki/language configurable "zoom constants". So an editor could write "zoom=airport", or "zoom=city". I am not exactly sure of the value though - there are two basic ways to create a map. One is data-driven, where the map is positioned and zoomed automatically based on some external data, like a Wikidata query. The other is "by hand" - where the user positions the map by panning and zooming in Visual Editor. Neither of these approaches would use "type".

Cough cough GeoData has dimensions and a type => dimensions mapping cough.

For region:GB - we could introduce a concept of "link sets", where one will be "default", and others will be listed by the <maplink infolinks="GB" ..., but should we make it manual or automatic or both? We could make these sets of links automatically show up in the info screen if the map's center moves to GB (however we define that "GB")

We should do our best to dod this automatically. Machines are good at mapping coordinates to country, why not use this ability to our benefit? ;)

I like that feature, it is overdue.

When working with location based information, I use the geohack feature to select the proper maps from a really huge number of them. For some purpose I use OSM, but this does not offer satellite images, so there is not a good way on OSM to identify an object / check for the correct location. You do not see the details of a roof on OSM. If some services are temporarily broken, I switch to another. So being restricted to the OSM link is not a perfect solution for me.

I do use the visualization of all coordinates on a page (or linked from that page) offered by geohack to check whether there are some coordinates off the main area, off the line of a river, etc. Hope this will work with maplinks/mapframes in a similar way, by automated collection of all the coordinates in an article.

Change 311709 had a related patch set uploaded (by JGirault):
Introduce map sidebar, for displaying map details and external map services.

https://gerrit.wikimedia.org/r/311709

Change 311462 had a related patch set uploaded (by JGirault):
Introduce map sidebar, for displaying map details and external map services.

https://gerrit.wikimedia.org/r/311462

Change 311709 merged by jenkins-bot:
Introduce map sidebar, for displaying map details and external map services.

https://gerrit.wikimedia.org/r/311709

Patch is now merged, thanks to everybody involved in this ticket. Here are screenshots :

Screen Shot 2016-09-24 at 3.04.32 AM.png (1×1 px, 879 KB)
Screen Shot 2016-09-24 at 3.04.48 AM.png (1×1 px, 664 KB)

This is a first iteration. I hope we can get user feedback about this feature, and soon we will have analytics, to keep improving it!

example screenshots are a first step, my comments:

as with geohack we need a localized version (depending on the region) to add local GIS services (each state in the EC has its own, and administrational units below states too).

*Offered maps could be restricted on mobiles to those that work pretty good on mobiles. Mobiles are, I think, not used for extracting / checking coordinates. And on mobiles this could be restricted to a quite small number.
*We should think about a combination of global services (google maps), local services (depending on region of the coordinates, e.g. www.geoportail.gouv.fr, amap.at), a per-wiki (pre)selection, and services selected by user preferences. It is of no good to have a per-wiki selection depending on the language of the wiki, because wikis always tend to think, write and locate globally. But a selection based on the offered languages of the GIS service might make sense.

Maps can be rather small (<mapframe>) as they cannot blow the whole article. Restricting the menu to the map frame could be difficult. Maybe a popup/overlay should be preferred.

<mapframe> should offer a feature to switch to full-screen mode.

@Herzi.Pinki thanks, the code has already been merged, and will be available everywhere in two weeks. You can see it at https://en.wikipedia.beta.wmflabs.org/wiki/Maplink#/maplink/0

as with geohack we need a localized version (depending on the region) to add local GIS services (each state in the EC has its own, and administrational units below states too).

  • The service names are localizable with translatewiki
  • I plan to add location-based services as part of T146534

*Offered maps could be restricted on mobiles to those that work pretty good on mobiles. Mobiles are, I think, not used for extracting / checking coordinates. And on mobiles this could be restricted to a quite small number.

  • We could introduce support for the service type if its really needed.

*We should think about a combination of global services (google maps), local services (depending on region of the coordinates, e.g. www.geoportail.gouv.fr, amap.at), a per-wiki (pre)selection, and services selected by user preferences. It is of no good to have a per-wiki selection depending on the language of the wiki, because wikis always tend to think, write and locate globally. But a selection based on the offered languages of the GIS service might make sense.

Maps can be rather small (<mapframe>) as they cannot blow the whole article. Restricting the menu to the map frame could be difficult. Maybe a popup/overlay should be preferred.

Not sure what you mean. You already have a "maximize map" button in the upper right corner of <mapframe>

<mapframe> should offer a feature to switch to full-screen mode.

Not sure what you mean. You already have a "maximize map" button in the upper right corner of <mapframe>

Sorry, Yurik, did not see that. It's already ok.

*Offered maps could be restricted on mobiles to those that work pretty good on mobiles. Mobiles are, I think, not used for extracting / checking coordinates. And on mobiles this could be restricted to a quite small number.

We can totally restrict the list on mobile, or make the mobile-optimized links more prominent in the list. We need feedback on which services to highlight, which are the most useful. It's a good suggestion, but I think we should roll the feature out like this, and wait a little for more user feedback.

*We should think about a combination of global services (google maps), local services (depending on region of the coordinates, e.g. www.geoportail.gouv.fr, amap.at), a per-wiki (pre)selection, and services selected by user preferences. It is of no good to have a per-wiki selection depending on the language of the wiki, because wikis always tend to think, write and locate globally. But a selection based on the offered languages of the GIS service might make sense.

Should the local services be based on the region represented on the map in an artificial intelligence way, or should it be an additional parameter manually added to the <mapframe> tag, such as <mapframe region="ES"> ?
I'm in favor of the first option (the automatic one), but I would like to receive your input.

We can totally restrict the list on mobile, or make the mobile-optimized links more prominent in the list. We need feedback on which services to highlight, which are the most useful. It's a good suggestion, but I think we should roll the feature out like this, and wait a little for more user feedback.

agreed

Should the local services be based on the region represented on the map in an artificial intelligence way, or should it be an additional parameter manually added to the <mapframe> tag, such as <mapframe region="ES"> ?
I'm in favor of the first option (the automatic one), but I would like to receive your input.

Agree, but lets discuss this at T146534