I've added the final major portion to (this version) of my page on polyline and polygon encoding - namely, documentation of the PolylineEncoder class. This class makes it easy to encode a polyline on the fly in javascript.
To use it, you first instantiate an object of the PolylineEncoder class. For example: pe = new PolylineEncoder();
Now, suppose you've got a path defined by an array of GLatLngs stored in the variable points. Generation of an encoded polyline representing this path is as simple as: polyline = pe.dpEncodeToGPolyline(points);
That's it - the variable polyline now holds an encoded polyline. Of course, you now need to add it as an overlay and you need to make sure that your script has access to the class definition in PolylineEncoder.js.
The constructor has optional arguments, that affect the encoding algorithm. The dpEncodeToGPolyline method has several optional arguments to specify the style of the line. There is an analogous method, dpEncodeToGPolygon, that accepts an array of arrays of GLatLngs specifying the portions of the boundary of a polygon and returning an encoded polygon.
Bear in mind that the encoding process is computationally intensive and takes time. If you have a small number of static maps with complicated path data, then it is definitely best to pre-encode those paths. If you have an extremely complicated path (say tens of thousands of vertices), then on the fly encoding with javascript will simply take too long; perhaps, a compiled server side encoding program could work. If, however, you have dynamically generated data that is moderately complicated (say a few hundred to a few thousand points), then on the fly encoding with javascript might be a reasonable approach.
I might have misunderstood an aspect of using your class: I used to create GPolyline after accumulating GPoints read from an NMEA file, but obvisouly for tracks several hours long at 1 point/s, plotting such polygons can become very time consuming. So I tried replacing
On May 19, 12:16 pm, jmfriedt <frie...@free.fr> wrote:
> I might have misunderstood an aspect of using your class: > ... > but I have doubts I have improved the rendering of my tracks.
Here are a few suggestions.
First, unless this is just one example of a dynamically generated map, then I'd suggest pre-encoding the points, rather than using the PolylineEncoder. While this does not really affect the behavior as the map zooms or pans, it strongly affects the startup time.
Second, your data has a few anomalies. For example, the longitude of one point is 485048.843053 and the latitude of another is 22002.471953. This actually leads to some unprintable characters and I'm surprised that the map works without javascript errors. It also leads to what appear to be spurious horizontal and vertical lines.
Finally (and most importantly to get it run smoothly), you've represented the path with a collection of 82 encoded polylines, even though it appears that you can represent it just fine as a single path. Unfortunately, I don't think that the encoded polyline technique helps much when it comes to a collection of paths. I set up an example to illustrate: http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/aqExample...
Incidentally, you can see looking at this example that the algorithm does, in fact, remove many of the points. Your original data had about 7400 points and the levels string of the (single path) encoded polyline has only 1400 characters. I should also mention that I took verySmall (your pres) to be 0.00001, rather than your choice of 0.000001. Both seem to work fine, but I'd expect a bit of a performance boost (without significant loss of detail) with the larger value.
Ideed you are absolutely correct, I had points in my LatLon list with invalid coordinates due to a mistake in my NMEA decoding function. After correcting this mistake and getting all the points in the right range, I can indeed observe the acceleration associated with the use of the Encoded Polyline and most significantly the fact that I no longer have to cut my trace in small 100-point long GPolyline but I can now display the whole trace as a single, big, encoded polyline. I can easily imagine now that due to these erroneous points, your algorithm for defining the level of each point was confused and assumed it had to plot all the points at all zoomlevels.
Indeed my objective was to write a script for anyone to put an NMEA file on the web and point the script to the track file for displaying over GM, hence the need for dynamic encoding of the polyline.
On May 20, 7:48 am, jmfriedt <frie...@free.fr> wrote:
> Ideed you are absolutely correct, I had points in my LatLon list with > invalid coordinates due to a mistake in my NMEA decoding > function. > ... > Indeed my objective was to write a script for anyone to put an NMEA > file on the web and point the script to the track file for displaying > over GM, hence the need for dynamic encoding of the polyline.
