OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-gis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency-gis] Note about GML /[emergency-gis] Re:[emergency] Kent State Symbology Study


GREAT email! I think you nailed it. There are certainly some things the
GIS SC needs to look into. Per Eliot's earlier email
(http://lists.oasis-open.org/archives/emergency-gis/200308/msg00008.html) about needing to step down as Chair, I think you have done an excellent job at beginning to describe one of the initial tasks the new Chair will have before them.

Allen

On Wed, 2003-08-06 at 10:07, Rex Brooks wrote: 
> Hi All,
> 
> I took the liberty of pasting in Eliot's replies to Bill's message
> "Note on GML" and Bill's reply to Allen's Forwarding of David Hall's
> message about the Kent State Symbology Study and Carl's observations
> on that topic because I want to address all of these issues. ( FYI:
> This is exactly opposite of my usual policy of deleting messages in
> threads from the bottom when replying to avoid just such overly long
> and tedious messages. So to relieve this somewhat I am deleting most
> of the remaining header info on the messages.)
> 
> First, I looked at the Kent State material and downloaded the pdf(s),
> as I have also looked at the latest work on GML, and come to the
> conclusion that the subsets of these specifications which apply to EM
> need to be sorted, codified and examined to see what else may be
> needed to optimize the correlation of markup language with symbology
> for EM.
> 
> I would be willing to help work on this, but I am already well and
> truly stretched so how much time and energy I could put into this
> remains to be seen. I will try to find overlaps between this work and
> work to which I have previously committed.
> 
> I would like to respectfully suggest that this effort might best be
> headed by Carl Reed whose work stands to have to have the largest
> intersection with the needs of this area for EM. To that end I think I
> can manage to help draft a set of requirements as has been suggested
> for something along the lines of an Implementors Note for using CAP
> mapped to GML.
> 
> I said in the impromptu GIS SC telecon yesterday, before Eliot and I
> got cut off in mid sentence and I eventually gave up the wait for his
> return, that I would write to Carl about perhaps heading up this
> effort and decided to draft this note instead. I still hope Eliot can
> post whatever he was about to say about his efforts to put together a
> CAP2GML converter.
> 
> Regardless, I've gone and stepped in it.
> 
> One last note, as Allen has suggested, this significantly overlaps the
> Infrastructure SC work, so it would be advantageous if we could take
> this up in the next TC meeting to see if we can iron out a way to
> proceed.
> 
> Ciao,
> Rex
> 
> ______________________________________________________________________
> 
> Date: Wed, 06 Aug 2003 05:17:10 -0400
> To: emergency-gis@lists.oasis-open.org
> From: Eliot Christian <echristi@usgs.gov>
> 
> Subject: [emergency-gis] Note about GML
> At 02:56 PM 7/29/2003 +0000, Bill Schroeder wrote: 
> > The proposal distriubted by Elliot last week has set a GML 3
> > profile, the CAP schema would be an application schema based on
> > that, it would  extend those generic types to the CAP features. 
> 
> Just to set the record straight, I did consider but did
> not pursue the idea of making the CAP schema a GML 3
> profile. Instead, I just referenced some few elements
> (and associated attributes) defined in GML versions
> 2 and 3.
> 
> This approach was undertaken merely to demonstrate one
> way in which CAP alert messages are able to be handled
> in mapping applications that are GML-capable. Such a
> demonstration might lead to an Implementors Note, but
> I don't anticipate proposing a standard GML profile for
> CAP, nor a normative statement in CAP about GML.
> 
> 
> ______________________________________________________________________
> Date: Wed, 06 Aug 2003 04:58:54 -0400
> To: emergency-gis@lists.oasis-open.org,Carl Reed <creed@opengis.org>
> From: Eliot Christian <echristi@usgs.gov>
> 
> Subject: [emergency-gis] Symbology standards and the OASIS EM TC
> At 08:29 PM 8/5/2003 -0700, Bill Schroeder wrote: 
> > [...]
> > 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. 
> 
> Yes, resources for additional standards work is one central issue.
> 
> The other issue is to get a clear statement of exactly what standards
> work not already underway could be/should be done by the OASIS EM TC.
> We have heard interest in standardization of specific sets of symbols.
> It has been noted that FGDC is doing work in that area, as are some
> agencies. We also heard interest in stronger Federal coordination
> among the various agencies and groups that are dealing with symbols
> pertinent to emergency management. To me, this seems something that
> would be best approached by working through the FGDC.
> 
> We have also heard interest in how to specify symbols as part of a
> style when displaying a map. OGC developed a standard called Style
> Descriptor Language. Carl Reed also points out that OGC is working
> on symbology metadata and on handling libraries of symbols.
> 
> Allen has asked for a summary of areas of collaboration and vision.
> Personally, I would sharpen that request to ask for a statement
> of requirements addressing whatever additional standards work is
> felt to be needed with regard to symbology for emergency management.
> 
> We cannot really begin to muster resources until we have an agreed
> statement of what standards work is envisioned. Perhaps Bill or Carl
> may be willing to do a first draft of such a requirements statement?
> 
> Eliot
> 
> 
> ______________________________________________________________________
> At 8:29 PM -0700 8/5/03, Bill Schroeder wrote: 
> > 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 
> 
> 
> -- 
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
-- 
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]