I’m excited to be at the Esri Dev Summit this year. I’ll be giving a few talks – the details and links to the resources for those talks are listed below. Hope to see you there!
I’m super excited about the ArcGIS API for JavaScript 4.0 beta. One of the exciting things is developer friendly widgets which allows us to write our own presentation layer, and still use the logic of the core widget (the “View Model”). For example, the View Model for the Basemap Toggle Widget allows you to call toggle() and get the current/secondary basemaps, all from your own module that implements the view.
After reading through Odoenet’s great post on this subject, I thought I’d take his React example and throw together an equivalent view in Dojo.
In the postCreate function we’re setting up a watch (using dojo/stateful) and updating our thumbnails when we see the “secondaryBasemap” property change. The event for when the user clicks the thumbnail is using dijit/_TemplatedMixin to setup that event to call the toggle function when it is clicked. In our toggle function we’re just calling the View Model’s toggle function.
var BToggle = declare([_WidgetBase, _TemplatedMixin, Stateful], {
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L75-L78
templateString: '<div><div class="basemap-item basemap-item-secondary" data-dojo-attach-event="click:toggle" data-dojo-attach-point="secondaryBasemapItem"></div><div class="basemap-item basemap-item-current" data-dojo-attach-point="currentBasemapItem"></div></div>',
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L5-L9
bgImage: function(target, url) {
domStyle.set(target, 'background-image', 'url(' + url + ')');
},
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L13-L18
constructor: function() {
this.inherited(arguments);
this.vm = new BasemapToggleVM();
this.secondaryThumbnailUrl = '';
},
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L29-L50
postCreate: function() {
this.inherited(arguments);
this.vm.view = this.view;
this.vm.secondaryBasemap = this.secondaryBasemap;
var info = this.vm.getBasemapInfo(this.secondaryBasemap || 'topo');
this.updateThumbnails(info, this.vm.currentBasemap);
this.vm.watch('secondaryBasemap', lang.hitch(this, 'updateThumbnails'));
},
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L52-L59
updateThumbnails: function(secondary, current) {
var secInfo = this.vm.getBasemapInfo(secondary);
var curInfo = this.vm.getBasemapInfo(current);
this.bgImage(this.secondaryBasemapItem, secInfo.thumbnailUrl);
this.bgImage(this.currentBasemapItem, curInfo.thumbnailUrl);
},
// https://github.com/odoe/esrijs4-vm-react/blob/master/src/components/basemaptoggle.jsx#L61-L63
toggle: function(evt) {
this.vm.toggle();
}
});
The code is annotated with links back to the equivalent line numbers in Rene’s example. This was a great learning experience for learning the View Models concept in the JS API – I’d encourage you to write your own!
One of my goals for 2015 was to build and assemble a Raspberry Pi based Kitchen Dashboard. The original idea was to use Dashing.io via this tutorial, but the Ruby requirement of Dashing.io made developing custom widgets tougher for me on Windows, so I ended up switching to Atlasboard.
There were many reasons why this project had core problems with the idea. Some of those included:
Setting up the actual software that runs the dashboard was pretty fun – probably the best part of the project for me. I enjoyed configuring the Atlasboard widgets to my liking. I had to edit the Calendar app to work like I wanted it to with our meal planning web service. I also wanted a better weather widget, which I wrote and released on GitHub.
After using it for awhile, I actually took this down out of our kitchen. The benefits were not worth the costs. I enjoyed the project though – especially being able to release an open source widget for Atlasboard – and will maybe revisit the idea in the future.
Having developed methods to get the NBA player shotchart data and player movement data into ArcGIS, I wanted to explore different ways to visualize the player movement data with webmaps, ArcGIS application templates, and 3D web scenes. I also wanted to look at an entire game and find ways to identify where on the court players spend the most time and what lanes or routes players are more likely to travel across the court. For this post, I’m going to describe some approaches to visualize an entire game of movement data with common GIS techniques and tools and use some really cool GIS visualization techniques to display the data and compare player movement maps.
For this post, I looked at the movement data for the entire game between the Oklahoma City Thunder and Detroit Pistons from November 27, 2015. I aligned the data so that the northern end of the basketball court is the Thunder’s offensive end and the southern end of the court is the Piston’s. I filtered the data to remove duplicate timestamps for each player on the court. This has the effect of filtering out moments where game action is occurring but the clock is not moving (for example, foul shots). This is what I wanted to do because I was interested in where players spend time on the court when the game is in progress.
I don’t like new year’s resolutions. They are too often forgotten a few weeks down the road. I do, however, like to have short and long-term goals, and the beginning of a new year is a great time to reflect on what has been accomplished, and what to do in 2016.
2015 Completed List:
Of course there were goals I had that I didn’t reach, including running and blogging.
Goals for 2016: