1. Manage prices using the IMPORT feature.
2. Price tables are now paginated when there are more than 250 cells.
For example, for 100 places (set as both origin and destination), there would be 10,000 price cells per vehicle. If there are 3 vehicles, the browser will be trying to render 30,603 table cells (including labels) when the page loads. If the computer hardware (specifically RAM) is under powered, this may cause the browser to freeze, become unresponsive or crash.
Our recommendation is to keep the number of places to a minimum and use an ‘other‘ option to handle a wider area. We are, however, looking at ways to manage a high number of places more efficiently. We will update this article accordingly.
Is this only a problem during configurations in my admin page?
Or does it affect also the web browser and computer of the user when calculating prices?
Any effects on the server where cabgrid is executed?
This will primarily effect the admin section because it will load a table for each vehicle containing cells for every possible journey….
On the front-end, only one journey is looked up, so speed should not be effected.
It is really your browser or computer’s ability to render multiple price tables with a large number of cells that is the problem.
isnt it a idea to make area’s that you can mark like with hailo
then you dont have the problem with all the cells
CabGrid is intended to use a price grid (it’s in the name), rather than other pricing models – such as distance based calculations. Whilst this might not suit every application, it does result in accurate and consistent pricing for journeys it does cover.
Our sister product, TaxiMap, allows you to draw regions on a map and assign prices for journeys between them. See http://blog.taximap.co.uk/development/zone-to-zone-fixed-pricing-a-step-too-far/