Claculate area of square from latitude and longitude

[Hrvoje]

Hi there,

I made map with four markers, dragable and i getPosition for these
markers. Now i have lat i lon for these four markers.

Question is:

Is it possible to calculate the area of irregular square from lat &
lon? i know calculate area from x & y but lat & lon...

any suggestions?
Maybe these ???
fromLatLngToPoint(latLng:LatLng, point?:Point)

I want something like:
http://www.daftlogic.com/projects-google-maps-area-calculator-tool.htm

but i don t understand these code.

Thanks anyway

[geoco...@gmail.com]

On Aug 14, 4:26 am, Hrvoje <hrvojelovr...@gmail.com> wrote:
> Hi there,
>
> I made map with four markers, dragable and i getPosition for these
> markers. Now i have lat i lon for these four markers.
>
> Question is:
>
> Is it possible to calculate the area of irregular square from lat &
> lon? i know calculate area from x & y but lat & lon...
>
> any suggestions?

Investigate Spherical Trigonometry.

> Maybe these ???
> fromLatLngToPoint(latLng:LatLng, point?:Point)
>
> I want something like:http://www.daftlogic.com/projects-google-maps-area-calculator-tool.htm

That example uses v2, this group is for v3. Which are you planning on
using?

Mike Willims has an implementation of an area calculation in his v2
epoly extension (but it doesn't fully account for the spherical
earth).

-- Larry

[geoco...@gmail.com]

On Aug 14, 6:05 pm, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> On Aug 14, 4:26 am, Hrvoje <hrvojelovr...@gmail.com> wrote:
>
> > Hi there,
>
> > I made map with four markers, dragable and i getPosition for these
> > markers. Now i have lat i lon for these four markers.
>
> > Question is:
>
> > Is it possible to calculate the area of irregular square from lat &
> > lon? i know calculate area from x & y but lat & lon...
>
> > any suggestions?
>
> Investigate Spherical Trigonometry.

