earthoutreach / earth-api-utility-library

Automatically exported from code.google.com/p/earth-api-utility-library
0 stars 0 forks source link

Keep computeBounds() from crashing in IE #20

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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?

Original issue reported on code.google.com by jmat...@gmail.com on 8 Nov 2009 at 11:58

GoogleCodeExporter commented 8 years ago

Original comment by api.roman.public@gmail.com on 12 Nov 2009 at 7:39