Leaflet (using OSM data) would be a better solution.

In T154513, @JMinor wrote:

Apart from political issues, [...]

This isn't a "political" issue (actually more of a legal issue, but I digress), but an issue with our mission itself.

@Josve05a Where in the app are you finding these maps?

In T157763#3015695, @Deskana wrote:

@Josve05a Where in the app are you finding these maps?

It's a new feature (still beta/alpha), I believe, and is part of iOS-app-feature-Places. A whole "tab" (between Explore and Saved), which brings out a map with dots for articles on Wikipedia.

The rhetoric in the description of this task is not helpful. Statements like "/me grumbles about lack of mission awareness amongt people..." are unnecessarily abrasive. People wouldn't work for the Foundation if they didn't care about the mission. All that taking a hostile attitude with them will do is make them less likely to engage with you. That's not a good thing.

Moving on to the issue of substance, there are legitimate reasons to use the Wikimedia maps infrastructure, and also legitimate reasons to not use it. According to T154513#2920017, using the Wikimedia maps would more than double the size of the app. That actually causes a conflict; the Foundation's mission is "to collect and develop educational content under a free license or in the public domain", but it's also "to disseminate it effectively and globally", and doubling the download size of the app could be a major impediment to that. Consider especially people on low bandwidth or rated data connections, which are common in the developing world, and are a major area of growth for our dissemination of knowledge.

My point is, this isn't a black and white issue. Positive discussion and engagement is good. Starting out with abrasiveness and negativity is not.

In T157763#3015718, @Deskana wrote:

The rhetoric in the description of this task is not helpful. Statements like "/me grumbles about lack of mission awareness amongt people..." are unnecessarily abrasive. People wouldn't work for the Foundation if they didn't care about the mission. All that taking a hostile attitude with them will do is make them less likely to engage with you. That's not a good thing.

Sorry for sounding cold and abrasive. Writing this while agitated a bit caused me to slip in to a hostile writing style, and for that I apologize.

According to T154513#2920017, using the Wikimedia maps would more than double the size of the app.

From what I can tell, that was about using Mapbox. leaflet and other alternatives are however tiny-tiny.

Regarding the mission, if doing one thing violates one part of the mission, we shouldn't instead do another thing that violates another part. In that case, we shouldn't do it at all, or find a way to accomplish both parts of that same goal.

"to disseminate it effectively and globally"

I see this part of the goal as a sub-part of the "to collect and develop educational content under a free license or in the public domain", due to the word it in "disseminate it".

I do however see a problem in that we license the app as freely licensed, but incorportate non-free material inside it, without acknowledging it on the credits page. Also, if we started disseminate non-free material above what out fair use policies allow, wouldn't that require the board to take such a decision?

It's not clear what T154513: Investigate Apple Maps and WMF OSM implementations evaluated, but based on the size they were probably looking at Mapbox for client-side rendering. If so, the size is understandable, but we're looking at functionality we wouldn't use.

I'm also not certain if the Apple's MapKit is doing client-side or server-side rendering. Again, this is a big difference in features if comparing.

I'm not a mobile developer, but Leaflet is a web map JS library, not an iOS native SDK, so my understanding is that it would be used by embedding a WebView into the app.

The Kartotherian generated tiles are certainly usable on mobile and can be generated at 2x, but we've done no work at optimizing tile size for mobile.

Wow, Josve05a, just wow.

1. You are included in development builds because of all the help you've given us in support and bug reporting, and because I have appreciated your bringing to my attention issues with things like incomplete image licensing that predate my employment. No version of the app has been released with Apple Maps, even to beta testers.

2. Although we broke our credits file in one version, which you found immediately, I made a High priority fix, and we corrected in the next version, we would never *intentionally* release anything without proper crediting. We do not typically update the credits file on development builds, but rather prior to actual releases.

3. Statements about legality and licenses, even by informed partisans are perhaps better left to lawyers. No major feature we have released during my tenure was not reviewed by someone from Legal, and that won't change for maps. In this case, that hasn't happened yet, because, as I said, you are seeing a very early development build, not something pending release soon.

