[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [emergency-gis] Re: [emergency] Kent State SymbologyStudy]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]