Mobile-l July 2015

mobile-l@lists.wikimedia.org

45 participants
60 discussions

Video for Safari, IE, and Edge: ogv.js 0.9 and TMH patches (please review)
by Brion Vibber 07 Jul '15

07 Jul '15

I've done some more cleanup and fixes on ogv.js JavaScript Ogg media player, with an 0.9 pre-release build and updated patches for TimedMediaHandler. Would love some code review and testing! *Upstream library release:* https://github.com/brion/ogv.js/releases/tag/0.9 *Live demo site:* https://ogvjs-testing.wmflabs.org/ *TMH patches:* Update to bundled ogv.js libs (went ahead and merged): https://gerrit.wikimedia.org/r/#/c/223261/1 Finish the desktop TMH integration of ogv.js player (need testing and review!): https://gerrit.wikimedia.org/r/#/c/165478/36 Work in progress mobile integration for TMH (needs more upstream updates for controls): https://gerrit.wikimedia.org/r/#/c/217485/ -- brion

1 0

Mobile-Apps' "Unbreak now" tasks in Phabricator
by Andre Klapper 07 Jul '15

07 Jul '15

Hi, could the Apps Team please update their open tasks with "Unbreak Now!" priority [1] in Phabricator's "Mobile-App-Sprint-58-iOS" project? https://phabricator.wikimedia.org/maniphest/query/40ps.K.br_Ri/#R That Sprint ended one month ago and all remaining tasks are in the "Done" column. Thanks in advance, andre [1] "Something is broken and needs to be fixed immediately" as per https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_… -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

3 3

ICDIM 2015
by conference＠icdim.org 07 Jul '15

07 Jul '15