4. That said, our app is MIT licensed, because we use Apple provided libraries in many places (we have to in many cases to make a functional app). It allows all the code and content developed by WMF and our volunteers to be licensed in accordance with our values, but to also include platform libraries for which we have no control over the license.

5. "Apart from political issues, " is guidance to an engineer to consider only the technical feasibility of different map providers. This doesn't imply licensing, policy and advancing free sources of information do not matter, but merely that he was asked to focus on the technical aspects, since that also determines the shape of what is possible. That ticket can be re-opened if you feel the technical analysis was unclear or incomplete (for example you know a native iOS library that will allow us to serve the Kartotherian tiles without bloating the app significantly in size and speed).

I'm sorry that the working relationship we developed and the changes we made over the last year to the app, in response to your requests (with more admittedly needed) have not demonstrated that me and the app team are not mission destroying nincompoops who "just don't get" or "care" about the mission and values of the Wikimedia projects. I appreciate you editing out your grumble, but I couldn't let this pass without saying that I know my character and the character of my team, it is not what you implied here, and it makes me sad that you would still think that of us. We can turn this ticket back to discussing how we might go about fulfilling the substance of your request, if possible.

I do however see a problem in that we license the app as freely licensed, but incorportate non-free material inside it, without acknowledging it on the credits page. Also, if we started disseminate non-free material above what out fair use policies allow, wouldn't that require the board to take such a decision?

100% of the app's source code is open and freely licensed. I'd argue the OS provided native MKMapView component is a tool like all of the other native components baked into the platform.

Our app's code, unlike most apps, is open source (maybe the most successful open source iOS app?). Like most apps, our code composes and controls native OS components like the one in question, MKMapView, such as - off the top of my head - WKWebView, UILabel, UITextField, UIScrollView, UIView, UIToolbar, UITabBar, UIBarButtonItem, UIButton, UICollectionView, UICollectionViewCell, UITableView, UITableViewCell, UIImageView, UISwitch, UIActivityIndicator, UIProgressView, UIPageControl, UIStackView, and UISearchBar. These are the native bits which make apps "apps". That's what native apps development is - leveraging and composing wicked-fast native OS components and APIs.

This particular native component provides the same benefits as all the others:

• baked into OS so no binary size increase (users have the OS, so they already have it)
• performant via deep hardware level optimizations (think GPU acceleration - what makes native apps snappy)
• zero maintenance (every external library imposes maintenance overhead - especially one as complicated as this)
• day-one compatibility with new operating system releases
• stability
• zero integration overhead

The alternatives available at this time for this platform present challenges in all of these areas. And that would be on top of the challenges of just getting the functionality working in a way that we'd be really proud to deliver.

Anyway, as a native developer I'm so incredibly stoked to get to contribute to this open source project. I'm even more excited lately given that Swift itself (the iOS development language) is now open source and is evolving so quickly - Swift 3 is AMAZING!!!

@Josve05a and I had an IRC exchange, and he has since edited the description. For the record I will leave my previous comment, though it is no longer relevant to the current state of the ticket. I also want to acknowledge his willingness to remove the more character-focus and inflammatory phrasing of the original description. It is personally very appreciated.

As I said above, lets now turn back to the actual substance of if it is possible to replace AppleMaps in the planned Places feature. We did do research to find a way to use our maps, but each had serious useability or user cost concerns. There may be a solution or native library we missed or where we misjudged an alternative solution to MapKit or MapBox.

Anyway not saying we *have* to use it (MKMapView), just wanted to point out, as someone who struggles with technical overhead every day, there are very real technical overhead implications to incorporating complicated external libraries into a binary like the app. I'm always going on about our binary size and how we need to decrease it ;)

Also for the record, @Josve05a is awesome. I appreciate how much he cares about the project and all he has done to make it better!

