Measuring time

[worker201]

Do you use statute miles or nautical miles for a coastline?
Guess that's up to the client.

I honestly thought this would take longer. The coastline file isn't ready for testing yet! (have to remove rivers and other unwanted junk, like piers)

But man, thanks a ton!
Now that I am beginning to see how this works, I may be able to write a whole slew of other programs that are useful for dealing with multisegment xy files.

[Void Main]

Yes I imagine it would. You can figure either statute, nautical, or kilometers by changing one number in the code. You can find the numbers needed for each in the comments of ZiaTioN's code. We are both using the number for statute miles in our programs.

[ZiaTioN]

Ok I figured out the differences in our code. First was I was not subtracting the latitude degrees from 90 before converting to radians (had to read the Math::Trig module docs to find this out) and I was sending the first pair as the first pair and the second pair as the second pair when I should have been sending the second pair as the first pair and the first pair as the second pair.

Void did this when he set @p2 = @p1 and then loaded the second pair as @p1 and sent @p1 first and @p2 second but was really sending the first pair second and the second pair first. LOL.. This difference probably came about because I used a lookahead method and Void used a look behind method. Plus I changed the trig math a bit but my old trig I think would work with the new data setup too but I got this from the Math::Trig module and it is more compact.

Anyhow:

Code: Select all

#!/usr/bin/perl -w

use strict;

$/ = '>';
my $total = 0;
while(<DATA>) {
   chomp();
   next unless($_);
   my $subtotal = 0;
   my @list = split(/\n/);
   for(0..$#list) {
      next unless($list[$_]);
      if ($list[$_+1]) {
         my ($lon0, $lat0) = split(/\s+/, $list[$_]);
         my ($lon1, $lat1) = split(/\s+/, $list[$_+1]);
         $subtotal += calculate($lon1, (90-$lat1), $lon0, (90-$lat0));
      }
   }
   printf("Subtotal: %.4f miles\n",$subtotal) if $subtotal;
   $total += $subtotal;
}
printf("Total: %.4f miles\n", $total);

sub calculate {
   my ($lon0, $lat0, $lon1, $lat1) = @_;
   my $pi = atan2(1, 1) * 4;

   $lon0 *= ($pi/180);
   $lat0 *= ($pi/180);
   $lon1 *= ($pi/180);
   $lat1 *= ($pi/180);

   $lat0 = $pi/2 - $lat0;
   $lat1 = $pi/2 - $lat1;

   # Value for $r = 3963.1 statute miles -- 3443.9 nautical miles -- 6378 km
   my $r = 3963.1; # statute miles, for feet multiply this by 5,280
   my $x = cos($lat0) * cos($lat1) * cos($lon0 - $lon1) + sin($lat0) * sin($lat1);

   return (atan2(sqrt(1 - $x**2), $x) * $r);
}


Two ways to do the same thing and with perl, probably a billion more...

[Void Main]

I can't imagine it matters which pair goes first or second because you are simply calculating the distance between two points. However, I am pretty sure it would matter if the latitudes and longitudes were switched (360 degress of longitude where there are only 180 degrees of latitude). You are right, there are probably a million other ways to do it and I am pretty sure my way wouldn't even be found in the top 100 best ways. :)

[ZiaTioN]

Yeah I just checked the ording on both our apps and it does not matter, I guess it was just the subtracting the latitude from 90 before conveting to radians and then subtracting the radian value from pi over 2 (pi/2). These two additions were the difference.

[JoeDude]

Worker201...I thought you were the mapping expert!!!

As far as long lat maps go, they are almost always in nauticle miles, however, land based maps which are long lat can be standard miles as well.

All governmental maps are MGRS. Hence they must be marked in Metrics.

Most civilian atlas' and driving maps are marked in standard miles.

The important thing is, what does your employer want it to be in? As you spent so much time in the Ocean, I would assume it would be nauticle miles. Assumption could screw the pooch though, best be safe and ask.

[Void Main]

Actually I used to do a little mapping for the government (US). :) I worked in a weather shop and used to do all kinds of crazy stuff with historical weather data and with DTED data. Things ranging from mapping ash content in the atmosphere over time after volcanic eruptions to deciding if certain locations are good places to be the home base for the B2 bomber based on icing conditions as well as other historical weather conditions at those locations. But that was 10-15 years ago. Alright, now I have to kill you. :)

[Void Main]

Ok, I just had to know where it was we were dealing with here. I wrote a Google Maps program to read your data and display it:

http://voidmain.is-a-geek.net/maps/

[JoeDude]

HAHAHA

And, I thought it would be somewhere in the Indian Ocean...at least it's near south padre!!!!

GAWD I MISS TEXAS!!!

[worker201]

The complete file, which is like 24,000 points, defines the complete medium resolution of the Galveston Bay shoreline, between Houston and Galveston, Texas. As you might know, this is part of hurricane alley, so mapping done here is pretty important. However, the current project is for the Texas Parks and Wildlife Dept (TPWD). They want a map of shrimp habitat in the bay. For biological planning purposes, they want to know the area, the volume, and the perimeter in kilometers. Making a map of habitats is easy. Computing the area and volume from a contour map is easy (simple function of my mapping program. Measuring the perimeter is not that easy.

According to the Llama Book, Perl's motto is "There's more than one way to do it". Thanks, guys, for illustrating that with clarity.

Hopefully, I'll be ready to use this by next week.

[Calum]

First was I was not subtracting the latitude degrees from 90 before converting to radians

i love this sort of thing! you can get all your arithmetic right and triplecheck everything, but something like this will totally flummox somebody, until they realise it's a "commonsense" thing if you know what i mean. one thing my introduction to programming course taught me was that programming is mainly about thinking laterally!

perhaps that's not the whole story, i am nowhere like at the stage to say i can write programs yet.

[Void Main]

Not only laterally but sometimes longitudinally as well. :)

[ZiaTioN]

First was I was not subtracting the latitude degrees from 90 before converting to radians

i love this sort of thing! you can get all your arithmetic right and triplecheck everything, but something like this will totally flummox somebody, until they realise it's a "commonsense" thing if you know what i mean. one thing my introduction to programming course taught me was that programming is mainly about thinking laterally!

perhaps that's not the whole story, i am nowhere like at the stage to say i can write programs yet.

Yeah it would have been common sense if I was fluent in calculating long and lat coordinates, which I am not. I can write code, in numerous languages, until the cows come home (fairly well I might add too) but that does not mean that long and lat calculations should be common sense to me, if you know what I mean. "Common sense" can sometimes be relative. The way I setup my program logic and functionality was common sense to me but only because I am fairly fluent in doing so. This may not be the case for others.

[worker201]

There are as many ways to express geospatial location as there are ways to write a 'hello world' program. I have personally gotten used to positive latitude north and positive longitude east. It could just as easily be done the other way around. Many other mappers use 360 degrees of longitude, so there's never any negatives. Oil companies still use UTM zones, which measure feet from known positions. It just depends on habits and whatever numbers make sense to your application. So nobody should feel dumb or forgetful for not knowing what area we're talking about or what coordinate system we're using. It wasn't specified, so the sky's the limit.

[Void Main]

I also prefer degrees in -DDD.FFFFFFFF (fractional degrees with negative being west and south) as it seems to be the easiest for me to work with (computationally). That's the way the data is dumped from most GPS units as well. It's certainly eaiser than DDD.MM.SSI or DDD.MM.FFFFFF but converting between them isn't a big deal so it's all good.