# Mapping with MapQuest, part 2

January 22, 2008 Leave a comment

Okay, so this is not a direct extension of the last article on the MapQuest API. It is, instead, a further adventure on my journey. In this post, I am going to talk about drawing stuff on the map, along with a few other juicy topics.

In our application, we show triangles on the map to indicate locations where a vehicle reported in. The head of the triangle points in the direction of the bearing of the vehicle. This was a major undertaking, in many ways, as I had not worked with Trig functions in ages. Thanks to Kevin Spencer (another MVP) for the hand hold here. The theory is pretty simple, once you work with it.

I had first thought about graphics for the arrows, which we had done in previous mapping adventures, but this presented a few issues, no matter how you sliced it.

Option 1: I could create 16 graphics, one each for N, NNW, NW, WNW, W, etc. and calculate which one to use. This was not completely accurate, but fairly easy to place. In the end, there were two big negatives here. First, I would have to create the 16 graphics in each color the person could choose (current 216, for the 216 web colors). Second, there is no concept of opacity in graphics for the MapQuest API, so I could not alter graphic color easily by track, which was a requirement on the old system.

Option 2: Use GDI+ to alter the graphic according to angle. This would require only one graphic. The problems here are many fold. First, I cannot overlay the graphic myself, as the API does not allow overlays in this manner (graphics only added by path). Second, while the .NET GDI+ piece would create the new graphic, I end up with 260 graphics per color. Automated, yes, but still a lot of clutter. Finally, I still have the opacity issue.

So I determined I would use the polygon overlay and draw the arrow on the screen. To do this, you have to first convert your bearing (in degrees) to radians.

direction = ((bearing) / (180/Math.PI));

Next, you have to calculate X and Y using sine and cosine. Length here is the length of the line (if at 0 degrees) in fraction of a degree. For my head of my arrows, I am using .001371624705923663 as the length, but this is also dependent on zoom, which I still have to figure out.

latPosition1 = latitude + (length * Math.cos(bearing));

longPosition1 = longitude + (length * Math.sin(bearing));

So far, so good. To get the other two bearings, I change the length to length/3 and the bearing to bearing + 120 or bearing – 120. I then rerun the calculations above on the new values. This creates a polygon. Each of the lat/long points is then added to the MQLatLongCollection I call shapePoints. The entire thing looks like this.

var triangle = new MQPolygonOverlay();

triangle.setFillColor(fillColor);

triangle.setFillColorAlpha(fillColorAlpha);

triangle.setColor(lineColor);

triangle.setColorAlpha(lineColorAlpha);

triangle.setBorderWidth(lineWidth);

var shapePoints = new MQLatLngCollection();

latPosition1 = latitude + (length * Math.cos((direction) / (180/Math.PI)));

longPosition1 = longitude + (length * Math.sin((direction) / (180/Math.PI)));

shapePoints.add(new MQLatLng(latPosition1, longPosition1));

latPosition2 = latitude + (length/3 * Math.cos(((direction + 120) / (180/Math.PI))));

longPosition2 = longitude + (length/3 * Math.sin(((direction + 120) / (180/Math.PI))));

shapePoints.add(new MQLatLng(latPosition2, longPosition2));

latPosition3 = latitude + (length/3 * Math.cos(((direction – 120) / (180/Math.PI))));

longPosition3 = longitude + (length/3 * Math.sin(((direction – 120) / (180/Math.PI))));

shapePoints.add(new MQLatLng(latPosition3, longPosition3));

triangle.setShapePoints(shapePoints);

overlay.add(triangle);

After completing this, I took a look at the Microsoft Virtual Earth SDK. One of the tools is an interactive SDK demo, which shows you both what it is doing and how to do it. I compare this to the MapQuest SDK, which has guidebooks (for some features), very few samples, and class documentation (autogenerated from the source) and I am underwhelmed by MapQuest’s offering in many ways. I also have Google maps to examine, which is somewhere between the two. If I were a developer, I would rank the APIs this way:

- Microsoft Live Virtual Earth Map SDK
- Google Maps SDK
- MapQuest Advantage API

Even with Microsoft and Google, I would still have to figure out the Trig. 🙂

Peace and Grace,

Greg