There might actually be two issues crossing here. I see @Josve05a added the Software-Licensing tag, therefore I'm assuming that (at lease part of) the intended outcome is to replace the operating system's native, proprietary software map viewer with a third-party, free and open source software library. However it is not clear why the use of an operating system library should matter in regard to credits and/or the license of the app's source code (MIT); in fact, as @Mhurd mentioned, lots of native components are already in use. For that reason, this task seems to actually concern licensing of content (map tiles) the most and may fall outside of the Software-Licensing project's scope.

In T157763#3016258, @Ricordisamoa wrote:

There might actually be two issues crossing here. I see @Josve05a added the Software-Licensing tag, therefore I'm assuming that (at lease part of) the intended outcome is to replace the operating system's native, proprietary software map viewer with a third-party, free and open source software library. However it is not clear why the use of an operating system library should matter in regard to credits and/or the license of the app's source code (MIT); in fact, as @Mhurd mentioned, lots of native components are already in use. For that reason, this task seems to actually concern licensing of content (map tiles) the most and may fall outside of the Software-Licensing project's scope.

Yeah, you are all mostly right, and I wanted to focus on the content parts and not the source code with this ticket (but I went out on a bad tangent while doing so). Removing the tag.

In T157763#3016289, @Josve05a wrote:

I wanted to focus on the content parts and not the source code with this ticket

Thanks. It is now clear that the goal is using map tiles provided by Kartotherian.

After some additional research into feasibility of the alternatives, we have decided to push a beta with Apple Maps still in place. I've posted a page on the app team's Mediawiki space running down the issues and tradeoffs behind this decision, and will continue to seek ways to replace the apple service with the WMF's own, or other free (both gratis+libre) maps service.

The issue of the privacy policy aspect doesnt appear to be covered on https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service , and IMO it needs to be covered, and probably in quite a bit of detail about how the Apple Maps service works. The two extremes are:

1. the Apple Maps service already has the users current geo position on the Apple servers, then there would be no privacy breach. Or,
2. the Wikipedia App instigates the device sharing the users geo position to non-Wikimedia servers, then the app is likely violating the privacy policy, either explicitly or spirit of it.

The real situation probably lies somewhere between those two extremes, and the exact way it works is quite vital to understand this.

The relevant section of the Privacy Policy is summized as "If you consent, we can use commonly-used location technologies to show you more relevant content."

Does this beta feature have informed consent to send the users GPS information to Apple?

Does this beta feature have informed consent to send the users GPS information to Apple?

On iOS, as a user you need to consent to ever sensor you use per application using it, with a consent dialog as defined by the developers. Note that on wikivoyage, we added a explicit approval and information dialog if you switch away from the wm maps layer to a 3rd party layer. That too is something that could be considered: Try switching layers at https://en.wikivoyage.org/wiki/A_Coruña

Has it been considered to use MKMapView custom tiles ?
https://github.com/viggiosoft/MapTileOverlayTutorial/
It will definitely be a LOT slower, but I think it would be worth exploring.

Thanks @TheDJ. As you say informed consent of users to share location is a requirment of iOS apps. The current app also has a "Nearby" feature based on the user's location and this feature doesn't change that. It just adds requests for maps tiles which may or may not be near the user.

As for the custom overlays, yes we did attempt it. In addition to the slowness you note, it had the following down sides:

1. Doubles the user data usage, as both the Apple tile and the custom overlay are downloaded
2. Interferes with the VoiceOver and Dynamic type accessibility features making maps not-accessible by the visually impaired
3. Because of the tiles the WMF service serves, we believe we'd have to use either bitmap maps (which look quite pixelated in some of our use cases) or un-styled vector tiles, which would take a significant effort to style.

This 3rd one is somewhat in the organization (but not the iOS team) control, but for the first 2 this would just be a tradeoff we'd have to accept.

• the Wikipedia App instigates the device sharing the users geo position to non-Wikimedia servers, then the app is likely violating the privacy policy, either explicitly or spirit of it.

The real situation probably lies somewhere between those two extremes, and the exact way it works is quite vital to understand this.

