There are many companies out there such as Google, Microsoft and
Yahoo, who have heavily invested in providing 3rd party
services for the benefit of software houses like MSM. Where possible we like to keep on top of
these developments to ensure that we can pass on some of the great
facilities being offered.
One such service is 'Mapping' and MSM have been able to harness
the power of the Google Maps API in one of our latest web applications.
The Google Maps API lets you embed maps in your own web pages
using JavaScript. The API provides a number of utilities for
manipulating maps (just like on the http://maps.google.com web page)
and adding content to the map through a variety of services,
allowing you to create robust maps applications on your
website.
This was used to great effect with a site recently developed http://www.allaboutschoolfees.com
This site provides useful information to parents by informing
them about which independent schools are within their local area,
the fees for those schools and how much they'll need to save to
send their children to them.
Parents can simply enter a postcode, town, county, or any other
type of location information and the application will then display
the closest schools to the location entered.
The solution described above seems simply enough, but beyond the
surface it presents a whole list of very complicated issues that
needed to be resolved.
One of which is the sheer number of schools that are held in the
system and how best to present this information sensibly to the
parent.
Due to the amount of client CPU processing required in plotting
hundreds of points on a map, it was not possible to merely plot
every school and allow the parent to pan and zoom accordingly.
There are options to summarise items upon the map, but what parents
are principally interested in are the closest schools.
As such we decided to develop a solution that would start by
showing the first closest 100 schools, and parents could then page
through to the next closest 100 schools, continuing to display
schools further and further from the original location. The visual
effect is that of a donut shape getting lager and thinner as the
parent displays the next set of schools.
The big question needed to be answered is, how does one
calculate the proximity of a point to the centre of the map?
Here's where it gets interesting!
At the equator the distance between two points can be calculated
using Pythagoras:
Where 'a' represents the longitudinal difference between the
'from' and 'to' points and 'b' represents the latitudinal
difference between the 'from' and 'to' point.
I say, 'at the equator' because the ratio between Longitude and
Latitude at the equator is 1:1, however the further away from the
equator the greater the ratio becomes. In order to overcome this,
one needs to adjust the ratio according to the latitudes distance
from the equator.
This can be done as follows:
ratio = 1/cos(Latitude)
Here is the c# code we used to perform the ratio calculation
passing a value for Latitude:
double RadianLat =
ConvertDegreesToRadians(Latitude);
decimal CosCal = Convert.ToDecimal(Math.Cos(RadianLat));
decimal ratio = decimal.Divide(1M, CosCal);
public static double
ConvertDegreesToRadians(double degrees)
{
return (Math.PI / 180) * degrees;
}
One issue in doing this in c# is that some of the functions are
calculated in degrees and others in radians, hence the mix.
To apply this 'ordering of proximity' in the SQL code itself we
used the following:
SQRT( square(lng - School.Longitude) + square( (lat -
School.Latitude) * r) ) AS Distance
Where
lng = the Longitude of the 'From Point'
lat = the Latitude of the 'From Point'
r = ratio.
This gives you a sense of how complex it can be sometimes to
resolve the simplest of solutions, in this case merely the distance
between two points and using this to order data coming back from
the database.
Many skills need to be evoked when designing an effective user
interface, not just the technical expertise in working out a
feasible solution, but also keeping a keen eye at all times on the
simplicity of how the system is to be used. One must ensure that
users are not overwhelmed by what is before them and that the
choices to be made are intuitive and meaningful.
There are many other very subtle behavioural changes we made to
the map, to ensure these principles were adhered to. One other
example was manipulating the zoom level to an appropriate setting
to ensure all schools were being properly displayed.
The facility to plot schools on a map also raises questions
about how this data would firstly get into the new application and
then how it could be maintained as new schools are entered and
updated.
As such we built into the school maintenance pages the facility
for an administrator to easily mark on the map where the school was
located.
The map code itself allows the facilities to:
Centre by a given location
Place a plot marker with extended information, which can also be
dragged to a different position
And load items from a separate external data feed
The solution is holistic, and provides an incredibly rich
experience to the end user.
What we have essentially done is taken the building tools that
have already been provided by Google and enhanced them to meet very
specific requirements and user needs.
Have a look for yourself by visiting : http://www.allaboutschoolfees.com
Enjoy.
