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
----------------------------------
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…
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
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
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.
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
[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
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
>
>