The information sent to Apple's servers is what location a user is looking at, as well as the standard data like IP, etc. This is inherent in any map which isn't preloaded. The server has to know what you're looking at to send the right data.

From this information it should be possible to derive either the user's location, or the article with a map they are viewing.

@Pnorman

You are correct that the map areas you're viewing are sent to a server. That request is sent via a secure connection and Apple has significant public documentation about how they preseve user privacy for these requests:

• Marketing/end user version: http://www.apple.com/privacy/approach-to-privacy/
• More detailed version: https://support.apple.com/en-us/HT207056

From this information it should be possible to derive either the user's location, or the article with a map they are viewing.

I'm not sure why that would be the case? You can use maps without enabling geolocation. You can look at areas like the entire United States for which there are hundreds of thousands of potential Wikipedia geolocated articles. Even in cases where the map tile contains only one or a small number of articles, that doesn't mean you've read or accessed those articles.

Also worth noting:

the article with a map they are viewing.

This feature doesn't touch or include maps in articles. Only the map based search capabilities of the new Places tab.

For those following along, the iOS team is disabling the places feature for the upcoming version (with an updated beta coming to users shortly).

In addition to giving us time to respond to usability/design research results and polish the features, we hope to use this extra time to better articulate the path forward for this feature in the light of these concerns. I also hope by then we can better speak to how it relates (or doesn't) to the Foundations plans for maps support going forward (this is not in my control, but its important).

I will update this ticket if there are any plans or changes made, and we'll be updating the wiki as well.

@JMinor Maps on iOS seems to be limited to the Nearby feature so far. Given this I get how it can be much simpler to implement with Apple libraries.

However, Maps (Kartographer) has been deployed to several wikis already, and aims at more wikis (once all the considerations will be resolved). The extension allows editors to embed rich maps with complex GeoJSON overlays in wikipedia articles. The number of articles with maps is still relatively low but it's growing. As part of this decision to use Apple maps, have you considered any mid/long-term plan to support articles' interactive maps in the native app? Have you decided to reduce the feature to the static snapshot image in the iOS app?

@JGirault please subscribe/comment on this ticket which tracks in article Kartographer support. T143877

I tried to raise several incompatibility issue with apps and maps last year but was told it was not a priority for the maps team.

Linking to T153282 which is being worked on now. Styled vector tiles are one major blocker for replacing Apple Maps with the WMF served maps tiles.

For subscribers here, we are releasing another version into beta with Places with apple maps.

I've updated the wiki page to better illustrate this is not really a choice at this stage, as the infrastructure and styles are just not there for WMF maps. We've also added a build flag to the main branch of our github project which allows devs to switch between the two. We hope this will help illustrate the issues leading to this decision as well as provide a starting point for volunteers who may want to pitch in to help make this task a reality.

https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service

I've read https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service#The_Present and I don't understand what's wrong with the current vector maps. They look good to me. Being more specific about the problems you see would help. At any rate, no difference in quality however big can justify a loss of privacy.

I do not see how https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Maps_service#Privacy answers anything. It basically just says "Apples promises to be good" (which is sometimes true, sure), while their privacy policy is just the typical USA-style privacy policy which doesn't give users any power.

Other providers provide more guarantees: for instance Mapbox accepts complaints and requests by individuals as mandated by EU law (privacy policy, 38).

@Nemo_bis the screenshots in the wiki are unfortunately out of date. They were based on this fragile workaround, which copied Mapbox’s "light" style and attempted to apply it to the tiles from maps.wikimedia.org. This stopped working somewhere along the way (the water and pretty much all of the roads were missing). Long-term, we would need to define a style that works with the tiles from maps.wikimedia.org. This could be done from scratch or via a conversion from an existing style. The new style is currently defined using this JSON file. Only land and water are defined so far.

Here are the current screenshots:

I'm removing this as a sub-task of T153282: [epic] Migrate to a new vector tile structure. There might be a dependency the other way around, but none of the new schema work depends on what's happening on iOS.