A couple of links I have come up with (don't know if they work):
http://forum.worldwindcentral.com/showthread.php?t=20724
http://mathworld.wolfram.com/SphericalPolygon.html

and this search:
http://www.google.com/search?client=gmail&q=spherical%20geometry%20area%20of%20polygon

-- Larry

[Hrvoje]

Mike Willims has an implementation of an area calculation in his v2
epoly extension (but it doesn't fully account for the spherical
earth).

-- Larry

I doesn`t care about spherical earth beacuse i need that tool for
measuring roof surface, in other words, small part of earth.

what is your suggestion, V2 or V3 or not important?

Thanks.

[geoco...@gmail.com]

That determination you will have to make yourself.
Is it a production site? The version control on v3 leaves something to
be desired, and v3 doesn't "officially support" IE6.

Also, the tools for measuring area of polygons in v2 are available, in
v3, they don't seem to be.

-- Larry

>
> Thanks.

[geoco...@gmail.com]

On Aug 14, 6:17 pm, "geocode...@gmail.com" <geocode...@gmail.com>

wrote:
> On Aug 14, 6:05 pm, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:
>
> > On Aug 14, 4:26 am, Hrvoje <hrvojelovr...@gmail.com> wrote:
>
> > > Hi there,
>
> > > I made map with four markers, dragable and i getPosition for these
> > > markers. Now i have lat i lon for these four markers.
>
> > > Question is:
>
> > > Is it possible to calculate the area of irregular square from lat &
> > > lon? i know calculate area from x & y but lat & lon...
>
> > > any suggestions?
>
> > Investigate Spherical Trigonometry.
>

> A couple of links I have come up with (don't know if they work):http://forum.worldwindcentral.com/showthread.php?t=20724http://mathworld.wolfram.com/SphericalPolygon.html
>
> and this search:http://www.google.com/search?client=gmail&q=spherical%20geometry%20ar...

My test page playing with the 2 algorithms:
http://www.geocodezip.com/v3_polygon_example_area.html
(no guarantees, they might both be wrong...)

[Ben Appleton]

Hi Larry,

On Mon, Aug 16, 2010 at 2:58 AM, geoco...@gmail.com
<geoco...@gmail.com> wrote:
> On Aug 15, 6:38 am, Hrvoje <hrvojelovr...@gmail.com> wrote:
>> Mike Willims has an implementation of an area calculation in his v2
>> epoly extension (but it doesn't fully account for the spherical
>> earth).
>>
>>   -- Larry
>>
>> I doesn`t care about spherical earth beacuse i need that tool for
>> measuring roof surface, in other words, small part of earth.
>>
>> what is your suggestion, V2 or V3 or not important?
>
> That determination you will have to make yourself.
> Is it a production site? The version control on v3 leaves something to
> be desired, and v3 doesn't "officially support" IE6.

Can you elaborate on "The version control on v3 leaves something to be
desired" - what more do you desire?

The versioning system is documented here:
http://code.google.com/apis/maps/documentation/javascript/basics.html#Versioning.
If the docs or release process are unclear we'd like to improve that.

Thanks!
Ben

> Also, the tools for measuring area of polygons in v2 are available, in
> v3, they don't seem to be.
>
>  -- Larry
>
>>
>> Thanks.
>

> --
> You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
> To post to this group, send email to google-map...@googlegroups.com.
> To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
>
>

[William]

On Aug 16, 8:42 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> My test page playing with the 2 algorithms:http://www.geocodezip.com/v3_polygon_example_area.html
> (no guarantees, they might both be wrong...)
>

thanks for implementing these very useful functions.

I had a couple of questions:

1. it looks like the polygons assume auto-closure, in other words, you
shouldn't have the final vertex equal to the first?

for example this code calculates the next vertex, which will be
vertex[0] for the final vertex.

k = ( j + 1 ) % paths.getLength();

2. the function GetPointAtDistance() assumes the lat,lng are a
cartesian coordinate system when calculating a linear interpolation on
lat and lng:

var m = (metres-olddist)/(dist-olddist);
return new google.maps.LatLng(
p1.lat() + (p2.lat()-p1.lat())*m,
p1.lng() + (p2.lng()-p1.lng())*m);

to use some functions from the RouteBoxer extension, I think it would
be more accurate to do a bearing distance calculation from the vertex:

var bearing = p1.rhumbBearingTo(p2);
return p1.rhumbDestinationPoint(bearing, metres-olddist);

...

[geoco...@gmail.com]

On Aug 15, 5:33 pm, Ben Appleton <apple...@google.com> wrote:
> Hi Larry,
>

> On Mon, Aug 16, 2010 at 2:58 AM, geocode...@gmail.com
> <geocode...@gmail.com> wrote:
> > On Aug 15, 6:38 am, Hrvoje <hrvojelovr...@gmail.com> wrote:
> >> Mike Willims has an implementation of an area calculation in his v2
> >> epoly extension (but it doesn't fully account for the spherical
> >> earth).
>
> >>   -- Larry
>
> >> I doesn`t care about spherical earth beacuse i need that tool for
> >> measuring roof surface, in other words, small part of earth.
>
> >> what is your suggestion, V2 or V3 or not important?
>
> > That determination you will have to make yourself.
> > Is it a production site? The version control on v3 leaves something to
> > be desired, and v3 doesn't "officially support" IE6.
>
> Can you elaborate on "The version control on v3 leaves something to be
> desired" - what more do you desire?

In v2 there is the concept of stable, release and development
versions. Any released version can be referenced.

In v3 the only choices are the equivalent of the "stable" release.
Most people are forced to use the equivalent of the "development"
version (.x) which was never suitable for production sites. Things
tend to break unexpectedly in the development version.



>
> The versioning system is documented here:http://code.google.com/apis/maps/documentation/javascript/basics.html....

>  If the docs or release process are unclear we'd like to improve that.

I think it is clear. I just don't think the current process is
acceptable for production sites. What is the "official"
recommendation for production sites? Use v3.0?

-- Larry

[Ben Appleton]

How are you forced to use the development version?

>> The versioning system is documented here:http://code.google.com/apis/maps/documentation/javascript/basics.html....
>>  If the docs or release process are unclear we'd like to improve that.
>
> I think it is clear.  I just don't think the current process is
> acceptable for production sites.  What is the "official"
> recommendation for production sites?  Use v3.0?

If you're a production site and risk-averse:
Use the frozen version (currently v3.0). This ensures that the API JS
will not change under your site.
Test your site against the release version (currently v3.1). Report
regressions with respect to the frozen version and we'll attempt to
fix them. This will become the next frozen version.

If you're a production site but need more recent features and fixes,
use the release version (currently v3.1). We only patch bugs in this
version, so it should be reasonably stable.

If you want to try out the latest features and fixes, enjoy living on
the edge, or want to be involved in the direction of the API, test the
latest version (currently v3.2).

[geoco...@gmail.com]

On Aug 15, 9:12 pm, William <william.g...@gmail.com> wrote:
> On Aug 16, 8:42 am, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:> My test page playing with the 2 algorithms:http://www.geocodezip.com/v3_polygon_example_area.html
> > (no guarantees, they might both be wrong...)
>
> thanks for implementing these very useful functions.
>
> I had a couple of questions:
>
> 1. it looks like the polygons assume auto-closure, in other words, you
> shouldn't have the final vertex equal to the first?
>
> for example this code calculates the next vertex, which will be
> vertex[0] for the final vertex.
>
> k = ( j + 1 ) % paths.getLength();

It is possible that should be changed. I haven't spent a lot of time
testing that function. I ported it from the site referenced.

>
> 2. the function GetPointAtDistance() assumes the lat,lng are a
> cartesian coordinate system when calculating a linear interpolation on
> lat and lng:
>
> var m = (metres-olddist)/(dist-olddist);
> return new google.maps.LatLng(
>   p1.lat() + (p2.lat()-p1.lat())*m,
>   p1.lng() + (p2.lng()-p1.lng())*m);
>
> to use some functions from the RouteBoxer extension, I think it would
> be more accurate to do a bearing distance calculation from the vertex:
>
> var bearing = p1.rhumbBearingTo(p2);
> return p1.rhumbDestinationPoint(bearing, metres-olddist);
>
> ...

The GetPointAtDistance() is a straight port of Mike Williams' v2
function. It is possible that it could be made more accurate. The
main purpose I have used that function for is for putting kilometer
markers on a route (on the polyline):
http://www.geocodezip.com/v3_polyline_example_kmmarkers_0.html

-- Larry

[geoco...@gmail.com]

On Aug 15, 9:52 pm, Ben Appleton <apple...@google.com> wrote:
> On Mon, Aug 16, 2010 at 2:18 PM, geocode...@gmail.com

Maybe the document needs to be more clear then. It seems to me that
v=3 is the recommended version.

Most of the examples include this:
<script type="text/javascript" src="http://maps.google.com/maps/api/js?
sensor=false"></script>

>
> >> The versioning system is documented here:http://code.google.com/apis/maps/documentation/javascript/basics.html....
> >>  If the docs or release process are unclear we'd like to improve that.
>
> > I think it is clear.  I just don't think the current process is
> > acceptable for production sites.  What is the "official"
> > recommendation for production sites?  Use v3.0?
>
> If you're a production site and risk-averse:
> Use the frozen version (currently v3.0).  This ensures that the API JS
> will not change under your site.
> Test your site against the release version (currently v3.1).  Report
> regressions with respect to the frozen version and we'll attempt to
> fix them.  This will become the next frozen version.
>
> If you're a production site but need more recent features and fixes,
> use the release version (currently v3.1).  We only patch bugs in this
> version, so it should be reasonably stable.
>
> If you want to try out the latest features and fixes, enjoy living on
> the edge, or want to be involved in the direction of the API, test the
> latest version (currently v3.2).

I think that if the above is true, you need to make it clearer. It
certainly isn't clear to me that v3.1 is the release version and that
v3.2 is available.

[William]

On Aug 16, 3:17 pm, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> The GetPointAtDistance() is a straight port of Mike Williams' v2
> function.  It is possible that it could be made more accurate. The
> main purpose I have used that function for is for putting kilometer
> markers on a route (on the polyline):http://www.geocodezip.com/v3_polyline_example_kmmarkers_0.html
>

Also it was used in the demo to place the corner points on the
squares, and I was curious about the area discrepancy for the 1 meter
square using the spherical method because the spherical area should
always be larger?

I think the "straight line" segments of a polygon/polyline are great
circle arcs if "geodesic" is set, otherwise they are rhumb lines since
they will be displayed as straight lines on a mercator projection.

...

[Ben Appleton]

Fair enough. We're "dogfooding" the development version here, but
perhaps to be clearer we could pick a version.

>> >> The versioning system is documented here:http://code.google.com/apis/maps/documentation/javascript/basics.html....
>> >>  If the docs or release process are unclear we'd like to improve that.
>>
>> > I think it is clear.  I just don't think the current process is
>> > acceptable for production sites.  What is the "official"
>> > recommendation for production sites?  Use v3.0?
>>
>> If you're a production site and risk-averse:
>> Use the frozen version (currently v3.0).  This ensures that the API JS
>> will not change under your site.
>> Test your site against the release version (currently v3.1).  Report
>> regressions with respect to the frozen version and we'll attempt to
>> fix them.  This will become the next frozen version.
>>
>> If you're a production site but need more recent features and fixes,
>> use the release version (currently v3.1).  We only patch bugs in this
>> version, so it should be reasonably stable.
>>
>> If you want to try out the latest features and fixes, enjoy living on
>> the edge, or want to be involved in the direction of the API, test the
>> latest version (currently v3.2).
>
>
> I think that if the above is true, you need to make it clearer.  It
> certainly isn't clear to me that v3.1 is the release version and that
> v3.2 is available.

With the release of v3.2 last week we're fixing the docs now. Until
that point it was hard to explain our intent that there be 3 major
versions live at any time (frozen, release, and latest/development).
Hopefully v3's versioning becomes clearer real soon.

Note that, compared to v2, in v3 we've intentionally removed the
aliases such as v=2.s, v=2 and v=2.x. We're now encouraging everyone
to pick a numbered (fixed) version, since many sites were surprised
that v=2 updated approximately weekly. By picking a numbered version,
sites control their update cycle rather than being caught by surprise.
Of course JS versions do not live forever, so every 3 months when we
freeze the release version we'll delete the old frozen version and
auto-upgrade any sites still using it.

- Ben

[geoco...@gmail.com]

On Aug 15, 11:13 pm, William <william.g...@gmail.com> wrote:
> On Aug 16, 3:17 pm, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:> The GetPointAtDistance() is a straight port of Mike Williams' v2
> > function.  It is possible that it could be made more accurate. The
> > main purpose I have used that function for is for putting kilometer
> > markers on a route (on the polyline):http://www.geocodezip.com/v3_polyline_example_kmmarkers_0.html
>
> Also it was used in the demo to place the corner points on the
> squares, and I was curious about the area discrepancy for the 1 meter
> square using the spherical method because the spherical area should
> always be larger?

That was bothering me as well. When I have a chance, I will see if
your suggestion fixes that.

-- Larry

[geoco...@gmail.com]

On Aug 16, 1:04 am, Ben Appleton <apple...@google.com> wrote:
> On Mon, Aug 16, 2010 at 3:24 PM, geocode...@gmail.com

You should be able to programatically "hard code" the current released
version in your examples (server-side). Then people won't be suprised
when the version changes underneath them.

You could also make it clearer that you get the development version if
you don't specify a version.

Could you please add information to the changelog about what version
each release is? I have asked this before. There is no way to relate
the change log to releases without searching for the release notices
and then looking at the date (and the date of the release notices is
not but so accurate...)

-- Larry

>
> - Ben
>
>
>
> >   -- Larry
>
> >> >> Thanks!
> >> >> Ben
>
> >> >> > Also, the tools for measuring area of polygons in v2 are available, in
> >> >> > v3, they don't seem to be.
>
> >> >> >  -- Larry
>
> >> >> >> Thanks.
>
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
> >> >> > To post to this group, send email to google-map...@googlegroups.com.
> >> >> > To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
> >> >> > For more options, visit this group athttp://groups.google.com/group/google-maps-js-api-v3?hl=en.
>
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
> >> > To post to this group, send email to google-map...@googlegroups.com.
> >> > To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
> >> > For more options, visit this group athttp://groups.google.com/group/google-maps-js-api-v3?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
> > To post to this group, send email to google-map...@googlegroups.com.
> > To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/google-maps-js-api-v3?hl=en.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[geoco...@gmail.com]

On Aug 15, 9:12 pm, William <william.g...@gmail.com> wrote:

> On Aug 16, 8:42 am, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:> My test page playing with the 2 algorithms:http://www.geocodezip.com/v3_polygon_example_area.html
> > (no guarantees, they might both be wrong...)
>
> thanks for implementing these very useful functions.
>
> I had a couple of questions:
>
> 1. it looks like the polygons assume auto-closure, in other words, you
> shouldn't have the final vertex equal to the first?
>
> for example this code calculates the next vertex, which will be
> vertex[0] for the final vertex.
>
> k = ( j + 1 ) % paths.getLength();

But later in the algorithm, it only actually does something if lam1 !=
lam2, and if two consecutive points are the same lam1 should equal
lam2, so that shouldn't matter.

-- Larry

[geoco...@gmail.com]

On Aug 16, 5:53 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> On Aug 15, 11:13 pm, William <william.g...@gmail.com> wrote:
>
> > On Aug 16, 3:17 pm, "geocode...@gmail.com" <geocode...@gmail.com>
> > wrote:> The GetPointAtDistance() is a straight port of Mike Williams' v2
> > > function.  It is possible that it could be made more accurate. The
> > > main purpose I have used that function for is for putting kilometer
> > > markers on a route (on the polyline):http://www.geocodezip.com/v3_polyline_example_kmmarkers_0.html
>
> > Also it was used in the demo to place the corner points on the
> > squares, and I was curious about the area discrepancy for the 1 meter
> > square using the spherical method because the spherical area should
> > always be larger?
>
> That was bothering me as well.  When I have a chance, I will see if
> your suggestion fixes that.

I changed the page to start with shorter lines, then cut them down to
the correct distance. That seemed to make the results come out
differently, so it looks like you were correct to suspect the
GetPointAtDistance routine. I'll remove that effect from the example
when I get a chance.

Original:
1.000 meter square
Area() 1.000005 m²
SphericalArea() 0.998147 m²
10.000 meter square
Area() 100.000540 m²
SphericalArea() 100.006183 m²
100.000 meter square
Area() 10000.099370 m²
SphericalArea() 10000.103782 m²
1000.005 meter square
Area() 1000055.289763 m²
SphericalArea() 1000055.297965 m²
1000.005 meter square
Area() 1.000055 km²
SphericalArea() 1.000055 km²

updated:
1.000000 meter square
Area() 1.000000 m²
SphericalArea() 0.998147 m²
10.000001 meter square
Area() 100.000059 m²
SphericalArea() 100.006183 m²
100.000023 meter square
Area() 10000.052694 m²
SphericalArea() 10000.048016 m²
1000.000 meter square
Area() 1000050.843834 m²
SphericalArea() 1000050.847346 m²
1000.000450 meter square
Area() 1.000051 km²
SphericalArea() 1.000051 km²

  -- Larry


>
> > I think the "straight line" segments of a polygon/polyline are great
> > circle arcs if "geodesic" is set, otherwise they are rhumb lines since
> > they will be displayed as straight lines on a mercator projection.
>

> > ...- Hide quoted text -

[John M Phillips]

An other option is to work in UTM coordinates. Each UTM zone is a
cartesian grid in meters. There are a set of projection
transformations available from Plan.4. I am using a server-side
solution using perl plan 4 moduels. But there is also a javascript
library.

Links:
Plan 4 http://trac.osgeo.org/proj/
Plan 4 javascript http://www.proj4js.org/
Plan 4 perl http://search.cpan.org/~sderle/Geo-Proj4-0.11/Proj4.pm
My project http://localhost/cgi-bin/AtcInspectionForm.cgi

[geoco...@gmail.com]

On Aug 16, 8:36 am, "geocode...@gmail.com" <geocode...@gmail.com>

wrote:
> On Aug 16, 5:53 am, "geocode...@gmail.com" <geocode...@gmail.com>
> wrote:
>
> > On Aug 15, 11:13 pm, William <william.g...@gmail.com> wrote:
>
> > > On Aug 16, 3:17 pm, "geocode...@gmail.com" <geocode...@gmail.com>
> > > wrote:> The GetPointAtDistance() is a straight port of Mike Williams' v2
> > > > function.  It is possible that it could be made more accurate. The
> > > > main purpose I have used that function for is for putting kilometer
> > > > markers on a route (on the polyline):http://www.geocodezip.com/v3_polyline_example_kmmarkers_0.html
>
> > > Also it was used in the demo to place the corner points on the
> > > squares, and I was curious about the area discrepancy for the 1 meter
> > > square using the spherical method because the spherical area should
> > > always be larger?
>
> > That was bothering me as well.  When I have a chance, I will see if
> > your suggestion fixes that.
>
> I changed the page to start with shorter lines, then cut them down to
> the correct distance.  That seemed to make the results come out
> differently, so it looks like you were correct to suspect the
> GetPointAtDistance routine.  I'll remove that effect from the example
> when I get a chance.

Another gotcha. My squares aren't really squares. One of the
"uncalculated sides" is longer than the others (the southward edge of
the squares), the difference gets bigger the bigger the "square" is.
I'll need to compensate or move the squares to the equator.

-- Larry

> > - Show quoted text -- Hide quoted text -

[geoco...@gmail.com]

On Aug 16, 8:10 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> On Aug 15, 9:12 pm, William <william.g...@gmail.com> wrote:
>
> > On Aug 16, 8:42 am, "geocode...@gmail.com" <geocode...@gmail.com>
> > wrote:> My test page playing with the 2 algorithms:http://www.geocodezip.com/v3_polygon_example_area.html
> > > (no guarantees, they might both be wrong...)
>
> > thanks for implementing these very useful functions.
>
> > I had a couple of questions:
>
> > 1. it looks like the polygons assume auto-closure, in other words, you
> > shouldn't have the final vertex equal to the first?
>
> > for example this code calculates the next vertex, which will be
> > vertex[0] for the final vertex.
>
> > k = ( j + 1 ) % paths.getLength();
>
> But later in the algorithm, it only actually does something if lam1 !=
> lam2, and if two consecutive points are the same lam1 should equal
> lam2, so that shouldn't matter.

But, when I "fixed" my squares, that test started to give a false
positive. lamX is calculated solely from the longitude, if 2
sequential non-identical points have the same longitude, that section
of code will not be executed, which gives an incorrect result. I'll
have to see if I can find a better implementation somewhere, I'm not
sure I trust this one.

Does anyone know where there is an accurate implementation of an area
calculation for spherical polygons?

-- Larry

>
>   -- Larry
>
>
>
>
>
> > 2. the function GetPointAtDistance() assumes the lat,lng are a
> > cartesian coordinate system when calculating a linear interpolation on
> > lat and lng:
>
> > var m = (metres-olddist)/(dist-olddist);
> > return new google.maps.LatLng(
> >   p1.lat() + (p2.lat()-p1.lat())*m,
> >   p1.lng() + (p2.lng()-p1.lng())*m);
>
> > to use some functions from the RouteBoxer extension, I think it would
> > be more accurate to do a bearing distance calculation from the vertex:
>
> > var bearing = p1.rhumbBearingTo(p2);
> > return p1.rhumbDestinationPoint(bearing, metres-olddist);
>

[William]

On Aug 17, 4:33 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

>
> Does anyone know where there is an accurate implementation of an area
> calculation for spherical polygons?
>

that code is originally sourced from:

* ANSI C code from the article
* "Computing the Area of a Spherical Polygon"
* by Robert D. Miller
* in "Graphics Gems IV", Academic Press, 1994

In Graphics Gems V, the following article made one correction to the
code, relating to polygons crossing the 0 meridian:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.9608&rep=rep1&type=pdf

that change was implemented in: sphere_polygon_area_3d()
C Source Code:
http://people.sc.fsu.edu/~jburkardt/cpp_src/geometry/geometry.C

...

[William]

On Aug 17, 4:33 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

>  lamX is calculated solely from the longitude, if 2
> sequential non-identical points have the same longitude, that section
> of code will not be executed, which gives an incorrect result.
>

I checked the original book and it's correct because the area is being
calculated as a signed sum of spherical triangles. These triangles
have a vertex at the pole and the difference in longitude between
successive vertices gives the polar angle. When this polar angle is
zero there's no area to calculate, so the section of code is skipped.

...

[geoco...@gmail.com]

William,
I tried using the rhumbDestinationPoint function from the
RouteBoxer to calculate my "test" squares. It seems to always return
a point that is closer to the original point than expected (where
GetPointAtDistance seemed to be giving me a point slightly further
away, at least when the starting line was a lot longer than the
desired distance).
For example a 1.0 meter distance gives me a point 0.999994 meters
away (starting from (32.7384,-117.148532).

Is there some approximation or dependence on location in that
calculation that might be causing that?

Although, thinking about it, I might not want the rhumb line after
all, I probably do want a geodesic line, along the great circle.

Thank you,
Larry

>
> ...

[William]

On Aug 18, 4:29 pm, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

> Although, thinking about it, I might not want the rhumb line after
> all, I probably do want a geodesic line, along the great circle.
>

yeah I think you are right, because the distance measurement function
using the haversine formula which is a great circle arc, so you can
use the "Destination Point given Distance and Start Point" formula
from:
http://www.movable-type.co.uk/scripts/latlong.html

...