Tenth International Conference on Digital Information Management Jeju Island, South Korea October 21-23, 2015 (www.icdim.org) Technically co-sponsored by IEEE Technology Engineering Management Society Proceedings will be indexed in IEEE Xplore Following the successful earlier conferences at Bangalore (2006), Lyon (2007), London (2008), Michigan (2009) , Thunder Bay (2010), Melbourne (2011), Macau (2012), Islamabad (2013) and Thailand (2014) the tenth event is being organized at Jeju Island the Republic of Korea (South Korea) in 2015. The International Conference on Digital Information Management is a multidisciplinary conference on digital information management, science and technology. The principal aim of this conference is to bring people in academia, research laboratories and industry together, and offer a collaborative platform to address the emerging issues and solutions in digital information science and technology. The ICDIM intends to bridge the gap between different areas of digital information management, science and technology. This forum will address a large number of themes and issues. The conference will feature original research and industrial papers on the theory, design and implementation of digital information systems, as well as demonstrations, tutorials, workshops and industrial presentations. The 10th International Conference on Digital Information Management will be held on October 21-23, 2015 at the Jeju Island, Republic of Korea (South Korea). The topics in ICDIM 2015 include but are not confined to the following areas. Information Retrieval Data Grids, Data and Information Quality Big Data Management Temporal and Spatial Databases Data Warehouses and Data Mining Web Mining including Web Intelligence and Web 3.0 E-Learning, eCommerce, e-Business and e-Government Natural Language Processing XML and other extensible languages Web Metrics and its applications Enterprise Computing Semantic Web, Ontologies and Rules Human-Computer Interaction Artificial Intelligence and Decision Support Systems Knowledge Management Ubiquitous Systems Peer to Peer Data Management Interoperability Mobile Data Management Data Models for Production Systems and Services Data Exchange issues and Supply Chain Data Life Cycle in Products and Processes Case Studies on Data Management, Monitoring and Analysis Security and Access Control Information Content Security Mobile, Ad Hoc and Sensor Network Security Distributed information systems Information visualization Web services Quality of Service Issues Multimedia and Interactive Multimedia Image Analysis and Image Processing Video Search and Video Mining Cloud Computing Workshops ICDIM 2015 has the following co-located workshops Fourth Workshop on Emerging Problem- specific Crowdsourcing Technologies Fourth Workshop on Advanced Techniques on Data Analytics and Data Visualization Third IEEE International Workshop on Data Management (IWDM 2015) First Workshop on Internet of Things First Workshop on Big Data Mining First Workshop on Cluster Computing First Workshop on Intelligent Information Systems Proceedings - All the accepted papers will appear in the proceedings published by IEEE. - All papers will be fully indexed by IEEE Xplore. - All the ICDIM papers are indexed by DBLP. Modified version of the selected papers will appear in the special issues of the following peer reviewed journals. 1. Journal of Digital Information Management (SCOPUs/EI) 2. Journal of Electrical Systems 3. Recent Advances in Electrical & Electronic Engineering 4. International Journal of Web Applications (IJWA) 5. International Journal of Information Technology and Web Engineering (IJITWE) 6. International Journal of Emerging Sciences (IJES) 7. International Journal of Grid and High Performance Computing (IJGHPC) (Scopus and EI Indexed) 8. International Journal of Computational Science and Engineering (Scopus and EI Indexed) 9. International Journal of Big Data Intelligence 10. International Journal of Applied Decision Sciences (Scopus/EI) 11. International Journal of Management and Decision Making (Scopus/EI) 12 International Journal of Strategic Decision Sciences 13. International Journal of Enterprise Information Systems (Scopus/EI Important Dates Full Paper Submission August 10, 2015 Notification of Acceptance/Rejection September 10, 2015 Registration Due October 10, 2015 Camera Ready Due October 10, 2015 Workshops/Tutorials/Demos October 22, 2015 Main conference October 21-23, 2015 2015 Main conference October 15-17, 2015 SUBMISSIONS AT http://www.icdim.org/submission.html Committee General Chair Hanmin Jung, Korea Institute of Science and Technology Information, Korea Ezendu Ariwa, University of Bedfordshire, UK Program Chairs Xu Shuo, ISTIC, China Thomas Mandl, Hildesheim University, Germany Satoshi Tojo, JAIST, Japan Program Co-Chairs Michaela Geierhos, Paderborn University, Germany Ing-Xiang Chen, Ericsson, Tiwan Imran Bajwa Sajwa The Islamia University of Bahawlpur, Pakistan Organizing committee Sa-kwang Song, KISTI, Korea Do-Heon Jeong, KISTI, Korea Seungwoo Lee, KISTI, Korea Young-Guk Ha, Konkuk University, Korea In-Su Kang, Kyungsung Univ. Korea Email: conference at icdim.org SUBMISSIONS AT http://www.icdim.org/submission.html ----------------------------------

1 0

Barry the browser bot
by Jon Robson 07 Jul '15

07 Jul '15

Some of you may have noticed a bot [1] providing reviews for the Mobilefrontend and Gather extensions. This is a grass routes experiment [2] to see if we can reduce regressions by running browser tests against every single commit. It's very crude, and we're going to have to maintain it but we see this as a crude stop gap solution until we get gerrit-bot taking care of this for us. Obviously we want to do this for all extensions but we wanted to get something good enough that is not scaleable to start exploring this. So far it has caught various bugs for us and our browser test builds are starting to finally becoming consistently green, a few beta labs flakes aside [3]. Running tests on beta labs is still useful but now we can use it to identify tests caused by other extensions. We were finding too often our tests were failing due to us neglecting them. In case others are interested in how this is working and want to set one up themselves I've documented this here: https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot Please let me now if you have any questions and feel free to edit and improve this page. If you want to jump into the code that's doing this and know Python check out: https://github.com/jdlrobson/Barry-the-Browser-Test-Bot (Patches welcomed and apologies in advance for the code) [1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c… [2] https://phabricator.wikimedia.org/T100293 [3] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…

2 1

[Web] Outstanding branches
by Sam Smith 06 Jul '15

06 Jul '15

Hey y'all, There are a bunch of (stale?) branches open against MobileFrontend. Do we need to keep any of the following around? - esisupport - photouploads3 - sandbox/jdlrobson/ds - sandbox/jgonera/backbone - sandbox/jgonera/backbone-watchlist - sandbox/jgonera/edit - sandbox/jgonera/framework Ta, –Sam

3 3

[video club] RailsConf 2015 - Implementing a Strong Code Review Culture
by Sam Smith 06 Jul '15

06 Jul '15

Hey y'all, I watch a lot of talks in my downtime. I even post the ones I like to a Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a Strong Code Review Culture" from RailsConf 2015 in particular because it's relevant to the conversations that the Reading Web team are having around process and quality. You can watch the talk on YouTube [1] and, if you're keen, you can read the paper that's referenced over at Microsoft Research [2]. I particularly like the challenge of providing two paragraphs of context in a commit message – to introduce the problem and your solution – and trying to overcome negativity bias in written communication* by offering compliments whenever possible and asking, not telling, while providing critical feedback. I hope you enjoy the talk as much as I did. –Sam [0] http://sometalks.tumblr.com/ [1] https://www.youtube.com/watch?v=PJjmw9TRB7s [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283 * The speaker said "research has shown" but I didn't see a citation *Notes (width added emphasis)* - Code review isn't for catching bugs - "Expectations, Outcomes, and Challenges of Modern Code Review" - Chief benefits of code review: - Knowledge transfer - Increased team awareness - Finding alternative solutions - Code review is "the discipline of explaining your code to your peers" - Process is more important than the result - Goes on to define code review as "the discipline of discussing your code with your peers" - If we get better at code review, then we'll get better at communicating technically as a team Rules of Engagement - As an author, provide context - "If content is king, then context is God" - *In a pull request (patch set) the code is the content and the commit message is the context* - Provide sufficient context - bring the reviewer up to speed with what you've been doing in the past X hours - *Challenge: provide at least two paragraphs of context in your commit message* - This additional context lives on in the commit history whereas links to issue trackers might not - As a reviewer, ask questions rather than making demands - Research has shown that there's a negativity bias in written communication. *Offer compliments whenever you can* - *When you need to provide critical feedback, ask, don't tell*, e.g. "extract a service to reduce some of this duplication" could be formulated as "what do you think about extracting a service to reduce some of this duplication?" - "Did you consider?", "can you clarify?" - "Why didn't you just..." is framed negatively and includes the word just - Use the Socratic method: asking and answering questions to stimulate critical thinking and to illuminate ideas Insist on high quality reviews, but agree to disagree - Conflict is good. *Conflict drives a higher standard of coding provided there's healthy debate* - Everyone has a minimum bar to entry for quality. Once that bar is met, then everything else is a trade-off - Reasonable people disagree all the time - Review what's important to you - SRP (Single Responsibility Principle) (the S from SOLID) - Naming - Complexity - Test Coverage - ... (whatever else you're comfortable in giving feedback on) - What about style? - Style is important - "People who received style comments on their code perceived that review negatively" - Adopt a styleguide Benefits of a Strong Code Review Culture - Better code - Better developers through constant knowledge transfer - Team ownership of code, which leads to fewer silos - Healthy debate

4 3

Performance audit example
by Joaquin Oltra Hernandez 06 Jul '15

06 Jul '15

Hey, I saw the other day a performance audit that Paul Irish did for the mobile site of reddit. It is a great audit and a great example of how to do a performance review of a site, I encourage all to carefully read it as we are going to have to do something similar in the following sprints in order to enable us to do more concrete performance work on the mobile website. https://github.com/reddit/reddit-mobile/issues/247 Awesome stuff.

2 3

Mobile MediaViewer and the Seattle Japanese Garden
by Pine W 06 Jul '15

06 Jul '15

English Wikipedia's "Seattle Japanese Garden" article looks good in the Android app, and the MediaViewer-like slideshow feature works well for the gallery. However, I'm unable to scroll through the photos in Mobile Web like I csn using the Android app. Are there any plans to add the slideshow functionality to mobile web? Thanks! Pine

2 1

[reading web] Phabricating in Q1
by Joaquin Oltra Hernandez 01 Jul '15

01 Jul '15

[Long email, sorry] Hi friends, There's been some talk about how we currently phabricate and there doesn't seem to be much satisfaction in our current workflows, and as part of the new team we are getting more software artifacts so we are going to have to adapt to this new situation. For that, I've mapped how we do things now, and proposed how we could move forward to effectively avoid more conphusion (sorry 'bout that). ## Current workflows Reading web currently uses 3 permanent boards + current sprint board. Reading-web: * Type: Team project. * Contains: Epics, bugs, features. * Board: Columns with should have, could have, etc. Mixed columns. Triaging column. MobileFrontend: * Type: Software project. * Contains: Bugs, tech tasks, features, discussions. * Board: Backlog. Gather: * Type: Team project + Software project (mix between the two above). * Contains: Epics, bugs, tech tasks, features. * Board: Columns with should have, could have, etc. Mixed columns. Triaging column. ### Bugs MobileFrontend bugs are added to MobileFrontend and Reading-web. They get categorized and triaged in Reading-web by team/standup and brought into the sprint if appropriate. Gather bugs are added to Gather & current sprint. Gather is triaged by JonR -- high priority are brought straight into the sprint. ### Features MobileFrontend/Gather features added to Reading-Web **Needs triage** column. Have MobileFrontend or Gather project added by TechPro as needed. Moved to **Must Have**, **Should Have**, or **Could Have** as necessary ### Problems * Workflow is different for MobileFrontend and Gather. * Boards have mixed responsibilities. * No one place to triage bugs and features. * Reading-Web is *noisey*. * Tasks with several tags -- leads to noise across all projects. * No clear high level overview of Reading-Web workload/workflow. On top of how we are currently working, we are getting a bunch of software artifacts that we are going to have to triage & maintain really soon. We need to adapt to deal with multiple projects/boards and maintain team vision of what we are doing. (Current process probably won't scale well with more than a few software projects). ## Proposal Taking into account that we want to: * Be able to work across multiple phabricator projects for different software artifacts. * Maintain a high level overview of team focus through time (so that we all know what we are focusing on mainly). * Have a clear place to triage for the projects we are responsible for. ### Solution #### phStructure Reading web will use N+2 boards. N+1 permanent boards + current sprint board. * *N being the number of software projects we maintain*. Reading-web: * Type: Team project. * Contains: Epics. * Board: Time based columns, left is closer, right is further on time. (Can be sprint based + Quarter based, or something else) (Ex: In progress | Next sprint | ...). MobileFrontend: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. Gather: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. PageImages: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. TextExtracts: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. ETC. (same for the rest of the software projects we're getting). Suggestion is that software projects get the same layout, but not necessary. #### Phrocess ##### Bugs and pheatures Such tasks will get submitted against the corresponding software project that involves them. If there is a bug on the mobile web, it'll get submitted to MobileFrontend, if there is a bug with collections, it'll get submitted against Gather. Same for feature requests. If there is a bug on MobileFrontend & PageImages it'll get submitted to both. Default priority *Needs triage* means task hasn't been triaged yet. Each project has tasks that involve that project. Reading-web stays a high level view of the team's focuses through time available for everybody. ##### Triaging We'll have a **saved query** available to everybody to triage (standups or else). Example: https://phabricator.wikimedia.org/maniphest/query/c_ZQlOwVk9I8/ (note this looks like shit because we don't use priorities at all right now). When triaging a bug, we'll set it's priority to something that makes sense regarding severity and add to current sprint project if priority is high. When triaging a feature, we'll set it's priority to something that makes sense regarding perceived importance and ping product owner. PO should add as subtask of epic if makes sense. ##### Sprint preparation. Task creation. >From the epics on Reading-web we'll spin off subtasks of specific work that'll get tagged with the concrete software project where they need to be acted upon with a priority. Sprint grooming and prioritisation will put subtasks of epics in *Next sprint* into the next sprint board. Also give a pass on work on software artifacts projects that needs to be added to sprint. Then we'll analyse and estimate. ------ I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png (I've tried with the current workflow but I don't even know how to accurately draw it. Sorry). --- What do you guys think? Beginning of next quarter is approaching so it would be great if we discussed this and arrived somewhere better than our current workflow. Thanks! Joaquin

