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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: [emergency] Re: [emergency-comment] Public Comment

I wanted to put my $.02 U.S. into this discussion for a number of 
reasons, but mainly to make the one point I am most interested in wrt 
CRS and GIS systems-thinking, as I prefer to think about it. That 
point is that we need liaison efforts between standards organizations 
to provide aids and guidance within a more widespread push for 
adoption of these standards.

This is more difficult and less rewarding than working on standards 
specificiations themselves, and that is difficult enough for anyone! 
I speak from experience. Whoever put it into my head that I should 
combine the overriding importance of Emergency Management with GIS 
and Health Informatics (HI) should be taken out behind the woodshed 
and seriously violated. ;-)

However, both GIS and HI share problems in terms of having standards 
that are overlapping, often inconsistent, contain some standards with 
terminology conflicts and are simply difficult to harmonize or select 
amongst for a given subdomain application, like medical billing, for 
instance, or manual confirmation of location parameters for automatic 
remote sensors. I am personally involved in developing 
ontologically-based semantic interoperability tools and practices 
(mainly practices) for accomplishing this in both domains.

I agree with Carl that a more flexible, open approach is needed, and 
since I am co chair of the SC in the EM TC that will grapple with 
including GML in CAP 2.0 and in EDXL"s various component 
specifications, I think that what we really need is a way to make 
choosing the correct standard or mixing and matching standards 
easier. Then, eventually the marketplace will select in practice what 
we can't predict while building standards using other standards.

I support adopting GML period, but common sense tells me that we are 
going to continue having a tough sell to governmental agencies, 
departments, ministries, etc., which have fairly extensive, 
entrenched vested interests in one or another standard, such as the 
US Dept of Transportation which has adopted IEEE 1512.

