What is the CAP standard and is it changing or has changed? We have ddd.ddddd in the G1000 and a camera using ddd mm.mmm and a handheld using ddd mm ss.
What should we use as a standard? Every time I try searching online I come across 10 year old manuals. :(
Whatever the customer, or the IC wants. I've used all three, and more than one at a time on the same mission. You just need to verify which at the start of the mission or sortie.
Quote from: SarDragon on April 22, 2016, 03:14:03 AM
Whatever the customer, or the IC wants. I've used all three, and more than one at a time on the same mission. You just need to verify which at the start of the mission or sortie.
Gotcha. I just figured one was more common than the others.
One format is more common, but as Dave said, use the format requested by the customer, IC or ops.
Lacking specific direction, which is likely, the following documents, for point position in latitude and longitude, all state to use degrees, minutes, decimal minutes (DDD MM.mm)
- Chairman of the Joint Chiefs of Staff Instruction CJSCI 3900.01 D "Position (Point and Area) Reference Procedures"
- Land, Coast Guard and Catastrophic Incident SAR Addendums to the US National SAR Supplement to the International Aeronautical and Maritime Search and Rescue Manual.
In my area of operations, the military and medevac helo crews all want coordinates in DDD MM.m.
Sarsat hit merge/composite positions (which is what AFRCC normally provides) are reported in DDD MM.m, tenth of a minute. The elementals (if you ask for them) are DDD MM.m, tenth of a minute for Doppler derived positions and DDD MM.mm, hundredth of a minute for encoded (GPS) positions. Reporting the encoded position to the hundredth of a minute doesn't mean it's more accurate.
Radar and NTAP coordinates will normally be given in DDD MM SS.ss
Degrees decimal degress (DDD.ddd) should be reserved for use by the GIS and map folks. It makes data entry much easier and consistent. This is the format that electronic devices store the coordinates no matter which format is used to enter them.
Regardless of the format used, there is only one "point" each in latitude and longitude. Always use the words degrees, minutes, seconds and point properly.
I'm not going to get into MGRS, USNG and UTM for ground operations. Those are for a separate thread.
Mike
Quote from: SarDragon on April 22, 2016, 03:14:03 AM
Whatever the customer, or the IC wants. I've used all three, and more than one at a time on the same mission. You just need to verify which at the start of the mission or sortie.
This is an odd little corner of the universe (I'm tempted to paraphrase Hunter S. Thompson here on the TV industry but will resist). The people I work with frequently have a list of street addresses, which have to be geocoded (converted to Lat/Long). That starts an awkward process.
For mapping,"DDD.dddddd" is not necessarily what is used because mapping applications -- at least the ones I use -- seem to like their latitude and longitude in radians (so that's R.rrrrrrrrrr [that's to ten decimal places]). (By the way, the GIS I use is SAS, which is an entire programming language and data analysis environment along with having GIS capability. There is a switch in some procedures to let the software know if you are not using radians, but radians is the default; you can even invent your own scale, which is somewhat odd.)
To further complicate things, the mapping coordinates are not really such that "there is only one 'point' each in latitude and longitude" [from "sardak"] as it turns out that in order to project a round earth onto a flat piece of paper the latitudes closest to the poles need to expanded longitudinally while the latitudes closest to the equator need to be compressed. There are specific reference latitudes for any given projection (specifically provided by the user or automatically assigned by the software and provided in the procedure log), but who knows what the longitude comes out as? From map to map, longitude may repeat in different places. (This is the difference between the actual unique coordinates and the "projected coordinates.") The data actually generating the map is not sharable with anyone else to use (as in, "Give me the coordinates of that dot on the map." "I'm afraid I can't do that.").
This means that for any given project it may be necessary to geocode a street address, put a star on a map using radians, provide a GPS user with degrees (in whatever format their unit requires), and if any other end-users are involved, provide degrees, degrees/minutes or degrees/minutes/seconds as required. This is complex, and the differences among the units that the individual end-users expect to receive requires constant attention; also, one can never assume that the end-users know these differences, or even know that there are differences (so verifying what the end-user needs at the start of the mission can itself be a vexing chore).
We can expect that as GPS and GIS become ever more common the complications will increase, rather than moving to some standard for all applications; and that as prices become ever lower an increasing number of non-technical end-users will be using these things, not necessarily knowing the best questions to ask before use, providing ample opportunity for confusion.
Just to support my own work I have written various utilities to accept input in degrees in any format (DDD.ddd..., DDD MM.mm, or DDD MM SS.ss), recognize the format, and convert the value to the other two formats along with radians; also, to accept radians and output the various degrees formats (globally, there is a problem with recognizing between R.rrr... and DDD.ddd..., but as long as the subject area is the continental U.S. that auto-recognition works for radians as well).
For SAR it's DDD.MMM.MM. Ref: Inflight Guide.
Quote from: scooter on April 25, 2016, 12:11:10 AM
For SAR it's DDD.MMM.MM. Ref: Inflight Guide.
True enough, but that is only one corner of an operational mission utilizing dozens of different services, of which CAP is only one element. It is unlikely that in an actual incident response situation that the incident commander (and his or her staff) have had any exposure to any "Inflight Guide" or have any other working knowledge of GIS (except for the one in their car). Under those circumstances establishing a common understanding of terms is impeded.
Regardless of all the training (e.g., FEMA's NIMS training -- we've all taken that, right?) that mandates common, standardized, plain language communications, there is still the problem that there are many elements of emergency services without a
lingua franca, due in large part to the technology being somewhat esoteric, which ultimately produces (1) management that lacks specific knowledge of the tools being utilized and (2) staff that often have to infer from imprecise direction what exactly management intends. (Lets not forget the Mars Climate Orbiter crash that was the result of a mix-up by software designers between metric and imperial measures.)
Quote from: docsteve on April 25, 2016, 09:24:37 PM
Quote from: scooter on April 25, 2016, 12:11:10 AM
For SAR it's DDD.MMM.MM. Ref: Inflight Guide.
True enough, but that is only one corner of an operational mission utilizing dozens of different services, of which CAP is only one element. It is unlikely that in an actual incident response situation that the incident commander (and his or her staff) have had any exposure to any "Inflight Guide" or have any other working knowledge of GIS (except for the one in their car). Under those circumstances establishing a common understanding of terms is impeded.
Regardless of all the training (e.g., FEMA's NIMS training -- we've all taken that, right?) that mandates common, standardized, plain language communications, there is still the problem that there are many elements of emergency services without a lingua franca, due in large part to the technology being somewhat esoteric, which ultimately produces (1) management that lacks specific knowledge of the tools being utilized and (2) staff that often have to infer from imprecise direction what exactly management intends. (Lets not forget the Mars Climate Orbiter crash that was the result of a mix-up by software designers between metric and imperial measures.)
To points 1 and 2, that's kind of the point of "management" - you don't need technical level knowledge of the software package, and you don't necessarily need to spell out every detail of your directions. That's why training highly skilled and proficient workers is important - the IC of a tornado incident doesn't himself care what format the coordinates on the aerial photography are, but ops and planning should know that in order for everyone to play nice, they should probably pick a format for the incident. Whether you want to derive that choice from a standard guide, or from what your software supports, or what you need to use to talk to other agencies, just pick a format and communicate it to the guys taking the pictures.
For CAP, ask the requesting agency what they want. If they don't know, do your best to figure out what is needed, and if you fall back on some internal standard in the lack of further guidance, so be it.
Looking a little more, like with the SC flooding. With the new FEMA Image Uploader software, it looks like FEMA does not want watermarked images anymore. No more running them through Robogeo and processing them first. No more 'North" arrows. Especially with the vertical imagery from the Virb, but apparently with obliques and all.
My point being, when you shoot obliques with a Solmeta on a DSLR, or you're shooting verticals with the Virb, both of those will be embedding DDD.dddddd ... like this for example: 33.202675, -87.402702. When viewing it on the FEMA CAP website map it will be truncated to 33.20, -87.40.
So ... I guess thats the FEMA standard. Other agencies wanting it differently will require post processing. FEMA wants those flooding or tornado images being uploaded as shoot as the AP's feet hit the tarmac. They don't want to wait for the images to be stamped, or processed.
At least ... this is my impression from the latest webinars and other info.
Many teams in our region are moving some of their mapping to the US National Grid system
https://en.wikipedia.org/wiki/United_States_National_Grid (https://en.wikipedia.org/wiki/United_States_National_Grid)
http://www.arcgis.com/home/item.html?id=dc352c5f18854d82b32bce92c0b6656b (http://www.arcgis.com/home/item.html?id=dc352c5f18854d82b32bce92c0b6656b)
Quote from: Spaceman3750 on April 25, 2016, 11:15:42 PMWhether you want to derive that choice from a standard guide, or from what your software supports, or what you need to use to talk to other agencies, just pick a format and communicate it to the guys taking the pictures.
For CAP, ask the requesting agency what they want. If they don't know, do your best to figure out what is needed, and if you fall back on some internal standard in the lack of further guidance, so be it.
+1 - we're not shelling frontline troops within 10 feet of the blue forces. CAP operates within a +/-5° universe to start with, coupled with aircraft that don't always have the option (or didn't for years) to
display in one or the other format, personal navigation and photo equipment, and very limited training, especially beyond "one punch and done".
In most cases, Google will get you and the teams where you need to be, anything else over and above that is gravy.
Quote from: etodd on April 26, 2016, 12:32:44 AM
...it looks like FEMA does not want watermarked images anymore.
Correct, this is has been the case since mid 2013.[/quote]
Quote from: Eclipse on April 26, 2016, 01:26:56 PM
Quote from: etodd on April 26, 2016, 12:32:44 AM
...it looks like FEMA does not want watermarked images anymore.
Correct, this is has been the case since mid 2013.
[/quote]
All the AP Skills Evaluators don't realize that yet. I just found that out the hard way after spending time installing and configuring Robogeo ... spending a couple hours plane time on my dime to demonstrate I know how to shoot and then stamp images ... so the AP Skills Evaluator would sign off everything on the SQTR. He really wanted to make sure I knew how to place the CAP logo, north arrows and info at bottom properly. NOW ... when its time to actually fly the final sorties to get signed off ... I get told by others ... BTW, we don't do those things anymore. Geez.
Yes ... the camera and computer are still in one piece. ;)