Jump to content

The unofficial HEY JEREMY & ELIAS thread -suggestions, requests, bugs for the GC.Com Benchmark


RACooper

Recommended Posts

I've been looking through the forums and reading quite a few great suggestions (IMNSHO), but they're so scattered and in seemingly unrelated threads that they are hard to follow. I'll try and summarize some of them here, and please add more. I'll try and email Jeremy to request that he periodically look through this thread for bugs to fix, and hopefully suggestions to implement, for the Benchmarking section.

 

My issues/favorites so far:

1) BUG. Fix the Terraserver links from the benchmark data pages. (I entered this in the GC.com forum on 9/23 and haven't even seen a response to my posting, much less a fix.)

 

2) SUGGESTION: change the way Benchmarks are logged. Make two fields: Status and Condition. Status would indicate Found/Not Found/Note, and Condition would be Good/Poor/Confirmed Destroyed (or similar).

 

There's my starting list. What else can be done to improve the Benchmarking section?

 

[This message was edited by Tennessee Geocacher on October 22, 2003 at 06:05 AM.]

Link to comment

I've never found a mark of my own, of course (and that's not just a line from my signature. I really haven't found any marks.) but I've seen a lot of the same requests show up here from time to time. I'll just dump them here since it looks like a good place for them:

 

Pocket Queries, of course. Apparently bmgpx doesn't work for everybody. Some people want logs in their GPX files, for example.

 

Newer data, too. It sucks to find a mark that bmgpx has put into your GPX file, only to discover that you can't log the find because it hasn't made it to geocaching.com yet.

 

A prominent link to the benchmark section from the main page is another one that's been requested a lot.

 

pirate.cgi.gif

Link to comment

 

I'll second RACooper's suggestions and add: fix the "skull bug."

 

Also, I'm not entirely happy with the manipulation (resizing and/or recompression) of photos on either the GC site or the BM site. This is not acceptable. If thumbnails are needed for a gallery or some such other purpose, create them as necessary but leave the cache log and BM log photos alone! They are an integral part of our logs and as such should be treated with the same degree of respect and integrity. I can't stress this more.

 

Cheers ...

 

~Rich in NEPA~

 

--- A man with a GPS receiver knows where he is; a man with two GPS receivers is never sure. ---

Link to comment

quote:
Originally posted by Rich in NEPA:

Also, I'm not entirely happy with the manipulation (resizing and/or recompression) of photos on either the GC site or the BM site. This is _not_ acceptable.


1) What's the problem? Perhaps the resize is only done if the photo exceeds some limits. Perhaps the limits need to be better stated?

 

2) Be aware that IE6 will auto-resize images.

Link to comment

 

quote:
Originally posted by GeckoGeek:

1) What's the problem? Perhaps the resize is only done if the photo exceeds some limits. Perhaps the limits need to be better stated?


The problem is that any resizing and subsequent JPEG compression during saving degrades the image quality. The degradation is cumulative. You may not notice it, but I do. They're my images and I prefer not to have them modified. What's next? Rearranging the words and editing the text of our cache logs to suit someone's formatting whims?!

 

quote:

2) Be aware that IE6 will auto-resize images.


I have no control over what somebody does to the images when they're downloaded to their computer for viewing. I'm well aware of the recommended sizes and formats for Web images and I make every attempt to be considerate of the fact that most people don't have large high-resolution computer displays or fast broadband connections. Therefore I'm already voluntarily resizing my photos to around 640x480 pixels. The trouble for me was trying to stay under the original 100KB filesize limit. So now that the limit is lifted I should be able to take advantage of improved image quality, but this is not the case because now the website reduces them to 600x540 pixels and adds even more JPEG compression. (If the image is less than 600 pixels wide it is not resized but it is still recompressed and resaved.)

 

Maybe this is a difficult concept to comprehend but I consider my photos to be an integral part of my cache logs. I'm not interested in any photo gallery where images are displayed out of context, but if a gallery is deemed necessary then it should be a simple matter for the website to create smaller photos and thumbnails in a standard format for use with the gallery only. I see absolutely no reason to have cache log images modified.

 

I've also heard the argument that most people don't know how to resize and save their images. This is pure bunk. Anyone who can figure out how to use a GPS receiver to go Geocaching and then buys a 6 megapixel digital camera certainly has the capacity to learn this simple task as well. Every digital camera on the market comes with the software to resize and edit photos. Windows XP will resize images automatically for you. My 75-year old mother, who never touched a computer in her life until two years ago, knows how to resize photos and send them in her e-mails!

 

Cheers ...

 

~Rich in NEPA~

 

--- A man with a GPS receiver knows where he is; a man with two GPS receivers is never sure. ---

Link to comment

This originally was posted on 100/100:

quote:
quote:

Originally posted by Colorado Papa:

I pride myself in not finding a BM. I would much rather confirm a BM was wiped out by a railroad being abandonded and all tracks and signals removed. Or a road being relocated. Or read about a flood. Unfortunately, no credit is given for NOT FINDs, but more time was spent at a library researching old documents than in the field.


There really needs to be a major change in the paradigm used for logging benchmarks. Based on the concept of positive identification I am now logging missing/destroyed marks as "Found," but only as long as I can positively identify (beyond any reasonable doubt) that I've located the station itself. The "Destroyed" option needs to be removed immediately from the BM logging form, and a "Condition" field (with dropdown list or radio buttons) added for all "Found" logs. This field will indicate that the station is either "Good," "Poor," or "Destroyed." In most cases I would hesitate to mark a station as "Destroyed" until I could file an official recovery report to NGS and a determination was made by them and added to the datasheet. I'd go back and edit the BM log afterwards. (Also, once a station has been logged as "Destroyed" subsequent "finders" should not be allowed to log it as "Found." This will give the credit where it's due.) The "Not Found" option should remain as it is now—that is, the mark wasn't found, or if there is any question about its identity.

 

Cheers ...

 

~Rich in NEPA~


Rich and I are on the same page except I disagree with the not allowing subsequence finders to log a DESTROYED. It doesn't bother me to have someone confirm my findings, or, heaven forbid, an error!

 

1950 Surveyor

 

[This message was edited by Colorado Papa on October 06, 2003 at 01:55 PM.]

Link to comment

 

quote:
Originally posted by Colorado Papa:

Rich and I are on the same page except I disagree with the not allowing subsequence finders to log a _DESTROYED_. It doesn't bother me to have someone confirm my findings, or, heaven forbid, an error!


CP, that's not the point. I'm as willing as you to have my work subjected to scrutiny and constructive criticism, and I'm certain to make plenty of mistakes.

 

The problem, however, is how do you reward the person who puts so much time and effort into proving that a station is missing/destroyed. Do you think it's proper for someone else to read your logs and based on your evidence submit a "Find" for this station? You do realize, of course, that's it's much harder to prove that a station doesn't exist than to locate one that does? I already have a few "Not Founds" where I've searched for stations and discovered an empty hole in the rock where the disk should be. I accept the fact that in these situations I have not been able to positively identify the station as the one in question. I'm sure there will be many others like this. There would be nothing preventing any another person from searching out a station mark that you or I have listed as missing/destroyed, and if they did find it (highly doubtable, since "positively identified" means just that) they are free to report their findings to NGS and contest the previous determination. I don't see where this is a problem. On the benchmarking site, remember, there would be no "Destroyed" logging option, only a place on a "Found" log to list the condition of the station as either Good, Poor, or Destroyed. The evidence should be sent to NGS and they will decide if the datasheet gets updated with the new classification.

 

Cheers ...

 

~Rich in NEPA~

 

--- A man with a GPS receiver knows where he is; a man with two GPS receivers is never sure. ---

Link to comment

quote:
Originally posted by Rich in NEPA:

The problem, however, is how do you reward the person who puts so much time and effort into proving that a station is missing/destroyed. Do you think it's proper for someone else to read your logs and based on your evidence submit a "Find" for this station?


Oh, is thing about no "finds after a destroyed" all about score keeping? In other words the first finder/destroyer gets the points? I'm fine with that.

 

I thought you were saying that no one could post their logs after a "destroyed" finding.

 

Now who gets the points in a contested status is completely different question. How someone can do a "find" baised in the "destroyed" evidence of another is beyond me. But I can see where one person finds and another says it's destroyed (for a landmark station it could easily happen) there's going to be some question who gets to claim the points. I'm not sure how to solve that. I'm not sure as it's a problem worth solving in terms of points.

Link to comment

 

quote:
Originally posted by GeckoGeek:

But I can see where one person finds and another says it's destroyed (for a landmark station it could easily happen) there's going to be some question who gets to claim the points.


For many people benchmarking is like geocaching so points are always going to be an issue. And as long as benchmark logging follows the same model as geocaching, there's going to be the tendency to think in terms of actually finding something at the prescribed location. It might be easier to think of a benchmarking "find" as simply a "recovery," in the same sense that NGS defines it. A successful recovery of a destroyed station is still a "find" in the same sense as finding the disk itself. I think this is the part that's hard to grasp. In geocaching the proof of a find is signing the logbook, but in benchmarking the proof of a find is positive identification of the station, whether the mark exists or not. If the mark doesn't exist any longer, the burden of proof becomes much greater. (It's the logical equivalent of proving a negative.) However, in many cases there can be enough verifiable evidence to make the claim valid. (Who decides if there's enough evidence? NGS, of course, when you submit a recovery report.) We just need a system of benchmark logging that follows this model and not geocaching.

 

Cheers ...

 

~Rich in NEPA~

 

--- A man with a GPS receiver knows where he is; a man with two GPS receivers is never sure. ---

Link to comment

The point is:

 

You found Something?

What is the next thing.

There or not you (found some type condition).

This to me is found.

 

Would it not be proper to state I found......

this condition.

At these coordinates,I know from experience this could be way off though. But state this and the new condition.

Or after diligintly looking, like some of us do...........State that as the condition,and it would take someone with more experience to search the mark.Some I have gone back to several times with a metal detector and finally found.

 

So every Station,Benchmark,Nail,Rivet,Tower,Mast,Tank,Plaque,Reference Marks,Azimuths or Stone has a condition.

 

I even entered a wrong picture and a geocaher caught it and e-mailed me and I corrected it.

 

I think that honest people will make honest reports and their work will show it and there are always those whom take advantage of any situation.

 

I have pondered this point many times as to how to log, (WHAT I Found)......................

 

WHEN ALL ELSE FAILS

*GEOTRYAGAIN*

TAKE PRIDE IN AMERICA

http://www.doi.gov/news/front_current.html

1803-2003

"LOUSIANA PURCHASE"

http://www.lapurchase.org

"LEWIS AND CLARK EXPADITION"

http://lewisclark.geog.missouri.edu/index

 

Arkansas Missouri Geocachrs Association

http://www.ARK-MOGeocachersAssociatoin@msnusers.com

http://groups.yahoo.com/group/Ark-Mo-Geocachers

Link to comment

I had an additional thought, but it would take the cooperation of DaveD's office, and probably rebuilding the querys into the NGS database...

 

If there was a way to directly query a specific PID in the NGS database, the GC.com details page for a marker could be dynamically updated with the latest info in the NGS files. However, I haven't found any way to query the NGS data without using this form (ds_pid.prl) on their site. I guess it's really a lot to ask to have NGS recode their site just for GC.com's benefit...

Link to comment

RACooper wrote:

quote:
If there was a way to directly query a specific PID in the NGS database, the GC.com details page for a marker could be dynamically updated with the latest info in the NGS files. However, I haven't found any way to query the NGS data without using this form (ds_pid.prl) on their site. I guess it's really a lot to ask to have NGS recode their site just for GC.com's benefit...

 

The info in the geocaching.com database originally came from CD-ROMs, which NGS no longer distributes.

 

The same information is now available online, with annually-compiled files of datasheets for each county, supplemented by monthly releases of datasheets containing new information. (http://www.ngs.noaa.gov/cgi-bin/datasheet.prl)

 

So it seems an alternate approach would be to update the gc.com database using these archive files.

 

Implementation would not be trivial, or so it seems to me (a non-programmer) - probably involving a one-time download of about 3,000 county datasheet files and their migration to the gc.com database (to replace the current information, which is about three years old), followed by a regular maintenance program of monthly updates.

 

The files appear to be maintained on an FTP server, which I suppose would greatly simplify the transfer.

Link to comment

quote:
Originally posted by ArtMan:

So it seems an alternate approach would be to update the gc.com database using these archive files.


Rather than update gc.com files, the gc.com PID datapage could contain everything except the description. Add a Detailed NGS Description radio button which would access the NGS datapage directly as a sub-window, just like we have in this particular case for Post A Reply.

 

After thought: Make it a larger window (90%?)with a PRINT option.

1950 Surveyor

Link to comment

Rather than update gc.com files, the gc.com PID datapage could contain everything except the description.......

 

That would be the way to get datasheets, pull the current one from NGS web site in real time. It's very easy to do, I do it on my web site (Sample). Not much sense in keeping a db of datasheets because they change frequently.

 

Problem is this web site would still need a database with PIDS, coordinates, etc. to generate the other things people want, like lists of benchmarks in a particular area.

 

Be nice if the NGS web site had a simple list of PIDS by state/whatever that you could work from, but they don't seem to have that option. Updating fifty states would be much simpler than 3,015 counties.

 

It would be a large undertaking to duplicate the NGS data and keep it current.

 

BeachBum22

http://www.benchmarkhunting.com

Just because I can't find it doesn't mean it's not really there.

Link to comment

The bug with the gallery appears to be back.

 

http://www.geocaching.com/mark/benchmark_album.asp?start=288

 

If you click any of the LY2803 links or pictures, with IE you get a "problem with the page..." error, and with NS you get what appears to be an SQL error message:

 

"ADODB.Field error '800a0bcd'

 

Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.

 

/mark/log_details.asp, line 91"

 

Too many pictures, Rich, you broke the db icon_cool.gif

 

BeachBum22

http://www.benchmarkhunting.com

Just because I can't find it doesn't mean it's not really there.

Link to comment

Kinda slow I am but,I just started using the Geocaching Maps,The new one's that shows caches,WOW This will help alot in searching for Benchmarks as well.There great.

They are making progress I hope to see something like this for the Benchmarks.

Is there such a critter yet?

It takes me a while to digest all this new stuff,

you guys and gals with all the experience are a great contribution to the betterment of Education all of yuu'ns

 

WHEN ALL ELSE FAILS

*GEOTRYAGAIN*

TAKE PRIDE IN AMERICA

http://www.doi.gov/news/front_current.html

1803-2003

"LOUSIANA PURCHASE"

http://www.lapurchase.org

"LEWIS AND CLARK EXPADITION"

http://lewisclark.geog.missouri.edu/index

 

Arkansas Missouri Geocachers Association

www.ARK-MOGeocachers@yahoogroups.com

Link to comment

We've been working on new code to import the latest benchmark files. I think we just have a couple of issues with it before we can publish it to the site.

 

I'll look into the problems listed above. Fortunately we'll be moving to the new log a cache code for benchmarks, and plan to add additional fields that are recognized by the NGS. I have to add some additional code to bring a popup list of definitions for each log type.

 

I'll pin a topic to the forums when I'm ready to tweak the benchmark code.

 

smile.gif Jeremy Irish

Groundspeak - The Language of Location

Link to comment

All I can say for now is Thanks for all that you do.

I know you have your hands full and are doing the best you can for the Entire Group,what a challenge.

 

So for now I will keep on Caching

 

WHEN ALL ELSE FAILS

*GEOTRYAGAIN*

TAKE PRIDE IN AMERICA

http://www.doi.gov/news/front_current.html

1803-2003

"LOUSIANA PURCHASE"

http://www.lapurchase.org

"LEWIS AND CLARK EXPADITION"

http://lewisclark.geog.missouri.edu/index

 

Arkansas Missouri Geocachers Association

www.ARK-MOGeocachers@yahoogroups.com

Link to comment

 

quote:
Originally posted by BeachBum22:

Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.


Apologies. The record was deleted in order to add/change some of the information in the description and photo captions, and I didn't want that crappy edit notice on it.

 

~Rich in NEPA~

 

--- You might own the cache, but geocaching.com owns you. ---

Link to comment

quote:
Originally posted by BeachBum22:Problem is this web site would still need a database with PIDS, coordinates, etc. to generate the other things people want, like lists of benchmarks in a particular area.

BeachBum22


No problem. The gc.com PID page would still be the same, only the BM description would be gone, replaced with the radio button.

 

1950 Surveyor

Link to comment

Apologies. The record was deleted in order to add/change some of the information in the description and photo captions, and I didn't want that crappy edit notice on it.

 

Don't apologize. You get a Gold Star. Programmers love it when you tell them exactly what's wrong, because it's much easier for them to fix. Here's the bug:

 

1. User creates benchmark log.

2. User uploads pictures.

3. User deletes benchmark log.

4. User recreates benchmark log.

 

I'm guessing you didn't delete all the pictures before you deleted the log?

 

The original pictures in the gallery are linked to URL parms that no longer exist (&ID &L) and point to an invalid record in the db:

 

/mark/log_details.asp?start=312&PID=LY2803&ID=59074&L=57988

 

so they should have been deleted (by the software) when the original log was deleted.

 

New log is:

 

/mark/log_details.asp?start=216&PID=LY2803&ID=59177&L=58093

 

BeachBum22

http://www.benchmarkhunting.com

Just because I can't find it doesn't mean it's not really there.

Link to comment

quote:
Originally posted by BeachBum22:

Here's the bug:

 

1. User creates benchmark log.

2. User uploads pictures.

3. User deletes benchmark log.

4. User recreates benchmark log.


 

There's a related bug: if you add a log entry to a BM (e.g., a find or a note), then delete that log entry, the BM will always show up in the list of BMs returned on the "List of items found" page for your account, even though you have no apparent association with that BM.

Link to comment

At the present, when searching for nearest geocaches in my area, the list of caches also includes red check marks to the left of the cache name to indicate that I have already found that cache.

 

When searching for the nearest benchmarks in my area, the list of benchmarks is several printed pages long, but there are presently no check marks to indicate that I have already found a listed benchmark.

 

This gets particularly confusing when attempting to download benchmark waypoints by lat/long for my home, lat/long for my station, and by my zip code. Some benchmarks appear redundantly in all three lists.

 

Would it be possible to code the benchmark section so that listed benchmarks that have been found by the user are indicated by a check mark? This would make downloading new benchmarks to search for much easier, as each waypoint wouldn't have to be cross-checked against a list of benchmarks that I've already located.

 

Thank you for your time and attention!

 

Keith M. McDonald

"Wreck Diver"

Link to comment

quote:
The "Destroyed" option needs to be removed immediately from the BM logging form, and a "Condition" field (with dropdown list or radio buttons) added for all "Found" logs. This field will indicate that the station is either "Good," "Poor," or "Destroyed." In most cases I would hesitate to mark a station as "Destroyed" until I could file an official recovery report to NGS and a determination was made by them and added to the datasheet. I'd go back and edit the BM log afterwards. (Also, once a station has been logged as "Destroyed" subsequent "finders" should not be allowed to log it as "Found."

 

I would agree on principle. Unlike you, when I am convinced that something is destroyed, I mark it as 'not found' rather than as 'found'. I have used the 'destroyed' option extensively, but ONLY in order to mark the BMs that are already marked as destroyed or lost in the official history. I don't touch those that are officially described as 'ought to be considered destroyed', etc. If it's officially destroyed, it should be removed from the database, or at least be marked as such. If noone can do it, we should do it ourselves. However, we should not assume the authority to claim 'destroyed' somethign that was found when it was last checked officially, no matter how sure we are. That's not up to us.

 

http://www.shunra.net

 

e

H I D E & G O G E E K !

Link to comment

quote:
Originally posted by Wreck Diver:

At the present, when searching for nearest geocaches in my area, the list of caches also includes red check marks to the left of the cache name to indicate that I have already found that cache.

 

When searching for the nearest benchmarks in my area, the list of benchmarks is several printed pages long, but there are presently no check marks to indicate that I have already found a listed benchmark.

 

This gets particularly confusing when attempting to download benchmark waypoints by lat/long for my home, lat/long for my station, and by my zip code. Some benchmarks appear redundantly in all three lists.

 

Would it be possible to code the benchmark section so that listed benchmarks that have been found by the user are indicated by a check mark? This would make downloading new benchmarks to search for much easier, as each waypoint wouldn't have to be cross-checked against a list of benchmarks that I've already located.


 

Yes yes yes please!

 

http://www.shunra.net

 

e

H I D E & G O G E E K !

Link to comment

Here's another bug: I know of only two examples, but I suspect there are more, and there's bound to be an easy explanation...

 

Search for benchmark CS1770. Then click on the ''nearest benchmarks'' link and you'll see all the benchmarks within ten miles, but CS1770 is not in the list. It should be at the top of the list.

 

The same is true for CS1954.

 

How many more benchmarks are invisible in this type of search?

 

I discovered this while looking up PIDs I found in a short-range radial search on the NGS website.

Link to comment

quote:
Originally posted by AE5D:

Here's another bug: I know of only two examples, but I suspect there are more, and there's bound to be an easy explanation...

 

Search for benchmark CS1770. Then click on the ''nearest benchmarks'' link and you'll see all the benchmarks within ten miles, but CS1770 is not in the list. It should be at the top of the list.

 

The same is true for CS1954.

 

How many more benchmarks are invisible in this type of search?

 

I discovered this while looking up PIDs I found in a short-range radial search on the NGS website.


 

This is because benchmarks with a "MARK NOT FOUND" in the official history do not show up on the initial search of benchmarks. If you click on "See all benchmarks for this query" at the top of the search result page, you will get these benchmarks marked with a skull to indicate that they have a "MARK NOT FOUND" in the official history. Note that the "MARK NOT FOUND" does not have to be the last history entry for this to happen. The last history could be "FOUND" but a previous one marked as "MARK NOT FOUND" will still cause this to happen. WHen I did this for CS1770, so many benchmarks came up with a skull that I didn't bother to count them all. Well over half, at least at the beginning.

Link to comment

It would seem that the biggest improvement would be for the benchmark section to be coded just like the cache section:

Listings have checks next to your finds.

Pocket Queries with logs.

Searches for benchmarks by type (disk, rod, rivit, etc.) (found, not found)

Watch lists.

Pocket Queries with logs.

I'm content to wait, though.

I'm having a blast in the meantime!

Link to comment

I'd like to see more information in the benchmark section of My Cache Page. Currently it just shows the date, the PID, and a found/not found icon. If I want to check on a benchmark that I've already looked for, it's hard to remember the PID. Could we have additional fields that show the designation and type? And maybe the distance and direction from my home coordinates?

Link to comment

One thing that I would like to see is the benchmarks that I've found highlighted like my finds on the cache search pages. IE: white = not found, grey = found (and of course, yellow = mine!). Right now, I'm the only one in my area who actively hunts benchmarks so I tend to look for found dates on the benchmark search pages and assume the finds to be mine. It's a simple method, but it works, for the most part, unless another cacher finds a mark and logs it before I do. I encourage other cachers to find marks, but I sometimes overlook marks that others have found.

Link to comment
Yes, I know we can't own any benchmarks, so none of them will be yellow, but, if I find one with a 'Kewaneh' designation, I'm going to claim it. :D

I couldn't find one with a 'Kewaneh' designation. The best I could do is:

 

MF1699 KEWANEE 41 13 34.3/089 56 06.4 1 il073.dat

MF1702 KEWANEE AIRPORT AIRWAY BEACON 41 12 13.7/089 55 31.8 3 il073.dat

MF1710 KEWANEE ATT MWV KSH 98 41 15 26.8/089 56 19.8 3 il073.dat

MF1703 KEWANEE BOILER WORKS TANK 41 14 38.5/089 56 14.9 3 il073.dat

MF1704 KEWANEE BOSS MFG CO TANK 41 14 36.1/089 56 11.4 3 il073.dat

MF1696 KEWANEE CENTRAL SCHOOL CUPOLA 41 14 30.9/089 55 21.5 3 il073.dat

MF1701 KEWANEE PUBLIC SERVICE CO TANK 41 14 53.3/089 55 27.0 3 il073.dat

MF1705 KEWANEE RAD WKEI MAST 41 13 36.3/089 56 05.8 3 il073.dat

MF1700 KEWANEE ST PETERS EVAN CH CUP 41 14 32.9/089 56 01.4 3 il073.dat

MF1695 KEWANEE WALWORTH CO TANK 41 14 53.7/089 55 13.1 3 il073.dat

MF1698 KEWANEE WATER WORKS STACK 41 14 49.5/089 55 33.4 3 il073.dat

MF1697 KEWANEE WATER WORKS TANK 41 14 50.0/089 55 33.8 3 il073.dat

CO0330 KEWANEE 32 25 28.5/088 24 42.1 2 1 ms075.dat

CO0334 KEWANEE AZ MK 32 25 27. /088 25 01. 1 ms075.dat

CO0329 KEWANEE RM 1 32 25 29. /088 24 42. 1 ms075.dat

CO0331 KEWANEE RM 2 32 25 29. /088 24 42. 1 ms075.dat

GD1803 KEWANEE 36 40 18.2/089 33 43.1 2 mo143.dat

NO0398 KEWANEE 42 55 05.9/100 21 42.8 3 ne031.dat

 

and

 

AC4546 SHARK 2 25 23 53.5/081 09 03.0 2 fl087.dat

AC4545 SHARK 3 25 23 21.3/081 09 01.8 2 fl087.dat

AC4395 SHARK POINT 25 09 38.9/080 49 36.4 3 fl025.dat

PD1073 SHARK 44 23 21.9/067 58 58.5 2 me009.dat

EA1910 SHARK SHOAL BEACON 1 34 42 17.1/076 40 41.9 3 X

EA1911 SHARK SHOAL BEACON 3 34 42 30.9/076 40 46.6 3 X

EB2866 SHARK NCGS 1970 34 55 24.8/079 39 18.5 2 nc153.dat

KV5209 SHARK RIVER COAST GUARD STA 40 11 40.8/074 00 33.3 3 D

KV0809 SHARK RIVER RM 2 40 11 39. /074 00 31. X

AI5199 SHARK R INLET S SKEL TR NE LEG 40 11 11.1/074 00 26.0 3 nj025.dat

KV0808 SHARK RIVER 40 11 40.2/074 00 32.3 2 1 nj025.dat

KV5208 SHARK RIVER INLET CG TOWER 40 11 11.1/074 00 33.4 3 nj025.dat

AI5197 SHARK RIVER INLET N BKWTR LT 2 40 11 14.8/074 00 28.6 3 nj025.dat

AI5198 SHARK RIVER INLET S BKWTR LT 1 40 11 11.1/074 00 26.1 3 nj025.dat

KV5205 SHARK RIVER RM 3 40 11 43.2/074 00 32.9 2 nj025.dat

CK3267 SHARK 32 52 07.1/080 03 43.5 3 sc019.dat

CK6337 SHARK 32 48 47.6/080 36 39.1 1 sc029.dat

AU2612 SHARK 1933 29 47 10.5/091 51 38.5 3 la045.dat

AB1516 SHARK 26 07 49.3/097 10 10.7 2 tx061.dat

TR1806 SHARK REEF RESET 48 28 33.7/122 56 52.0 2 wa055.dat

 

or, how about:

 

HU1903 SHARKFIN SHOAL LIGHTHOUSE 1898 38 12 07.7/075 59 12.2 2 X

and

JP0371 SHARKS TOOTH 38 10 05.6/114 54 52.4 3 nv017.dat

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...