IEEE 1512 is a fine standard, except that it doesn't easily fit into 
an XML world of web services information delivery. A vague 
recommendation for translating the standard into XML Schema in a 
roll-your-own approach for decision support information aggregation 
services is a prescription for a separate disaster from whatever 
incident requires a well-informed first response and where DoT 
information is critical. Unfortunately, the chances are zero of DoT 
providing its own translation standard and I haven't heard that IEEE 
is even approachable about providing such a standard translation. 
(I'd like to be wrong about that, and I admit I am not a member, 
can't afford it in the foreseeable future within my own priorities 
and that is the only sure way to be heard on the matter. However, 
like many people, paying for the privilege of opposing set policies 
in a venerable (ie change-resistant) organization just isn't very 

The point is that even when or if such a reliable translation 
standard comes about, publicizing it and making it available easily 
and quickly is an oxymoron, given that IEEE operates on a fee-based 
model that just adds another nickel to the nickel and dime barrier to 
adoption of standards. I think it is safe to say the Section 508 and 
other such considerations for underserved population segments, 
specifically poor people, simply won't happen, so we have a lot of 
work to do to make the standards we have and those we are building 
work out there where the rubber meets the road.

Just FYI, I am building a set of registries to accomplish some of 
this as a prototype in a Semantic Interoperability Architecture Pilot 
sponsored by the US federal Semantic Interoperability Community of 
Practice chartered by the CIO Council Architecture and Infrastructure 
Committee. So, I am not solely a problem describer.


At 4:47 PM -0700 2/28/06, Carl Reed OGC Account wrote:
>I appreciate this dialogue. On a number of occasions I have 
>suggested that both CAP and EDXL should have optional elements for 
>alternate CRS's as well as simple GML fragments for point, line, 
>circle, and polygon. There has been considerable and good discussion 
>on these points over the last 18 months. We hope that this can 
>happen as part of the CAP 2.0 work.
>As to David's point regarding GPS and WGS-84. This is true. However, 
>we cannot assume that either an alert or an emergency message will 
>be generated based on devices/applications that generate lat/long 
>coordinates in WGS-84. Further, other standards work related to the 
>emergency message/alert infrastructure, such as OMA, concluded 
>that a more flexible, open approach to dealing with CRS. From the 
>Mobile Location Platform API standard (Version 3.2), the following 
>is how they define a CRS:
>                   srsName
>srsName is a short hand method of defining the 
>CoordinateReferenceSystem. It is a URI datatype that contains the 
>codeSpace and code values, which are defined in the same way as in 
>the CoordinateReferenceSystem.
>Char String
>Defined values:
>Default value:
><Box srsName="www.epsg.org/#4326">
>This attribute is optional and is on all shape elements. If the 
>srsName is not included the WGS84 CRS SHOULD be assumed.
>Years ago, the Location Interoperability Forum, now part of OMA, 
>decided to use OGC/ISO best practices for dealing with geospatial 
>content. It is also of interest to note that geometry structures 
>used in MLP are based on GML (although a bit out of date). Why did 
>they follow this approach? Well, for one they recognized the need 
>for insuring that any telecommunications carrier anywhere in the 
>world could use the MLP API and not worry about differences in 
>location technology, coordinate reference system handling, and so 
>So, what this means is that it is quite possible that emergency 
>alerts/messages generated from the mobile location services 
>infrastructure (read cell phones) will be packaged based on the 
>content of an MLP payload. I should also add that this includes 
>units of measurement. In the case of MLP, the default is survey foot 
>- not kilometers.
>Just something to think about.
>Also, below my signature, take a look at a slide from a presentation 
>about IEEE 1451.5. This slide was prepared by 3eTI, a sensor network 
>hardware/software provider. (This is not an endorsement by myself or 
>the OGC of any of the products shown in the slide - this slide is 
>provided as an example only) The IEEE-1451.5 wireless standard 
>promises to integrate a wide variety of sensors with a number of 
>different wireless radio implementations using standards based 
>protocols to communicate between the application and the sensor. I 
>bring this up because again many alerts and notifications will be 
>generated from sensor networks something like the one shown below. 
>It is also interesting to note that this is a secure network. One 
>more point - the location of the sensor is communicated (as part of 
>the 1451.5 draft standard) as a point profile of GML :-)
>----- Original Message -----
>From: "Van der Vlugt, Maurits R (SKM)" 
>To: "David Danko" <<mailto:DDanko@esri.com>DDanko@esri.com>; 
>Sent: Tuesday, February 28, 2006 3:38 PM
>Subject: RE: [emergency-comment] Public Comment
>  > Hi Dave,
>>  Thanks for your comments. I couldn't agree more:
>>  Yes, optional GML should be allowed as a minimum - and it should be as
>>  simple as possible.  I'm all for maximising take-up by both users and
>>  industry (not unrelated).
>>  The question then is: can we not define a EDXL-profile of GML that is
>>  simple enough for the EM community, yet is automatically compatible with
>>  the GIS community? I'm no GML guru, but ideally this would be a GML
>>  profile that is 'lean and mean' (like the SF profile), which could for
>  > instance mandate WGS84 as the default SRS unless extended/overridden by
>>  a specific user community?
>>  You state that EDXL will be used in specific clients that don't do
>>  coordinate transformations. If this is the case, then I agree that
>>  prescribing (default) WGS84 is needed. But will it be used exclusively
>>  in such clients?
>>  Mind you: I'm not advocating GML solely for the purpose of allowing
>>  alternative SRS-es. I guess the point is that (theoretically?) using GML
>>  as a baseline would still allow you to have a simple, default and
>>  workable spatial component, but at least it would be (a) interoperable
>>  with GIS software and (b) extensible for specific user communities
>>  should they wish to do so.
>>  Can we have our cake and eat it too? I mean: isn't that what cake is
>>  for, after all?
>>  Best regards,
>>  Maurits van der Vlugt
>>  Senior Geo-IT Consultant
>>  Sinclair Knight Merz
>>  100 Christie St
>>  St Leonards
>>  NSW 2065
>>  Tel: +61 (2) 9928 2551
>>  Fax: +61 (2) 9928 2224
>>  Mobile: +61 403 349 341
>>  Email: <mailto:mvandervlugt@skm.com.au>mvandervlugt@skm.com.au
>>  P
>>  Please consider the environment before printing this e-mail
>>  Sinclair Knight Merz
>>  Achieve Remarkable Success - Our Commitment to Clients
>>  For further information, visit our website
>>  -----Original Message-----
>>  From: David Danko [mailto:DDanko@esri.com]
>>  Sent: Wednesday, 1 March 2006 6:21 AM
>>  To: <mailto:emergency@lists.oasis-open.org>emergency@lists.oasis-open..org
>>  Cc: Van der Vlugt, Maurits R (SKM)
>>  Subject: FW: [emergency-comment] Public Comment
>>  EM TC (and Maurits)
>>  Some comments on the comments below about using GML:
>>  1. If we want to use GML, keep it OPTIONAL AND IN-ADDITION to the way it
>>  is now, mandating a few simple geometries and WGS 84
>>  2. True, Australia uses GDA 94, North America uses NAD 83; but in an
>>  international specification it is best to use a global model especially
>>  for what EDXL is designed for. To quote an Australian publication:
>>  "Given that the ITRF and WGS84 reference frames are also
>>  very closely aligned, for most practical purposes GDA94
>>  and WGS84 coordinates can be considered the same"
>>  3. When you use a GPS receiver the coordinates are displayed in WGS 84
>>  (even in Australia)
>>  4. EDXL will be used in clients that CAN NOT handle coordinate
>>  transformations. So the coordinate reference system should be known
>>  ahead of time - identifying it in the EDXL is the best way to do this.
>>  Using GML/user identified coordinate reference systems will be fine for
>>  users needing to additionally identify target areas down to the
>>  centimeter and correcting for tectonic plate continental drift.
>>  Dave
>>  David M. Danko
>>  GIS Standards
>>  Environmental Systems Research Institute, Inc.
>>  8620 Westwood Center Drive
>>  Vienna, VA 22182-2214
>>  USA
>>  E-mail: <mailto:ddanko@esri.com>ddanko@esri.com
>>  Tel: 703-506-9515 x 8011
>>  Mobile: 703-989-1863
>>  Fax: 703-506 9514
>>  -----Original Message-----
>>  From: 
>>  Sent: Friday, February 24, 2006 8:49 PM
>>  To: 
>>  Subject: [emergency-comment] Public Comment
>>  Comment from: <mailto:mvandervlugt@skm.com.au>mvandervlugt@skm.com.au
>>  Name: Maurits van der Vlugt
>>  Title: Senior Business Systems Consultant
>>  Organization: Sinclair Knight Merz Pty Ltd
>>  Regarding Specification: EDXL-DE
>>  Dear EM TC Members,
>>  I am responding to the EDXL-Dev1.0 specification, issued 14 February, on
>>  behalf of Sinclair Knight Merz (SKM), an international engineering
>>  consulting firm, based in Australia.
>>  Amongst others, we are involved in feasibility studies for Emergency
>>  Management (EM) systems, dispatching, GIS and interoperability, for a
>>  wide range of clients. Currently, we are finalising a "Resource Tracking
>>  and Information Management Feasibility Study" for the Office of the
>  > Emergency Services Commissioner (OESC) in the state of Victoria.
>>  In this light, we applaud the efforts by this TC and welcome the
>>  EDXL-Dev1.0 specification. However, we have some concerns about its
>>  potential impacts on interoperability between EM and spatial information
>>  systems (GIS):
>>  1) Through our experience in Australia with the OESC study and
>>  other projects such as the Spatial Interoperability Demonstration
>>  Project (SIDP: <http://www.sidp.com.au>www.sidp.com.au), we know 
>>that (geo-)graphical display of
>>  EM-related information (such as resources, dispatches, incident reports)
>>  in multi-agency collaborative environments is critical.
>>  2) Geospatial display and analysis is most commonly done with
>>  Commercial off the Shelf tools, virtually all of which now can by
>>  default ingest Geographic Markup Language (GML) as the standard format
>>  for exchange of geographic features and their attributes. Hence, the
>>  inclusion of a (simple) GML structure in the TargetArea object of
>>  EDXL-DEv1.0 would be considered critical for easy adoption of the
>>  standard for EM interoperability purposes.
>>  3) By adopting GML as the method for location description, we would
>>  also enable the use of alternative spatial reference systems. In
>>  Australia, the national standard for instance is not GWS84, but GDA94.
>>  And I'm sure similar situations exist in other countries.
>>  4) Adopting GML would also mean the automatic inclusion of an
>>  altitude element (relevant for e.g. locating of aircraft) and temporal
>>  resource tracking.
>>  In summary: effortless and seamless interoperability between EM and
>>  (COTS) GIS systems is an essential prerequisite for successful
>>  multi-agency EM collaboration. We strongly recommend that this TC
>>  seriously consider using the universally accepted standard of GML to
>>  represent geographic locations within the EDXL-DE specification to
>>  achieve this level of seamless and effortless interoperability.
>>  Many thanks for your consideration, and wishing you all the best with
>>  your work,
>>  Regards,
>>  Maurits van der Vlugt
>>  Senior Business Systems Consultant
>>  Sinclair Knight Merz Pty Ltd
>>  <mailto:mvandervlugt@skm.com.au>mvandervlugt@skm.com.au
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail:
>>  For additional commands, e-mail:
>>  Please consider the environment before printing this e-mail.
>>  Notice - This message contains privileged and confidential 
>>information intended only for the exclusive use of the addressee 
>>named above. If you are not the intended recipient of this message 
>>you are hereby notified that you must not disseminate, copy or take 
>>any action in reliance on it. If you have received this message in 
>>error please  notify us immediately. Opinions, conclusions and 
>>other information in this e-mail and any attachments that do not 
>>relate to the official business of the firm are neither given nor 
>>endorsed by it. Any documentation produced using this data is 
>>uncontrolled and not subject to update. The recipient is 
>>responsible for reviewing the status of the transferred information 
>>and should advise us immediately upon receipt of any discrepancy. 
>>Any design details are applicable to the intended project only. 
>>Subject to contract, we retain copyright of all the transmitted 
>>material and it must not be reproduced wholly or in part, or 
>>supplied to any third party without our written permission. The 
>>sender makes no warranty regarding the accuracy or completeness of 
>>the data transmittal or to the presence of computer viruses or data 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

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