The full code that illustrates the problem can be viewed at Web Page showing problem
The code, which mostly works, takes the query parameter searches a couple of FusionTables for matching records and zooms the map to the extent of the selected record. The problem occurs for a subset of the records, where it only zooms for part of some records (doesn't show the entire selection). I have narrowed this down to those records where the returned kml (generated from GIS coverage) consists of a MultiGeometry record. The calculated bounds appears to only be for the last LineString in the record.
Here is the section from the zoom.js file that is generating the incomplete bounds
if (geoXml.docs[0].gpolylines.length > 0) {
geoXml.docs[0].gpolylines[0].setMap(null);
if (i==0) var bounds = geoXml.docs[0].gpolylines[0].bounds;
else bounds.union(geoXml.docs[0].gpolylines[0].bounds);
} else if (geoXml.docs[0].gpolygons.length > 0) {
and this is the kml for the geoXml variable that is parsed.
"<MultiGeometry><LineString><coordinates>-80.234377,26.310641 -80.234312,26.31064
-80.233513,26.310636 -80.231503,26.310625 -80.231344,26.310624 -80.22946,26.310609
-80.227565,26.310592 -80.227448,26.310591 -80.225461,26.310576 -80.223426,26.310559
-80.222466,26.31055 -80.221437,26.310541 -80.220498,26.310533 -80.219425,26.310523
-80.217414,26.310504 -80.215964,26.310491 -80.21545,26.310485 -80.213368,26.310462
-80.21138,26.310436 -80.209695,26.310414 -80.20963,26.310416 -80.209566,26.310418
-80.209501,26.310421 -80.209436,26.310425 -80.209371,26.310429 -80.209306,26.310433
-80.209241,26.310438 -80.209176,26.310443 -80.209112,26.310449 -80.209047,26.310456
-80.208983,26.310463 -80.208918,26.31047 -80.208854,26.310478 -80.20879,26.310486
-80.208726,26.310496 -80.208661,26.310505 -80.208597,26.310515 -80.208533,26.310526
-80.208469,26.310537 -80.208406,26.310549 -80.208342,26.310561 -80.208279,26.310573
-80.208215,26.310586 -80.208172,26.310596</coordinates></LineString>
<LineString><coordinates>-80.204375,26.311873 -80.204235,26.311902 -80.204171,26.311909
-80.204106,26.311916 -80.204041,26.311922 -80.203977,26.311928 -80.203912,26.311934
-80.203848,26.31194 -80.203783,26.311945 -80.203718,26.311951 -80.203653,26.311956
-80.203588,26.311961 -80.203524,26.311966 -80.203459,26.311971 -80.203394,26.311975
-80.203329,26.311979 -80.203264,26.311983 -80.2032,26.311987 -80.203135,26.311991
-80.20307,26.311994 -80.203005,26.311998 -80.20294,26.312 -80.202875,26.312003
-80.20281,26.312006 -80.202745,26.312009 -80.20268,26.312011 -80.202615,26.312013
-80.20255,26.312014 -80.202485,26.312016
-80.202388,26.312019</coordinates></LineString>
<LineString><coordinates>-80.199882,26.312008 -80.199148,26.312003</coordinates></LineString>
<LineString><coordinates>-80.202369,26.312023 -80.200655,26.312014</coordinates></LineString>
</MultiGeometry>"
Is the problem one with my code needing to process each individual line string, and if so, can someone point me to an example of how to do that? Or is this a bug with the geoXML3 library?
Looks like a bug in geoxml3:
Doesn't seem to be correctly computing the bounds for multiple <LineString> tags in a <MultiGeometry> .
Created an issue in the issue tracker.
Fixed the issue.