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: RE: [emergency] GIS Profiles used in Emergency Services


Toby,

Glad to hear of your interest in the GML simple features profile developed for use in EDXL. The profile spec and schema are nearing completion of the process to become a Committee Specification Draft (CSD).

 

This draft spec and associated schema, as you have probably seen on related emails, have been approved by vote of the EM-TC to become a Committee Specification Draft (CSD) following a few remaining steps to complete in the OASIS approval and registration process.

 

Here’s a link to the location as it appears on the EM-TC page (points to a location in RIM-SC):

http://www.oasis-open.org/apps/org/workgroup/emergency-rim/download.php/43482/EDXLGSF_wd10.zip

 

Keep in mind that, until we have completed the OASIS process, the draft spec and schema are still not ‘final’. However, I believe the schema and spec are stable enough to begin to consider how it might be used in EDXL and perhaps other use. Perhaps Elysa Jones might clarify the status and access/use in case I might have mis-spoke.

 

Regards,

Lew Leinenweber

SE Solutions, Inc.

301.351.4485

 

From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Fri, 09 Sep 2011 10:15 AM
To: emergency@lists.oasis-open.org
Subject: [emergency] GIS Profiles used in Emergency Services

 

Long-time lurker.

 

Can someone give me a pointer to the GML profiles used in EDXL? There are many reasons to adopt the same or similar profiles.

 

-           Outages and Additional LEO requirements often coincide

-           Emergency “Keep Powered at all costs” locations often overlap with sites of interest to first responders.

 

Pointers?

 

Thanks

 

tc

 


"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

-Antoine de Saint-Exupery


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: Toby Considine [mailto:Toby.Considine@gmail.com]
Sent: Friday, September 09, 2011 10:11 AM
To: energyinterop@lists.oasis-open.org
Cc: creed@opengeospatial.org
Subject: FW: Use of Applicable Location in eiDistributeQuote

 

Received this note from Bruce yesterday…

 

From: Bartell, Bruce [mailto:bbartell@xtensible.net]
Sent: Thursday, September 08, 2011 6:38 PM
To: Toby.Considine@gmail.com
Subject: Use of Applicable Location in eiDistributeQuote

 

I am looking at the use of ApplicableLocation in eiDistributeQuote.

The way it is structured now I only seem to be able to access gml:AbstractFeature via the ServiceAreaType.

I noticed that serviceArea is part of the emixInterface substitution group. That group has ServiceDeliveryPoint, PNode, and other locations applicable to a price.

Was the intent to be able to get to the substitution group, extend the type through EmixInterfaceType, or both?

Both would seem to be the best way, if possible. As I said, right now I can only use gml:AbstractFeature in the ServiceAreaType.

 

Bruce Bartell

Xtensible Solutions

 

It highlights an area that EMIX 1.0 did not go to.

 

The GML AbstractFeature is like many of the EMIX objects; it is a not-useful-by-itself abstract tub in which you can put all sorts of GIS information. In EMIX, we specify that an AbstractFeature can fit into an EmixInterface. We never specified what was in it, though.

 

In general, best practice in GML-derived schemas is to derive specific types. EMIX leaves that as an exercise for the reader. EMIX specifies the Profile Level 0 be used. This restricts the features to points, lines, and polygons. No DR messages sent to all forested areas. No Quotes to all lakefront properties. An abstract feature can be a collection of features.

 

GML is very large. In a perfect world, with infinite time, we would meet for just as long on the GIS features as we have on everything else. We should define something similar to three types of features, name them and go.

 

A good introduction to these issues is at the Penn State Geography page on GML

 

https://courseware.e-education.psu.edu/courses/geog585/content/lesson06/11.html

 

At a first guess, I think we need:

 

-           A named “Bounded by” object. All things that are inside this polygon. We should give it a name.

-           Points (and collections of points). What is the meaning? Are all meters / locations w/I [50 ft] of one of those points subject to a DR event?

-           Lines, aka circuits. Do we want to support circuits? Again, are all Nodes w/I [100  Meters] of a Circuit affected?

 

Possible Shortcut. Emergency Management has been through this exercise. Perhaps we can re-use their definitions and work.

 

tc

 

 

 


"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

-Antoine de Saint-Exupery


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

 



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