CAP <geocode> element needs to adopt 'recognized' coding systems

[Jeff Kyser <ktrails@comcast.net>]

Hey all,

I started this post on the cap-interop@lists.incident.com mailing list, 
and now
see portions of my original comments on oasis lists. I've tried to 
follow them
through, but still don't see a resolution of my concern. If it is out 
there in the
e-mail ether, please let me know where I can find it. Here's my concern:

	that a 'free text', optional field such as geocode does not lend 
itself to
	mapping CAP messages into existing alert/warning systems, and filtering
	these messages by geographic data, especially for older systems that
	may not yet be set up to deal with polygons.

	Specifically, the use of 'user-assigned abbreviations' for the target
	systems limits this field's utility to cases in which the message 
producer
	and message consumer know what the target system is a priori.

	While I fully agree that there is no "one true set" of geocodes that 
will
	suffice for all users, this field's utility to the community could be 
greatly
	increased by  identifying an initial set of coding systems, including 
the
	abbreviations and formats to be used.

	Examples (only for illustration) might include:

		fips=<5 digit code>
		same=<6 digit code>
		state=<2 letter code>
		zipcode=<5 digit code> or <9 digit code>
		areacode=<3 digit area code>
		csepp=<depot>:<zone>

	It would still be up to the message producer to determine which 
geocodes
	they could output, and up to the message consumer to determine which
	geocodes they could work from, but at least there would be a published
	set to start with, along with a standard set of abbreviations  for 
each. In the
	event that a producer did not find the coding system they wanted, they 
could
	still fall back to their own proprietary one, but at least then it 
would be a
	conscious decision rather than a mistake due to misnaming a commonly
	understood coding scheme.

regards,

-jeff kyser
Warning Systems, Inc.