4 8

Re: [WikimediaMobile] [reading-wmf] maps w/ nearby
by Adam Baso 01 Jul '15

01 Jul '15

Moving thread to mobile-l. On Fri, Jun 19, 2015 at 1:43 PM, Yuri Astrakhan <yastrakhan(a)wikimedia.org> wrote: > Hi everyone, sorry for not replying earlier. Ulf, thank you for your offer > to help, and everyone’s support of the map project! > > Here's our accomplishments so far and the approximate path forward: > > We now have built a vector-based Tile rendering service, called > Kartotherian <https://github.com/nyurik/kartotherian> (work in progress). > It is based on the components from Mapbox & Mapnik, and data from > OSM->osm2pgsql->Postgress w/Postgis. > > * Demo Server > <http://ns512621.ip-167-114-156.net:4000/static/#6/40.731/-73.989> > * Project page <https://www.mediawiki.org/wiki/OpenStreetMap> > * Implementation Info > <https://www.mediawiki.org/wiki/Maps/Tile_Server_Implementation> > > At this point, we are implementing a server-side Vector->PNG conversion, > similar to mod_tile approach. But, internally, all data is stored as vector > tiles, and converted to images on the fly. We are capable of also serving > those tiles raw, without rasterisation, but we will still need to do some > extra work to optimize their size at low zoom levels, wait for the complete > font implementation (e.g. Arabic is not showing correctly), and a number of > other minor issues. So client-side vector rendering is pushed for the > second stage. > > Feel free to use the Demo Server > <http://ns512621.ip-167-114-156.net:4000/static/#6/40.731/-73.989> for > any development and testing work. > > > On Fri, Jun 19, 2015 at 3:24 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote: > >> I've been waiting to follow up on this until I got official clarification >> on WMF's position for using the Apple's framework… >> >> Good news, WMF legal has no privacy/legal concerns with using the MapKit >> framework - so we will be able to proceed with implementing map features >> using the official iOS SDK! >> >> This should make it much easier to develop this feature. >> >> On Sat, Jun 13, 2015 at 7:12 PM, Ulf Buermeyer <ulf(a)ijure.org> wrote: >> >>> >>> Jon, >>> >>> thanks for following up! >>> >>> Just in order to share what we discussed yesterday let me briefly >>> summarize: >>> >>> Last year I submitted a pull request that introduces a simple map view >>> to display places referenced by coordinates mentioned in an article >>> (replacing the somewhat clumsy "look, there are 34 or so map providers >>> on the internet" page). The code was technically fine but not merged in >>> so far for policy reasons as MapViews on iOS display non-free content & >>> hit Apple's servers. >>> >>> So here are the options to move forward: >>> >>> * WMF may revisit the issue and approve use of Apple maps >>> + could be rolled out almost immediately >>> - non-free content >>> - privacy issue? >>> - community may be fond of that map selection page? >>> >>> * the MapView could be quickly tweaked to show nearby places >>> (accompanying the current nearby list) >>> + quick to implement >>> - non-free content >>> - privacy issue? >>> >>> >>> I have also coded an OpenStreetMap layer that can be displayed in an >>> ordinary iOS MapView but replacing Apple map content so it could be used >>> in both scenarios mentioned above to avoid hitting Apple servers. >>> + free content >>> - some time to implement (currently running in one of my apps but not >>> yet transformed into a separate component) >>> >>> >>> As for the OSM tiles to display in said layer, there are once again >>> three options: >>> >>> * set up WMF tile rendering infrastructure >>> + control over tile design >>> + download from WMF servers -> no privacy issue >>> - HUGE impact on engineering & operations resources >>> >>> * cache official OSM tiles >>> + download from WMF servers -> no privacy issue >>> + small impact on operations, little engineering >>> - some tile expiration logic / tweaking needed >>> - need to consult with admins: >>> http://wiki.openstreetmap.org/wiki/Tile_usage_policy >>> >>> * proxy official OSM tiles >>> + download from WMF servers -> no privacy issue >>> + small impact on operations, practically no engineering >>> - OSM guys from the UK may have concerns regarding load on their >>> infrastructure >>> - need to consult with admins: >>> http://wiki.openstreetmap.org/wiki/Tile_usage_policy >>> >>> Hope that helps, happy to help. >>> >>> Best, Ulf >>> >>> >>> >>> On 12/06/15 18:08, Jon Katz wrote: >>> > Hi All, >>> > Tilman brought Ulf (copied) to the office today and it was great and >>> > energizing to sit down with him and hear his thoughts on maps and >>> nearby >>> > options. As Tilman said earlier, Ulf has already done some work in >>> this >>> > area and is happy to help out. He also has some ideas about how we >>> > could make things scale. I think the only thing holding him back right >>> > now is not knowing where he can add the most value. >>> > >>> > I encourage Corey, Dmitry, Yuri and Max, in particular, to include Ulf >>> > in any conversations about this moving forward. >>> > >>> > -J >>> > >>> > On Fri, Jun 5, 2015 at 4:55 PM, Tilman Bayer <tbayer(a)wikimedia.org >>> > <mailto:tbayer@wikimedia.org>> wrote: >>> > >>> > Hi all, >>> > >>> > as it happens, Ulf (CCed, the author of last year's GitHub pull >>> > request >>> > <https://github.com/wikimedia/apps-ios-wikipedia/pull/3> that >>> Brian >>> > mentioned; he is the developer of a fairly popular geolocation iOS >>> > app <http://mapalarm.net/wp/> and runs his own OSM tileserver) is >>> in >>> > SF again currently; we'll have lunch early next week. He would be >>> > delighted to come by the office and chat with people working in >>> this >>> > area. (IIRC Max, Monte and Brion already met him last year, which >>> > led to that pull request.) Would some of the apps/maps people be >>> > interested in talking to him around 2pm on Monday, say? >>> > >>> > I showed Wikiminiatlas <https://wma.wmflabs.org/> to Ulf yesterday >>> > and he would be excited to use it to update his iOS app patch for a >>> > proof of concept that's in line with the privacy policy. I guess he >>> > could also use the new Karta server instead for something more >>> > production-like. >>> > >>> > >>> > On Wed, May 27, 2015 at 3:32 PM, Yuri Astrakhan >>> > <yastrakhan(a)wikimedia.org <mailto:yastrakhan@wikimedia.org>> >>> wrote: >>> > >>> > Disclaimer: I do not know much about the specifics of the iOS >>> > implementation, so can only speak about overall approach and >>> > possible concerns. >>> > >>> > * Per WMF privacy policy, we cannot use outside servers if that >>> > exposes our user's browsing behaviour. Thus any outside servers >>> > must be proxied to be consumable by our users. >>> > * OSM data is not the same as the tiles people see - there is >>> > data (clone of OSM db), there is data tiles (vector tiles) that >>> > only contain the features we try to show on a specific zoom >>> > level for that area, and there is rendering of that data as an >>> > image. From what I have learnt so far, most of the OSM-based >>> > stacks implement "raster tiles" - all images are pre-rendered >>> as >>> > PNGs for speed. >>> > * We are trying to switch to vector based approach, where tiles >>> > are stored as data, and converted to image on request, either >>> by >>> > the server or by the user's browser. Which means that if you >>> > have retina screen, the image will be rendered twice the >>> regular >>> > size, and will be much crispier. This also means that you can >>> > rotate it on your device, or dynamically change the language. >>> > * I suspect, and please update me on this if you know the >>> > details, that the built-in iOS implementation can only handle >>> > images (raster) from the 3rd party (WMF). Mapbox's vector >>> format >>> > is gaining in acceptance, and IIRC, has been selected by OSM >>> > community in general for the future development, but I am not >>> > sure iOS supports it natively. >>> > >>> > On Wed, May 27, 2015 at 10:24 PM, Brian Gerstle >>> > <bgerstle(a)wikimedia.org <mailto:bgerstle@wikimedia.org>> >>> wrote: >>> > >>> > Agree with Corey, I've mentioned this elsewhere >>> > < >>> https://www.mail-archive.com/mobile-l@lists.wikimedia.org/msg03395.html >>> >, >>> > but it's important to note that as of iOS 6 >>> > <https://blog.openstreetmap.org/2012/10/02/apple-maps/>, >>> > Apple has been (and still appears to be >>> > < >>> http://applemapsmarketing.com/2014/11/open-street-map-apple-maps/>) >>> > using OSM for map data. I don't know the rationale behind >>> > why we need our own OSM servers, but does that rationale >>> > also prevent our iOS app from using Apple-provided OSM >>> data? >>> > >>> > >>> > On Wed, May 27, 2015 at 4:05 PM, Corey Floyd >>> > <cfloyd(a)wikimedia.org <mailto:cfloyd@wikimedia.org>> >>> wrote: >>> > >>> > Any reason to import a 3rd party library for >>> > functionality built in to the iOS SDK? Seems like work >>> > to explore/integrate a dependency where none is needed. >>> > Without this extra work, this is something that can be >>> > built in < 1 day. >>> > >>> > >>> > >>> > On Wed, May 27, 2015 at 10:01 PM, Brian Gerstle >>> > <bgerstle(a)wikimedia.org <mailto:bgerstle@wikimedia.org >>> >> >>> > wrote: >>> > >>> > Cool, looks like mapbox has an iOS SDK >>> > <https://www.mapbox.com/mapbox-ios-sdk/>. Is >>> there >>> > somewhere that the progress on funding is being >>> > tracked? Put another way, where should I direct >>> PM, >>> > design, etc. to get this prioritized? Also, I >>> think >>> > it'd be worth it to ship this to a percentage of >>> > users to (further) validate the feature. >>> > >>> > On Wed, May 27, 2015 at 3:56 PM, Yuri Astrakhan >>> > <yastrakhan(a)wikimedia.org >>> > <mailto:yastrakhan@wikimedia.org>> wrote: >>> > >>> > Current state of affairs: >>> > https://karta.wmflabs.org/static/ is up and >>> > running, and should have all the data soon. It >>> > uses mapbox stack, which means that it >>> generates >>> > vector data tiles, and creates a PNG tiles on >>> > the fly. This also means that in a few days, >>> you >>> > will be able to view WebGL based maps there too >>> > - rendered on the browser, with multiple >>> styles, >>> > and rotatable. >>> > >>> > The community needs this service, and has >>> > already built a large number of amazing >>> projects >>> > even without the production-level vector >>> > service. Examples include >>> > * atlas-style drill-down map >>> > < >>> http://umap.openstreetmap.fr/de/map/wikipedia-clustermap_36725> >>> > (umap, see more info >>> > <http://umap.openstreetmap.fr/>) >>> > * Wikidata-based map of pages by class >>> > < >>> https://tools.wmflabs.org/wp-world/wikidata/superclasses.php?lang=en>, >>> > e.g. all rollercoasters >>> > < >>> https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=en&uselang=en… >>> >. >>> > * There is an amazing presentation >>> > < >>> https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.pdf> >>> > (pdf) by Kolossos (Tim Adler), that gives many >>> > more examples of the community-built map >>> > services and projects (OpenOffice format >>> > < >>> https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.odp>) >>> > >>> > >>> > P.S. Tomasz, it's Yuri, not Yuvi, and don't >>> > blame IRC auto-complete :) >>> > >>> > On Wed, May 27, 2015 at 7:57 PM, Max Semenik >>> > <maxsem.wiki(a)gmail.com >>> > <mailto:maxsem.wiki@gmail.com>> wrote: >>> > >>> > Hey - yes, we're workig on serving map >>> > tiles. Both raster and MapBox vectors. Our >>> > current demo implementation is >>> > at https://karta.wmflabs.org/static/ - >>> only >>> > raster tiles ATM, vectors coming in 1-2 >>> > days. The main problem, however, is >>> > budgeting - yet if we get very little >>> > hardware, concentrating on maps for apps >>> > might even be a reasonable option as apps >>> > traffic might be lower than if we exposed >>> > maps to all web users. Getting no bugdet at >>> > all is also a possible outcome, though. >>> > >>> > >>> _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > EN Wikipedia user >>> > page: >>> https://en.wikipedia.org/wiki/User:Brian.gerstle >>> > IRC: bgerstle >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > Corey Floyd >>> > Software Engineer >>> > Mobile Apps / iOS >>> > Wikimedia Foundation >>> > >>> > >>> > >>> > >>> > -- >>> > EN Wikipedia user >>> > page: https://en.wikipedia.org/wiki/User:Brian.gerstle >>> > IRC: bgerstle >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org <mailto: >>> Mobile-l(a)lists.wikimedia.org> >>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > Tilman Bayer >>> > Senior Analyst >>> > Wikimedia Foundation >>> > IRC (Freenode): HaeB >>> > >>> > _______________________________________________ >>> > reading-wmf mailing list >>> > reading-wmf(a)lists.wikimedia.org <mailto: >>> reading-wmf(a)lists.wikimedia.org> >>> > https://lists.wikimedia.org/mailman/listinfo/reading-wmf >>> > >>> > >>> >> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> > > > _______________________________________________ > reading-wmf mailing list > reading-wmf(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/reading-wmf > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l July 2015