[Fwd: Re: [emergency-gis] Re: [emergency] Kent State SymbologyStudy]

[Allen Wyke <emtc@nc.rr.com>]

Here is the email from Carl, which I referenced in my last email.

--Forwarded Message-- 
> From: Carl Reed <creed@opengis.org>
> To: Bill Schroeder <bschroeder@esri.com>, Allen Wyke <emtc@nc.rr.com>, mwalton@eteam.com
> Cc: emergency-gis@lists.oasis-open.org
> Subject: Re: [emergency-gis] Re: [emergency] Kent State Symbology Study
> Date: Wed, 06 Aug 2003 12:34:55 -0600
> 
> Hi Bill -
> 
> Thanks for cc'ing me on this email. As you may know, the FGDC typically
> deals with content standards and typically does not really worry about
> digital exchange or interoperability at the software/services level. This is
> not out of oversight or ignorance. Has to do with their mandate. That said,
> a couple of folks on the FGDC staff are very involved in the work of the
> OGC. The key person is Doug Nebert. He is currently Chair of our Catalog WG
> and Catalog RWG (the work in these groups may now offer an opportunity to
> collaborate with the new Infrastructure SC of the OASIS E-Gov TC).
> 
> In terms of symbology interoperability, this is an area (as Allen's email
> points out) that the OGC has had some experience in and our members have
> worked a number of activities related to symbology interoperability. So, I
> have a couple of suggestions (actions on my part).
> 
> Contact: Doug Nebert and get his view on this topic
> Contact: OGC staff and members who have worked symbology interoperability
> and begin to define a path ahead.
> 
> Does this make sense?
> 
> Carl
> 
> -- Original Message --
> From: Bill Schroeder <bschroeder@esri.com>
> To: Allen Wyke <emtc@nc.rr.com>; Carl Reed <creed@opengis.org>;
> <mwalton@eteam.com>
> Cc: <emergency-gis@lists.oasis-open.org>
> Sent: Tuesday, August 05, 2003 9:29 PM
> Subject: RE: [emergency-gis] Re: [emergency] Kent State Symbology Study
> 
> 
> > Allen/Elliot/Matt:
> >
> > I sat in on the a brief from FGDC and they are working on a release of the
> > symbols for comment in October.
> >
> > I asked the presenter (Michael Domarantz) if they were considering the
> > digital exchange of symbols and standards for interoperability and he
> > suggested that would not be undertaken by this working group.  It appeared
> > to me to be outside their scope and beyond their resources.
> >
> > I think this is a real issue/problem/opportunity.  In my opinion the
> problem
> > is one of those that is in need of a champion and more importantly one
> with
> > $ to staff and work the symbol interoperability effort.
> >
> > Do we want to seek a champion/funds/charter or join with an organization
> > which can do this (OGC)?   May be a question for the Exec Board.
> >
> > Bill
> >
> >
> >
> >
> >
> >
> >
> > --Original Message--
> > From: Allen Wyke [mailto:emtc@nc.rr.com]
> > Sent: Monday, August 04, 2003 8:45 PM
> > To: Carl Reed
> > Cc: emergency-gis@lists.oasis-open.org; IF SC
> > Subject: [emergency-gis] Re: [emergency] Kent State Symbology Study
> >
> > On Mon, 2003-07-21 at 17:28, Carl Reed wrote:
> > > The topic of symbology may be an opportunity for the EM TC and the OGC
> to
> > > collaborate. Our membership has done considerable work in the "how" of
> > > interoperability for encoding and communicating symbology. We do not
> deal
> > > with the actual definitions (content) for symbols. Symbology definition
> is
> > > better done by groups such as USGS, FEMA, NIMA, APWA, and so forth.
> >
> > I agree - this is a good place to collaborate. I actually have been
> > exchanging emails with Scott McAfee at DHS, whom Bill S (ESRI) has been
> > communicating with as well. Scott had mentioned that he was working with
> > you guys on this.
> >
> > >From an EM TC perspective, I think the proper approach would be for the
> > GIS SC to formally take on this effort - "effort" being defined as
> > summarizing the areas of collaboration and vision, so that the greater
> > EM TC can understand the overall purpose. Is that something you can
> > initiate with Bill and Eliot? Or maybe, we just did that :)
> >
> > Any thoughts on how best to proceed would be appreciated.
> >
> > > For example, we have an OpenGIS specification called "Style Layer
> > > Descriptor" (SLD). SLD - using XML Schema - provides a mechanism for
> > > expressing symbology portrayal rules to an application client or to a
> > > server. The reason our members defined and adopted SLD as a
> specification
> > is
> > > that when a user is requesting spatial data from multiple servers, how
> can
> > > the user be assured that they will see the spatial data rendered in a
> > common
> > > consistent manner using symbology that they are used to?
> > >
> > > We are also working on various other aspects related to interoperability
> > and
> > > symbology, such as symbology metadata and how to build, maintain, and
> > access
> > > a library of symbol libraries.
> > >
> > > The SLD specification can be found on the public portion of our web site
> > > (www.opengis.org).
> >
> > Ok, so I think you might have answered my initial question of where to
> > start here. This certainly sounds like a VERY exciting and applicable
> > area of interest, although I would defer to the experts on if it is the
> > only area (I assume not) for the EM TC.
> >
> > That being said, I have cross posted this with the EMIF SC, because this
> > certainly spans the topic of the greater EM infrastructure. I think the
> > question to the EMIF that stimulates the potential answer you have
> > provided is, "with the presence of an agreed upon symbologize standard,
> > what is the best way to exchange data that includes those symbols that
> > maintains the intent of the originating source?" If SLD is potentially
> > an answer to that question, which is sounds like it is, then the next
> > step would be to work with the EMIF to make sure it found its
> > appropriate home in their specs.
> >
> > This is only my personal initial thought based on what you have
> > provided. I will defer to Rick and his group to determine/evaluate if
> > SLD is part of their picture, and to the GIS SC to probe you for
> > additional areas of collaboration. In the meantime, if you have any
> > other ideas, thoughts, or recommendations, we certainly welcome the
> > insight.
> >
> > Allen
> >
> > > I look forward to exploring this potential area of collaboration.
> > >
> > > Regards
> > >
> > > Carl Reed
> > > OGC
> > >
> > > -- Original Message --
> > > From: Allen Wyke <emtc@nc.rr.com>
> > > To: David Hall <dhall@federalsupportsystems.com>
> > > Cc: Emergency Management TC <emergency@lists.oasis-open.org>;
> > > <emergency-gis@lists.oasis-open.org>
> > > Sent: Monday, July 14, 2003 7:35 PM
> > > Subject: Re: [emergency] Kent State Symbology Study
> > >
> > >
> > > > This is actually an excellent report. I have cross posted it with the
> > > > GIS SC.
> > > >
> > > > Eliot/Bill: I recommend we attempt to contact Dr. Dymon
> > > > (udymon@kent.edu) and see if he can speak at one of your con calls. In
> > > > conjunction, we should try and ascertain the status of the work at
> FEMA,
> > > > if they received this paper, and get their thoughts/direction. The
> goal
> > > > would be to specify where we (the EM TC) plans to draw its symbology
> > > > from, even if it is in a working draft state.
> > > >
> > > > Thoughts?
> > > >
> > > > Allen
> > > >
> > > > On Tue, 2003-07-01 at 13:36, David Hall wrote:
> > > > > The following is a link to the Emergency symbology study performed
> by
> > > > > Kent State for FEMA that was mentioned in today's XML committee
> call.
> > > > >
> > > > > http://dept.kent.edu/geography/Dymon/symbology.htm
> > > > >
> > > > >
> > > > > ******************************
> > > > > David Hall
> > > > > Federal Support Systems
> > > > > 703-627-0215
> > > > > 703-832-5664 fax
> > > > > --
> > > > > System Engineering
> > > > > Information Security
> > > > > Internet Software Systems
> > > > > Project Management
> > > > > ******************************
> > > > >
> > > > --
> > > > R. Allen Wyke
> > > > Chair, Emergency Management TC
> > > > emtc@nc.rr.com
> > > > http://www.oasis-open.org/committees/emergency
> > > >
> > > >
> > > > You may leave a Technical Committee at any time by visiting
> > >
> >
> http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro
> > > up.php
> > > >
> > --
> > R. Allen Wyke
> > Chair, Emergency Management TC
> > emtc@nc.rr.com
> > http://www.oasis-open.org/committees/emergency
> >
> >
> > --
> > To unsubscribe, e-mail: emergency-gis-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: emergency-gis-help@lists.oasis-open.org
> >
> >

-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency