This project has moved. For the latest updates, please go here.

Display More Records

May 29, 2014 at 8:13 PM
How can I display more than 250 records on the map? The maximum number of records per page is 250 and that's all that shows up on the map but I need to see more than that. Any help would be appreciated.
Coordinator
May 30, 2014 at 10:50 PM
At the very beginning of this project, I made a conscious decision to display the exact list of entities on the map that is being displayed in the list. Which means by extension that the chart is limited to same number of records that the list is limited to.
There are a number of reasons for this, performance and simplicity being the main reasons. Performance is a big one, it has to make a separate call to the bing maps web service to geocode the address of every record in the list. So if there's 250 being displayed, that's 250 web service calls. It does this every time the page is loaded. Before pin clustering was added, it was able to asynchronously add the pins to the map, which actually made a cool looking effect as they were added one a time. But now with pin clustering, they have to be added all at once, so the performance impact of that many web calls is very noticeable.
Then there's the issue of usability, if the map is displaying pins that are not in the grid list, it could cause some confusion to the users, since the map is supposed to be displaying the same data they are looking at and so there would be discrepancies.

It's also an all-or-nothing kind of issue. I can't add an option to allow an arbitrary maximum number of records to be displayed, it has to be the same records as the list, or it can be all the records returned by the view. Imagine a scenario where the user sees 250 records per page, and is on page 2 of a list of 1000 records. It's easy to get the 250 records that they are looking at. But if you want to arbitrarily allow 500 records per map, where would the other 250 records come from? There's no good way to determine which other records to retrieve. So the only option at this point is to allow all the records from all the pages in the view to be added on the map.

Back during version 1.0, I would say that displaying all the records on one map is beyond the intent of the chart map solution. But now that we're in 2.x, we have some options. I can add an option on the config page for the map, that will allow admins to specify if the map should display all records from the view, or just the records currently displayed. That will put the responsibility on the administrators to determine what is best for their organizations. Which is generally a good thing.


On a performance related note: Since pin clustering was added, and the slow performance of the geocoding is much more noticeable than it was before. I've been considering caching the latitude and longitude of the records. The oob entities already have fields to store those values, and of course I already have the code to do the geocoding, so it's just a matter of performing an update operation on the records. But one thing I never wanted to do was update data, the map just displays it. What I may do in the future is offer a second add-on solution that includes a plugin that will keep those values up to date, that way the map doesn't have to do any geocoding, and that would fix up the performance, even if a great number of records are on the map. The extra solution would be optional, and would need to clearly state exactly what it does.
Jun 17, 2014 at 1:06 AM
Hi Wedge, just a thought: would it be possible to display a paging indicator (e.g. P. 1/3) on the Map if the number of records >= the user's max number of records displayed? This way it would at least be evident that the map is trimming the view results (just as the grid UI trims the results) and would also give the user the option to page through. Might be a nice compromise to ease the End User confusion.
Coordinator
Sep 2, 2014 at 8:58 PM
Edited Sep 2, 2014 at 8:58 PM
A paging indicator wouldn't change much, as that exists on the grid already. I don't want to implement anything that already exists, that's what keeps this solution clean and intuitive and powerful.
The new caching feature in 2.2 is the first step I've added to being able to display all records on a single map. That feature is to follow later on...