Hi all, I've just discovered an instance in OL where floating-point maths is causing it to produce wrong results. Or at least I think that is the problem. Am keen for the perspective of other users.
I have got a small polygon (about 4m x 16m land parcel) that I want OL to show on the map and put a popup on. This polygon is defined in WGS84 as follows: 146.499146 -35.964346 146.499147 -35.964234 146.499179 -35.964234 146.499179 -35.964346 146.499146 -35.964346 When it gets added to my map, it gets converted into spherical mercator metres for display on Google Maps imagery: 16308210.33436940 -4295716.54499556 16308210.44568890 -4295701.14094059 16308214.00791260 -4295701.14094059 16308214.00791260 -4295716.54499556 16308210.33436940 -4295716.54499556 I then calculate a centroid for the polygon, which uses the getCentroid method in LinearRing.js. This ends up putting the centroid at: 16306764.80622490 -4295327.62865597 (which is clearly outside the polygon) If I apply the formula used in the getCentroid method using Excel (which is explained here at http://en.wikipedia.org/wiki/Centroid#Centroid_of_polygon), I get the centroid computed as: 16308173.84173270 -4295698.77909395 (which is closer, but still not in the polygon even though it should be). Now clearly neither of these are in the right place. It is a result of the centroid formula producing huge numbers when using spherical mercator coordinates (which themselves are huge). I'm wondering if there is a better approach to computing the centroid that can avoid these issues? Any ideas or implementations? Thanks, Steve -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/getCentroid-method-influenced-by-floating-point-math-tp6346365p6346365.html Sent from the OpenLayers Users mailing list archive at Nabble.com. _______________________________________________ Users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-users
