emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency-comment] Public Comment
- From: "Carl Reed OGC Account" <creed@opengeospatial.org>
- To: "Van der Vlugt, Maurits R \(SKM\)" <MVandervlugt@skm.com.au>, "David Danko" <DDanko@esri.com>, <emergency@lists.oasis-open.org>
- Date: Tue, 28 Feb 2006 16:47:00 -0700
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:
Description: |
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. |
Type: |
Attribute |
Format: |
Char
String |
Defined
values: |
|
Default
value: |
www.epsg.org/#4326 |
Example: |
<Box
srsName="www.epsg.org/#4326"> |
Note: |
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 forth.
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 :-)
Cheers
Carl
----- Original Message -----
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: 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
> http://www.skmconsulting.com/Markets/spatial/
>
>
>
> -----Original Message-----
> From: David Danko
[mailto:DDanko@esri.com]
> Sent: Wednesday, 1 March 2006 6:21 AM
>
To: 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: ddanko@esri.com
>
Tel: 703-506-9515 x 8011
> Mobile: 703-989-1863
> Fax: 703-506
9514
>
> -----Original Message-----
> From: comment-form@oasis-open.org
[mailto:comment-form@oasis-open.org]
> Sent: Friday, February 24, 2006
8:49 PM
> To: emergency-comment@lists.oasis-open.org
>
Subject: [emergency-comment] Public Comment
>
> Comment from: 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: 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
> mvandervlugt@skm.com.au
>
>
>
>
---------------------------------------------------------------------
> To
unsubscribe, e-mail:
> emergency-comment-unsubscribe@lists.oasis-open.org
>
For additional commands, e-mail:
> emergency-comment-help@lists.oasis-open.org
>
>
>
> 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 errors
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]