earth-api-utility-library - Project Hosting on Google Code

Today 65 min ago r63 (Fix minor bug during JS compression affecting IE (variable m...) committed by api.roman.public - Fix minor bug during JS compression affecting IE (variable munging and yuckevalyuck). Fix minor bug during JS compression affecting IE (variable munging and yuckevalyuck). Last 30 days Nov 17, 2009 issue 21 (computeBounds() not working in IE) commented on by jmatth...@xexam.net - Thanks for the reply. I took a look at the source but have to admit I am too much of a novice to decipher it. I was able to partly decipher some of the properties of the bounds object that was created, and I found that the following two properties seem to be properly defined. //alert(bounds.center()); //alert(bounds.span().lat); Oddly, it used to generate an error message in IE, but now, it no longer does. It still fails, though. If I knew how to figure out what all the properties of the bounds object were supposed to be, then, I could probably dig into it. Thanks for the reply. I took a look at the source but have to admit I am too much of a novice to decipher it. I was able to partly decipher some of the properties of the bounds object that was created, and I found that the following two properties seem to be properly defined. //alert(bounds.center()); //alert(bounds.span().lat); Oddly, it used to generate an error message in IE, but now, it no longer does. It still fails, though. If I knew how to figure out what all the properties of the bounds object were supposed to be, then, I could probably dig into it. Earlier this year Nov 12, 2009 issue 21 (computeBounds() not working in IE) commented on by api.roman.public - Will get to this as soon as I have some time. If there's an easy fix, please feel free to submit a patch. Will get to this as soon as I have some time. If there's an easy fix, please feel free to submit a patch. Nov 12, 2009 issue 20 (Keep computeBounds() from crashing in IE) changed by api.roman.public - Status: Duplicate Status: Duplicate Nov 12, 2009 issue 21 (computeBounds() not working in IE) commented on by api.roman.public - Issue 20 has been merged into this issue. Issue 20 has been merged into this issue. Nov 10, 2009 issue 21 (computeBounds() not working in IE) reported by jmatth...@xexam.net - What steps will reproduce the problem? 1. 2. 3. Please disregard Issue #20 , written by me. I have since found that the bug is not reliant on existence of geometry associated with a feature (as described in that ticket). I have since associated a point with every placemark, and I tested every placemark to make sure it has a legitimate lat/lon. They all do. I am performing a computeBounds() on every placemark in a folder. It works fine in FF and Chrome. It does not work at all and reports a bug in IE. At the point of failure, it causes the application to crash. The bug is described in IE's "developer tools" as: extensions.pack.js, line 32, character 42701 I will be happy to share my source with you so that you can see what triggers it. In fact, I am going to try to attach the source now. In the source, you will see the pertinent lines to use to trigger and/or work-around the bug. They are the presently-commented lines 648, 649 and 654. With these lines commented out, the bug will occur. If you remove the comments and allow the code to bypass computeBounds() if browser is IE, then, it works fine, but of course not in IE. It just prevent attempts to computeBounds() if the detected browser is IE. Here are the relevant lines: if (browser.search(/Internet Explorer/i)==(-1)) { //alert(browser.search(/Internet Explorer/i)); //alert("Computing."); var bounds = gex.dom.computeBounds(folder); gex.view.setToBoundsView(bounds, {aspectRatio:2.3, scaleRange:2.5 }); } I will be happy to share any other information and am looking forward to helping to resolve this expeditiously. Thanks. What steps will reproduce the problem? 1. 2. 3. Please disregard Issue #20 , written by me. I have since found that the bug is not reliant on existence of geometry associated with a feature (as described in that ticket). I have since associated a point with every placemark, and I tested every placemark to make sure it has a legitimate lat/lon. They all do. I am performing a computeBounds() on every placemark in a folder. It works fine in FF and Chrome. It does not work at all and reports a bug in IE. At the point of failure, it causes the application to crash. The bug is described in IE's "developer tools" as: extensions.pack.js, line 32, character 42701 I will be happy to share my source with you so that you can see what triggers it. In fact, I am going to try to attach the source now. In the source, you will see the pertinent lines to use to trigger and/or work-around the bug. They are the presently-commented lines 648, 649 and 654. With these lines commented out, the bug will occur. If you remove the comments and allow the code to bypass computeBounds() if browser is IE, then, it works fine, but of course not in IE. It just prevent attempts to computeBounds() if the detected browser is IE. Here are the relevant lines: if (browser.search(/Internet Explorer/i)==(-1)) { //alert(browser.search(/Internet Explorer/i)); //alert("Computing."); var bounds = gex.dom.computeBounds(folder); gex.view.setToBoundsView(bounds, {aspectRatio:2.3, scaleRange:2.5 }); } I will be happy to share any other information and am looking forward to helping to resolve this expeditiously. Thanks. Nov 08, 2009 issue 20 (Keep computeBounds() from crashing in IE) reported by jmatth...@xexam.net - What steps will reproduce the problem? 1. In IE only, try to perform computeBounds() in a data set where any feature fails to contain a geometry associated with it. What is the expected output? What do you see instead? I can't say something different should be "expected," as it is a novel issue (probably novel), but if a feature (e.g. placemark) does not have a geometry (e.g. point) associated with it, computeBounds() will crash with an error message that the object (presumably getFeatures()) is not defined. It is understandable that when your application was designed, it was always assumed that a feature would have a geometry, but as you will see, your application is potentially much more than that. I am explaining why below. Instead, computeBounds() should ignore such features and continue calculating on the rest of the set. That way, bounds will be set on all included features which DO have associated geometries. Please use labels and text to provide additional information. Please improve computeBounds() and keep it from crashing in IE when a geometry is not associated with a feature. The reason for wanting to include placemarks without points is that a large set of data is being imported from another source unrelated to Google Earth. If this data does not include an address, you should still be able to write a placemark into a kml, just excluding a point. Why? Because the end application would be inferior if we had to associate points of coordinates (0,0) with every placemark whose address could not be found. To include such points would mean that computeBounds() would necessarily operate on a bunch of unfound addresses, and therefore, the bounding box would be defined to include these, making it unnecessarily too large of a box. Why have placemarks in the KML in the first place if the point data is unavailable? Because GE can be more than just a point finder. In my case, I use the placemark data as a database as well. I make liberal use of <ExtendedData> to store information on the placemark. I then use the placemark to access the <ExtendedData> in order to show information unrelated to point coordinates, such as last name, political party, phone number, and many other items. A navigation window is used in connection with the plug-in window to be able to click on placemarks and navigate to them. In addition to just using placemarks for plain-old navigation in the plug-in window, these placemarks are used to grab the ExtendedData and display it in other places outside the plug-in window. Further, the navigation tree is created based on the list of placemarks. To exclude placemarks from the kml file just because lat/lon is (0,0) would mean the navigation tree would be missing important data which could otherwise be tapped and used. It would be nice to be able to use it exactly this way and to just have computeBounds() ignore features with no geometry. Of course, it cannot navigate in the plug-in window to a placemark without a point, but I have that handled. That part was easy. In sum, there is no reason to crash computeBounds() just because a feature does not have a geometry. To change this behavior should be very easy to do, requiring perhaps the addition of any a few lines of code to check to see if getGeometry() is defined. To do so would not adversely affect any other application that relies on computeBounds(), and therefore, the function would be improved, and further, this would allow the GE plug-in to be more than just a way to map points. Its ExtendedData, by itself, can be used as a robust database for use of the fields in display manipulation. Since computeBounds() currently crashes, a catch-22 is created. I can either (a) eliminate placemarks and the robust set of data that is associated with them, or (2) keep the placemarks in and have computeBounds() include coordinates of (0,0) every time a bounds is computed. Here is the website link to see this behavior in action. Please note, it works fine in FF and Chrome. http://www.sovereignstates.net/StateLegislators/VSLegislators.htm Thanks, and if you elect to make this improvement, could you please notify me by e-mail? What steps will reproduce the problem? 1. In IE only, try to perform computeBounds() in a data set where any feature fails to contain a geometry associated with it. What is the expected output? What do you see instead? I can't say something different should be "expected," as it is a novel issue (probably novel), but if a feature (e.g. placemark) does not have a geometry (e.g. point) associated with it, computeBounds() will crash with an error message that the object (presumably getFeatures()) is not defined. It is understandable that when your application was designed, it was always assumed that a feature would have a geometry, but as you will see, your application is potentially much more than that. I am explaining why below. Instead, computeBounds() should ignore such features and continue calculating on the rest of the set. That way, bounds will be set on all included features which DO have associated geometries. Please use labels and text to provide additional information. Please improve computeBounds() and keep it from crashing in IE when a geometry is not associated with a feature. The reason for wanting to include placemarks without points is that a large set of data is being imported from another source unrelated to Google Earth. If this data does not include an address, you should still be able to write a placemark into a kml, just excluding a point. Why? Because the end application would be inferior if we had to associate points of coordinates (0,0) with every placemark whose address could not be found. To include such points would mean that computeBounds() would necessarily operate on a bunch of unfound addresses, and therefore, the bounding box would be defined to include these, making it unnecessarily too large of a box. Why have placemarks in the KML in the first place if the point data is unavailable? Because GE can be more than just a point finder. In my case, I use the placemark data as a database as well. I make liberal use of <ExtendedData> to store information on the placemark. I then use the placemark to access the <ExtendedData> in order to show information unrelated to point coordinates, such as last name, political party, phone number, and many other items. A navigation window is used in connection with the plug-in window to be able to click on placemarks and navigate to them. In addition to just using placemarks for plain-old navigation in the plug-in window, these placemarks are used to grab the ExtendedData and display it in other places outside the plug-in window. Further, the navigation tree is created based on the list of placemarks. To exclude placemarks from the kml file just because lat/lon is (0,0) would mean the navigation tree would be missing important data which could otherwise be tapped and used. It would be nice to be able to use it exactly this way and to just have computeBounds() ignore features with no geometry. Of course, it cannot navigate in the plug-in window to a placemark without a point, but I have that handled. That part was easy. In sum, there is no reason to crash computeBounds() just because a feature does not have a geometry. To change this behavior should be very easy to do, requiring perhaps the addition of any a few lines of code to check to see if getGeometry() is defined. To do so would not adversely affect any other application that relies on computeBounds(), and therefore, the function would be improved, and further, this would allow the GE plug-in to be more than just a way to map points. Its ExtendedData, by itself, can be used as a robust database for use of the fields in display manipulation. Since computeBounds() currently crashes, a catch-22 is created. I can either (a) eliminate placemarks and the robust set of data that is associated with them, or (2) keep the placemarks in and have computeBounds() include coordinates of (0,0) every time a bounds is computed. Here is the website link to see this behavior in action. Please note, it works fine in FF and Chrome. http://www.sovereignstates.net/StateLegislators/VSLegislators.htm Thanks, and if you elect to make this improvement, could you please notify me by e-mail? Oct 19, 2009 issue 19 (Placemarks not loading in IE8) commented on by jmatth...@xexam.net - Also, FYI, the only states that have geocoding are AL, CA and TX, so check and compare only those. Also, FYI, the only states that have geocoding are AL, CA and TX, so check and compare only those. Oct 19, 2009 issue 19 (Placemarks not loading in IE8) reported by jmatth...@xexam.net - What steps will reproduce the problem? 1. Run my code in Firefox (it works). 2. Run it in IE 8 (it doesn't). What is the expected output? What do you see instead? Upon page load, placemarks should be put into the GE viewer. It does not appear they are when the browser is IE8. It does work in Firefox. Please use labels and text to provide additional information. Here is my page, so you can check: http://www.sovereignstates.net/StateLegislators/VSLegTracker.php I think you have a fabulous library! If I can help in any way, please let me know. Relevant source code below. (Sorry, can't get indents on this text window). function initCB(instance) { ge = instance; ge.getWindow().setVisibility(true); var gex = new GEarthExtensions(ge); ge.getNavigationControl().setVisibility(ge.VISIBILITY_SHOW); ge.getLayerRoot().enableLayerById(ge.LAYER_ROADS, true); ge.getLayerRoot().enableLayerById(ge.LAYER_BORDERS, true); gex.dom.clearFeatures(); var folder = gex.dom.addFolder( { name: "Legislators" }); for (i=0;i<latitudes.length;i++) { nlatitude=parseFloat(latitudes[i].firstChild.nodeValue); nlongitude=parseFloat(longitudes[i].firstChild.nodeValue); if (nlatitude!=0 && nlongitude!=0) { placemark=gex.dom.addPointPlacemark( [nlatitude, nlongitude], { name: names[i].firstChild.nodeValue }); folder.getFeatures().appendChild(placemark); } } //for i var bounds = gex.dom.computeBounds(folder); gex.view.setToBoundsView(bounds, {aspectRatio:1.5, scaleRange:2.0 }); } // end initCB(instance) What steps will reproduce the problem? 1. Run my code in Firefox (it works). 2. Run it in IE 8 (it doesn't). What is the expected output? What do you see instead? Upon page load, placemarks should be put into the GE viewer. It does not appear they are when the browser is IE8. It does work in Firefox. Please use labels and text to provide additional information. Here is my page, so you can check: http://www.sovereignstates.net/StateLegislators/VSLegTracker.php I think you have a fabulous library! If I can help in any way, please let me know. Relevant source code below. (Sorry, can't get indents on this text window). function initCB(instance) { ge = instance; ge.getWindow().setVisibility(true); var gex = new GEarthExtensions(ge); ge.getNavigationControl().setVisibility(ge.VISIBILITY_SHOW); ge.getLayerRoot().enableLayerById(ge.LAYER_ROADS, true); ge.getLayerRoot().enableLayerById(ge.LAYER_BORDERS, true); gex.dom.clearFeatures(); var folder = gex.dom.addFolder( { name: "Legislators" }); for (i=0;i<latitudes.length;i++) { nlatitude=parseFloat(latitudes[i].firstChild.nodeValue); nlongitude=parseFloat(longitudes[i].firstChild.nodeValue); if (nlatitude!=0 && nlongitude!=0) { placemark=gex.dom.addPointPlacemark( [nlatitude, nlongitude], { name: names[i].firstChild.nodeValue }); folder.getFeatures().appendChild(placemark); } } //for i var bounds = gex.dom.computeBounds(folder); gex.view.setToBoundsView(bounds, {aspectRatio:1.5, scaleRange:2.0 }); } // end initCB(instance) Oct 07, 2009 issue 18 (My Earth demo does not pop balloons in FF 3.014) commented on by christopher.co - Windows XP SP2 Neither edit-mode nor view-mode worked. Windows XP SP2 Neither edit-mode nor view-mode worked. Oct 07, 2009 issue 18 (My Earth demo does not pop balloons in FF 3.014) commented on by api.roman.public - Couldn't repro in Firefox 3.5 on Windows. Chris, was this on Windows or Mac? Also, were you in edit mode or view mode? Couldn't repro in Firefox 3.5 on Windows. Chris, was this on Windows or Mac? Also, were you in edit mode or view mode? Oct 07, 2009 issue 18 (My Earth demo does not pop balloons in FF 3.014) reported by christopher.co - What steps will reproduce the problem? 1. Visit http://earth-api-samples.googlecode.com/svn/trunk/demos/myearth/index.html in FF 3.014 2. Open a My Map 3. Select a placemark You expect an Earth balloon to pop open, but nothing happens. This works in Chrome 3.0.195.25. What steps will reproduce the problem? 1. Visit http://earth-api-samples.googlecode.com/svn/trunk/demos/myearth/index.html in FF 3.014 2. Open a My Map 3. Select a placemark You expect an Earth balloon to pop open, but nothing happens. This works in Chrome 3.0.195.25. Oct 06, 2009 issue 17 (gex.edit.place inside a gex.edit.place dropcallback doesn't ...) Status changed by api.roman.public - Fixed in trunk, see Revision 62 Status: Fixed Fixed in trunk, see Revision 62 Status: Fixed Oct 06, 2009 r62 (Minor bugfix; fixes Issue 17) committed by api.roman.public - Minor bugfix; fixes Issue 17 Minor bugfix; fixes Issue 17 Oct 06, 2009 issue 17 (gex.edit.place inside a gex.edit.place dropcallback doesn't ...) Status changed by api.roman.public - Status: Accepted Status: Accepted Oct 06, 2009 issue 17 (gex.edit.place inside a gex.edit.place dropcallback doesn't ...) reported by christopher.co - What steps will reproduce the problem? 1. Visit the draggable demo 2. Paste and run: gex.dom.clearFeatures(); function dropCallback() { var pm2 = gex.dom.addPointPlacemark([0, 0], { name: 'Champion2' }); gex.edit.place(pm2, { dropCallback: function() { dropCallback(); // This does work: //setTimeout(function() { // dropCallback(); //}, 100); } }); } dropCallback(); What steps will reproduce the problem? 1. Visit the draggable demo 2. Paste and run: gex.dom.clearFeatures(); function dropCallback() { var pm2 = gex.dom.addPointPlacemark([0, 0], { name: 'Champion2' }); gex.edit.place(pm2, { dropCallback: function() { dropCallback(); // This does work: //setTimeout(function() { // dropCallback(); //}, 100); } }); } dropCallback(); Sep 17, 2009 extensions-0.2.pack.js (GEarthExtensions Release 0.2, Packed) file uploaded by api.roman.public Sep 17, 2009 extensions-0.2.js (GEarthExtensions Release 0.2, Uncompressed) file uploaded by api.roman.public Sep 17, 2009 r61 (Tagged release 0.2 ) committed by api.roman.public - Tagged release 0.2 Tagged release 0.2 Sep 17, 2009 r60 (Updated svn:ignore to ignore build/ directory) committed by api.roman.public - Updated svn:ignore to ignore build/ directory Updated svn:ignore to ignore build/ directory Sep 17, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) commented on by alexis.dagues - Nice, thanks. Nice, thanks. Sep 17, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) Status changed by api.roman.public - Trunk should work in IE now; 0.2 is coming very soon. Status: Fixed Trunk should work in IE now; 0.2 is coming very soon. Status: Fixed Sep 17, 2009 issue 16 (documentation of gex.dom.buildScreenOverlay is incorrect) Status changed by api.roman.public - Status: Fixed Status: Fixed Sep 17, 2009 10 Wiki pages changed by api.roman.public - Revision r59 Docs updates Added GEarthExtensionsMath3dReference Edited GEarthExtensionsDomReference, GEarthExtensionsEditReference, GEarthExtensionsFxAnimationReference, GEarthExtensionsFxReference, GEarthExtensionsFxTimedAnimationReference, GEarthExtensionsReference, GEarthExtensionsUtilReference, GEarthExtensionsViewReference, WikiNav">WikiNav Revision r59 Docs updates Added GEarthExtensionsMath3dReference Edited GEarthExtensionsDomReference, GEarthExtensionsEditReference, GEarthExtensionsFxAnimationReference, GEarthExtensionsFxReference, GEarthExtensionsFxTimedAnimationReference, GEarthExtensionsReference, GEarthExtensionsUtilReference, GEarthExtensionsViewReference, WikiNav">WikiNav Sep 17, 2009 r59 (Docs updates) committed by api.roman.public - Docs updates Docs updates Sep 17, 2009 r58 (Fix a minor bug with line string drawing that didn't repeat ...) committed by api.roman.public - Fix a minor bug with line string drawing that didn't repeat the first coordinate to the end when finishing the draw by clicking the first coordinate Fix a minor bug with line string drawing that didn't repeat the first coordinate to the end when finishing the draw by clicking the first coordinate Sep 17, 2009 issue 16 (documentation of gex.dom.buildScreenOverlay is incorrect) commented on by nrat...@gmail.com - same for size, it isn't optional. same for size, it isn't optional. Sep 17, 2009 issue 16 (documentation of gex.dom.buildScreenOverlay is incorrect) reported by nratani - screenXY is listed as optional, but it isn't: Required parameter 'screenXY' was not passed. screenXY is listed as optional, but it isn't: Required parameter 'screenXY' was not passed. Sep 16, 2009 r57 (Added JSLint build target to build.xml and minor test-relate...) committed by api.roman.public - Added JSLint build target to build.xml and minor test-related cleanup Added JSLint build target to build.xml and minor test-related cleanup Sep 16, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) commented on by api.roman.public - Hoping to release 0.2 by the end of the month, but not certain I'll be able to do that. Really all that's left is browser compatibility though. Hoping to release 0.2 by the end of the month, but not certain I'll be able to do that. Really all that's left is browser compatibility though. Sep 16, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) commented on by alexis.dagues - Hi, thanks for your reply, we have to do like you, and waiting the 0.2 release to debug IE versions ! Have you an idea of release date ? Hi, thanks for your reply, we have to do like you, and waiting the 0.2 release to debug IE versions ! Have you an idea of release date ? Sep 15, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) Status changed by api.roman.public - Hi, thanks for the report. I generally don't test in IE until an official release. I'll be sure to run all tests and samples on IE6, 7, and 8 before releasing GEarthExtensions 0.2 (hopefully soon). Status: Accepted Hi, thanks for the report. I generally don't test in IE until an official release. I'll be sure to run all tests and samples on IE6, 7, and 8 before releasing GEarthExtensions 0.2 (hopefully soon). Status: Accepted Sep 15, 2009 issue 15 (Trunk version of GEX doesn't work with Internet Explorer 7) reported by alexis.dagues - What steps will reproduce the problem? 1.Launch IE 7 2.Try sample codes 3.GEX object can't be instantiated What is the expected output? What do you see instead? May work as Internet Explorer 8, we can't use last functionalities added to this library.. Please use labels and text to provide additional information. What steps will reproduce the problem? 1.Launch IE 7 2.Try sample codes 3.GEX object can't be instantiated What is the expected output? What do you see instead? May work as Internet Explorer 8, we can't use last functionalities added to this library.. Please use labels and text to provide additional information. Sep 13, 2009 r56 (Major build process reorg and overall project cleanup, also ...) committed by api.roman.public - Major build process reorg and overall project cleanup, also switch back to YUI Compressor Major build process reorg and overall project cleanup, also switch back to YUI Compressor Sep 05, 2009 r55 (Added unit and interactive tests, also reorganized files in ...) committed by api.roman.public - Added unit and interactive tests, also reorganized files in util Added unit and interactive tests, also reorganized files in util Sep 04, 2009 r54 (Fixed an annoying edge case in polygon editing when number o...) committed by api.roman.public - Fixed an annoying edge case in polygon editing when number of coordinates = 2 (two midpoints instead of one). Also renamed example titles. Fixed an annoying edge case in polygon editing when number of coordinates = 2 (two midpoints instead of one). Also renamed example titles. Sep 04, 2009 r53 (Added a bunch of interactive tests and improved interactive ...) committed by api.roman.public - Added a bunch of interactive tests and improved interactive test UI Added a bunch of interactive tests and improved interactive test UI Sep 03, 2009 issue 14 (fx.TimedAnimation multiple completion function calls) Status changed by api.roman.public - Sorry for the delay, fixed in trunk as of Revision 52. Status: Fixed Sorry for the delay, fixed in trunk as of Revision 52. Status: Fixed Sep 03, 2009 r52 (Animation and effects related tweaks and fixes.) committed by api.roman.public - Animation and effects related tweaks and fixes. Animation and effects related tweaks and fixes. Aug 28, 2009 issue 11 (Make sure gex.edit.drawLineString results in counter clockwi...) Status changed by api.roman.public - Fixed in trunk (Revision 51), new sample here: http://earth-api-utility-library.googlecode.com/svn/trunk/extensions/examples/poly-draw-extruded.html works with both clockwise and counter clockwise polygons. Status: Fixed Fixed in trunk (Revision 51), new sample here: http://earth-api-utility-library.googlecode.com/svn/trunk/extensions/examples/poly-draw-extruded.html works with both clockwise and counter clockwise polygons. Status: Fixed Aug 28, 2009 r51 (Added enforce counterclockwise default-on option for drawLin...) committed by api.roman.public - Added enforce counterclockwise default-on option for drawLineString; also slight change to Makefile, just use geojs/dist, don't recompile Added enforce counterclockwise default-on option for drawLineString; also slight change to Makefile, just use geojs/dist, don't recompile Aug 18, 2009 r49 (Added gex.math3d and gex.view.createVantageView. Fixed multi...) committed by api.roman.public - Added gex.math3d and gex.view.createVantageView. Fixed multiple instances bug. Merged in geojs trunk into dist files. Minor other fixes. Added gex.math3d and gex.view.createVantageView. Fixed multiple instances bug. Merged in geojs trunk into dist files. Minor other fixes. Aug 12, 2009 issue 14 (fx.TimedAnimation multiple completion function calls) Status changed by api.roman.public - The original reasoning was to handle the case where frameend wouldn't get called if nothing changed in the 3D view. This may or may not still be possible. I'll investigate. Thanks for filing the bug! Status: Accepted The original reasoning was to handle the case where frameend wouldn't get called if nothing changed in the 3D view. This may or may not still be possible. I'll investigate. Thanks for filing the bug! Status: Accepted Aug 12, 2009 issue 14 (fx.TimedAnimation multiple completion function calls) reported by nik.vandenwijngaert - I'm using a TimedAnimation to animate an object over a set of linestrings; here's the code I'm using: var duration = 1000; function animate_car (object, placemark) { var startlat = placemark.getGeometry ().getCoordinates ().get(0).getLatitude (); var startlon = placemark.getGeometry ().getCoordinates ().get(0).getLongitude (); var endlat = placemark.getGeometry ().getCoordinates ().get(1).getLatitude (); var endlon = placemark.getGeometry ().getCoordinates ().get(1).getLongitude (); var location = object.getGeometry().getLocation(); var anim = new gex.fx.TimedAnimation (duration, function (t) { location.setLatitude (startlat + (endlat-startlat)1.0t/duration); location.setLongitude (startlon + (endlon-startlon)1.0t/duration); }, function () { var next_sibling = placemark.getNextSibling (); animate_car (object, next_sibling); }); So each second we should traverse one placemark, and then move onto the next. The problem I'm having is that the "completionfunction" is called more than once occasionally. From inspecting the code for the TimedAnimation, it appears that the renderer functions are listening for _both_ the GE "frameend" and a tick of 100ms. If I comment either one of these out, everything works fine. What is the reason for the 100ms tick to be there, and can't we get by with only the GE frameend? I'm assuming that multiple invocations of the completion function stem from both the frameend and 100ms tick timing out at the exact same time, causing a duplicate call... kind regards, Nik. I'm using a TimedAnimation to animate an object over a set of linestrings; here's the code I'm using: var duration = 1000; function animate_car (object, placemark) { var startlat = placemark.getGeometry ().getCoordinates ().get(0).getLatitude (); var startlon = placemark.getGeometry ().getCoordinates ().get(0).getLongitude (); var endlat = placemark.getGeometry ().getCoordinates ().get(1).getLatitude (); var endlon = placemark.getGeometry ().getCoordinates ().get(1).getLongitude (); var location = object.getGeometry().getLocation(); var anim = new gex.fx.TimedAnimation (duration, function (t) { location.setLatitude (startlat + (endlat-startlat)1.0t/duration); location.setLongitude (startlon + (endlon-startlon)1.0t/duration); }, function () { var next_sibling = placemark.getNextSibling (); animate_car (object, next_sibling); }); So each second we should traverse one placemark, and then move onto the next. The problem I'm having is that the "completionfunction" is called more than once occasionally. From inspecting the code for the TimedAnimation, it appears that the renderer functions are listening for _both_ the GE "frameend" and a tick of 100ms. If I comment either one of these out, everything works fine. What is the reason for the 100ms tick to be there, and can't we get by with only the GE frameend? I'm assuming that multiple invocations of the completion function stem from both the frameend and 100ms tick timing out at the exact same time, causing a duplicate call... kind regards, Nik. Aug 10, 2009 r48 (Fix minor bug in gex.dom.walk related to polygon boundaries,...) committed by api.roman.public - Fix minor bug in gex.dom.walk related to polygon boundaries, also document buildRegion's lod parameter Fix minor bug in gex.dom.walk related to polygon boundaries, also document buildRegion's lod parameter Aug 10, 2009 issue 13 (callback options for util.displayKml) Status changed by api.roman.public - Yes, I was thinking to add this, but decided not to, in order to future proof for network links (network links don't have an 'onload' callback). I will add this though, thanks. Status: Accepted Yes, I was thinking to add this, but decided not to, in order to future proof for network links (network links don't have an 'onload' callback). I will add this though, thanks. Status: Accepted Aug 10, 2009 issue 13 (callback options for util.displayKml) reported by underbluewaters - It would be really useful to be able to provide a callback that accepts the kmlObject as an argument after the kml file is loaded. It would be really useful to be able to provide a callback that accepts the kmlObject as an argument after the kml file is loaded. Aug 09, 2009 issue 9 (JS for addPointPlacemark) commented on by api.roman.public - Note that a simple implementation calling balloon.setContentString(event.getTarget().getDescription()); would not take BalloonStyle and entity replacements into account. Just a note--I'll still implement this at some point. Note that a simple implementation calling balloon.setContentString(event.getTarget().getDescription()); would not take BalloonStyle and entity replacements into account. Just a note--I'll still implement this at some point. Aug 08, 2009 issue 10 (option for util.displayKml to update camera) Status changed by api.roman.public - Implemented in trunk. I haven't updated the reference yet, but you can look at the commit for sample usage: http://code.google.com/p/earth-api-utility-library/source/detail?r=47 Status: Fixed Implemented in trunk. I haven't updated the reference yet, but you can look at the commit for sample usage: http://code.google.com/p/earth-api-utility-library/source/detail?r=47 Status: Fixed Aug 08, 2009 r47 (Implement issue 10 and related stuff around KML and flyToFea...) committed by api.roman.public - Implement issue 10 and related stuff around KML and flyToFeature Implement issue 10 and related stuff around KML and flyToFeature

issue 20 (Keep computeBounds() from crashing in IE) reported by jmatth...@xexam.net - What steps will reproduce the problem? 1. In IE only, try to perform computeBounds() in a data set where any feature fails to contain a geometry associated with it. What is the expected output? What do you see instead? I can't say something different should be "expected," as it is a novel issue (probably novel), but if a feature (e.g. placemark) does not have a geometry (e.g. point) associated with it, computeBounds() will crash with an error message that the object (presumably getFeatures()) is not defined. It is understandable that when your application was designed, it was always assumed that a feature would have a geometry, but as you will see, your application is potentially much more than that. I am explaining why below. Instead, computeBounds() should ignore such features and continue calculating on the rest of the set. That way, bounds will be set on all included features which DO have associated geometries. Please use labels and text to provide additional information. Please improve computeBounds() and keep it from crashing in IE when a geometry is not associated with a feature. The reason for wanting to include placemarks without points is that a large set of data is being imported from another source unrelated to Google Earth. If this data does not include an address, you should still be able to write a placemark into a kml, just excluding a point. Why? Because the end application would be inferior if we had to associate points of coordinates (0,0) with every placemark whose address could not be found. To include such points would mean that computeBounds() would necessarily operate on a bunch of unfound addresses, and therefore, the bounding box would be defined to include these, making it unnecessarily too large of a box. Why have placemarks in the KML in the first place if the point data is unavailable? Because GE can be more than just a point finder. In my case, I use the placemark data as a database as well. I make liberal use of <ExtendedData> to store information on the placemark. I then use the placemark to access the <ExtendedData> in order to show information unrelated to point coordinates, such as last name, political party, phone number, and many other items. A navigation window is used in connection with the plug-in window to be able to click on placemarks and navigate to them. In addition to just using placemarks for plain-old navigation in the plug-in window, these placemarks are used to grab the ExtendedData and display it in other places outside the plug-in window. Further, the navigation tree is created based on the list of placemarks. To exclude placemarks from the kml file just because lat/lon is (0,0) would mean the navigation tree would be missing important data which could otherwise be tapped and used. It would be nice to be able to use it exactly this way and to just have computeBounds() ignore features with no geometry. Of course, it cannot navigate in the plug-in window to a placemark without a point, but I have that handled. That part was easy. In sum, there is no reason to crash computeBounds() just because a feature does not have a geometry. To change this behavior should be very easy to do, requiring perhaps the addition of any a few lines of code to check to see if getGeometry() is defined. To do so would not adversely affect any other application that relies on computeBounds(), and therefore, the function would be improved, and further, this would allow the GE plug-in to be more than just a way to map points. Its ExtendedData, by itself, can be used as a robust database for use of the fields in display manipulation. Since computeBounds() currently crashes, a catch-22 is created. I can either (a) eliminate placemarks and the robust set of data that is associated with them, or (2) keep the placemarks in and have computeBounds() include coordinates of (0,0) every time a bounds is computed. Here is the website link to see this behavior in action. Please note, it works fine in FF and Chrome. http://www.sovereignstates.net/StateLegislators/VSLegislators.htm Thanks, and if you elect to make this improvement, could you please notify me by e-mail?

What steps will reproduce the problem? 1. In IE only, try to perform computeBounds() in a data set where any feature fails to contain a geometry associated with it. What is the expected output? What do you see instead? I can't say something different should be "expected," as it is a novel issue (probably novel), but if a feature (e.g. placemark) does not have a geometry (e.g. point) associated with it, computeBounds() will crash with an error message that the object (presumably getFeatures()) is not defined. It is understandable that when your application was designed, it was always assumed that a feature would have a geometry, but as you will see, your application is potentially much more than that. I am explaining why below. Instead, computeBounds() should ignore such features and continue calculating on the rest of the set. That way, bounds will be set on all included features which DO have associated geometries. Please use labels and text to provide additional information. Please improve computeBounds() and keep it from crashing in IE when a geometry is not associated with a feature. The reason for wanting to include placemarks without points is that a large set of data is being imported from another source unrelated to Google Earth. If this data does not include an address, you should still be able to write a placemark into a kml, just excluding a point. Why? Because the end application would be inferior if we had to associate points of coordinates (0,0) with every placemark whose address could not be found. To include such points would mean that computeBounds() would necessarily operate on a bunch of unfound addresses, and therefore, the bounding box would be defined to include these, making it unnecessarily too large of a box. Why have placemarks in the KML in the first place if the point data is unavailable? Because GE can be more than just a point finder. In my case, I use the placemark data as a database as well. I make liberal use of <ExtendedData> to store information on the placemark. I then use the placemark to access the <ExtendedData> in order to show information unrelated to point coordinates, such as last name, political party, phone number, and many other items. A navigation window is used in connection with the plug-in window to be able to click on placemarks and navigate to them. In addition to just using placemarks for plain-old navigation in the plug-in window, these placemarks are used to grab the ExtendedData and display it in other places outside the plug-in window. Further, the navigation tree is created based on the list of placemarks. To exclude placemarks from the kml file just because lat/lon is (0,0) would mean the navigation tree would be missing important data which could otherwise be tapped and used. It would be nice to be able to use it exactly this way and to just have computeBounds() ignore features with no geometry. Of course, it cannot navigate in the plug-in window to a placemark without a point, but I have that handled. That part was easy. In sum, there is no reason to crash computeBounds() just because a feature does not have a geometry. To change this behavior should be very easy to do, requiring perhaps the addition of any a few lines of code to check to see if getGeometry() is defined. To do so would not adversely affect any other application that relies on computeBounds(), and therefore, the function would be improved, and further, this would allow the GE plug-in to be more than just a way to map points. Its ExtendedData, by itself, can be used as a robust database for use of the fields in display manipulation. Since computeBounds() currently crashes, a catch-22 is created. I can either (a) eliminate placemarks and the robust set of data that is associated with them, or (2) keep the placemarks in and have computeBounds() include coordinates of (0,0) every time a bounds is computed. Here is the website link to see this behavior in action. Please note, it works fine in FF and Chrome. http://www.sovereignstates.net/StateLegislators/VSLegislators.htm Thanks, and if you elect to make this improvement, could you please notify me by e-mail?

Today

Last 30 days

Earlier this year