Actions

Ontolog Forum

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

BuildingServicePerformance Project Team Conference Call - Friday 28-Nov-2008

Session Title: Connecting Building Information with EDXL

Session Convener: DeborahMacPherson

Resources:

Next Meeting: TBD +/- 2 weeks. Michelle will develop short statement with goals and deliverables, will see when people are available to reserve the time.

Conference Call Details

  • Date: Friday, Nov. 28, 2008
  • Start Time: 3:00pm EST / 12:00pm PST / 20:00 UTC
  • Expected Call Duration: 2.0 hours
  • Dial-in Number:
    • from a US telephone (US): +1-218-486-3600 (domestic long distance cost will apply)
    • When calling in from a phone, use Conference ID: "4389979#"
    • from Europe, call:
      • Austria 0820-4000-1577
      • Belgium 070-35-9992
      • France 0826-100-280
      • Germany 01805-00-7642
      • Ireland 0818-270-037
      • Italy 0848-390-179
      • Spain 0902-886-056
      • Switzerland 0848-560-327 / 0848-414-110
      • UK 0870-738-0765
    • callers from other countries please dial into either one of the US or European numbers
  • Shared-screen support (VNC session) will be started 5 minutes before the call at: http://vnc2.cim3.net:5800/
    • view-only password: "ontolog"
    • if you plan to be logging into this shared-screen option (which the speaker may be navigating), and you are not familiar with the process, please try to call in 5 minutes before the start of the session so that we can work out the connection logistics. Help on this will generally not be available once the presentation starts.
  • During the session, you can also type in your questions or comments through the browser based chat session by:
    • pointing a separate browser tab (or window) to http://webconf.soaphub.org/conf/room and enter: Room="ontolog_20081128" and My Name="Your Own Name (in WikiWord format" (e.g. "JaneDoe")
    • or point your browser to: http://webconf.soaphub.org/conf/room/ontolog_20081128
      • instructions: once you got access to the page, click on the "settings" button, and identify yourself (by modifying the Name field). You can indicate that you want to ask a question verbally by clicking on the "hand" button, and wait for the moderator to call on you; or, type and send your question into the chat window at the bottom of the screen.
  • RSVP to DeborahMacPherson appreciated, ... or simply just by adding yourself to the "Expected Attendee" list below (if you are a member of the team.)
  • Please note that this session may be recorded, and if so, the audio archive is expected to be made available as open content, along with the proceedings of the call to our community membership and the public at-large under our prevailing open IPR policy.

Attendees

  • Attended:
    • Alan Vihn NIST BFRL
    • Peter P. Yim CIM3
    • DeborahMacPherson WDG Architecture, Accuracy&Aesthetics
    • David Coggeshall, San Francisco Communications, MapLab Project
    • Michelle Raymond, Honeywell ACS Labs and Knowledge Interaction Consulting
    • Toby Considine, TC9 Inc. OASIS oBIX TC, OASIS TAB
    • Bob Smith, City of Huntington Beach Env. Board, Performance Indicators
    • Rex Brooks, Starbourne Communications, EDXL TC OASIS
  • Expecting:
    • ... if you are coming to the meeting, please add your name above (plus your affiliation, if you aren't already a member of the community) above, or e-mail <peter.yim@cim3.com> so that we can reserve enough resources to support everyone's participation. ...
  • Regrets:

Carl Reed Official liaison from OGC to OASIS (traveling)

Agenda Ideas

Proposed Conference Call:

TITLE: Connecting Building Information with EDXL

Choosing 1 or 2 themes from list below for discussion. Thank you for your interest in this complex subject matter.

1. Sensor data, GIS data and Building Information Data - from BIM to EDXL - Building Information Systems overlapping SensorML from OGC - IT Sensor and EDXL standards - The levels of SensorML and oBIX - MVD, IDM, and IFC - Security applied to the structures of the BIM - Situational Reporting specification

2. Visibility and Relationships - The Smart grid - Where Building Emergency Response Information fits into EDXL - Where Emergency Medical Information Systems fit across disciplines and standards groups - The place of sensor data in relation to the Common Alerting Protocol and the EDXL Distribution Element (EDXL-DE) - Rendering on tiny devices - Generating interactive PDF's on the fly - Excluding data structures

3. Allowing for Testing - testing for conformance with NIMS mandated standards, e.g. CAP, EDXL-DE, EDXL-RM and EDXL-HAVE. - Embedded systems, building systems, power supply and distribution must all change their security model - learning how to adapt and keep adapting

4. Transparency in multi-million dollar energy efficiency and building performance discussions - investments during recessions - large green loan packages - BSP like performance indicators - specifying and contracting building service performance requirements

5. Widely distributed smaller problems, spread out nationwide or larger - Query in context - city's policy==>program===>budgeting==>performance metrics==>[repeat] cycles. - Infrastructure planning

6. People who need to be in the conversation - NBIMS - OGC - NIST Sensor Standards Harmonization Group - OASIS Emergency Management Technical Committee (EM TC), GIS Subcommittee (EM GIS SC), Messages and Notification Subcommittee (EM-Msg SC) - Emergency Interoperability Consortium (EIC)

7. The Building Emergency Response Scenario - Building Automated Alerts - Mapping Alerts to Floorplans - External Alerts - Incident Assessment - Communicating with the Building - Building Source Data Classification - Fire fighter building features - Alert event types and related categories - OmniClass

  • Slides here about these 2 paragraphs written by NIST BFRL

The scenario begins in a large commercial building [slide 1] at 321 Prince Street [slide 2], in a section of the third floor that is undergoing renovation. Contractors left out some vapor-producing chemicals that have ignited after-hours, producing a small explosion and starting a fire. The explosion disables the smoke alarm in the room, but this generates a trouble condition at the fire panel. The fire panel generates a Common Alerting Protocol (CAP) alert that is passed to the BISACS Base Server (BBS). The alert is then passed to the subscribing central station alarm (CSA) company that monitors the building. Upon receipt at the CSA, a representative attempts to contact the building personnel to verify the alert (smoke alarm trouble in room 310). While the CSA representative follows procedures to verify the alert, another alert arrives reporting a smoke alarm from the hallway outside 310. The CSA representative then immediately transmits these two alerts to 9-1-1 dispatch electronically, with both CAP alerts grouped together in a message.

The 9-1-1 dispatch center receives the CAP alerts with data fields from the message loaded into form fields in the Computer Aided Dispatch (CAD) software interface. At this point the dispatcher will see that there is a suspected fire in a commercial building at 321 Prince Street with smoke alarm trouble and alarm signals on the third floor. This likely indicates a working fire. The dispatcher will follow procedure to dispatch the jurisdiction's standard fire response to the building address. The CAD system will internally authorize each of these units to have access to building alerts and access to additional building incident data directly from the building BBS. The CAD system will transmit the building alert data on to responding units who will have the alert data presented visually and/or audibly.

Agenda & Proceedings

DC = David Coggeshall AV = AlanVihn TC = Toby Considine MR = Michelle Raymond DM = DeborahMacPherson PPY = Peter P. Yim RB = Rex Brooks BS = Bob Smith

DC Focusing on mapping to floorplans, collaboration with Onuma Planning System and Vectorworks

AV mapping position of alert onto the floorplan

DC break the assignment in 2 parts - shared between building owners and public safety, 2nd part are alerts

TC complicated

MR focus area of deliverables for working group as a focus for this group

TC a couple missing things: underlying system, failures in smoke detection, not 1 to 1 mapping. Other is the space, BIM shared, vs needing a warrant to share. Needs to be a mapping between business process and person, different than physical space. Problematic.

AV the security area is Toby from workshop

TC not just physically sensors to space, there are other issues to consider and need to keep this perspective in place

RB one key issue is some determination is if sensor data is released to the public

TC subset of the public, like and ambulance

RB at some point needs to be a legal determination about when that is required vs optional, get on the good legal ground first

BS will take forever

RB what the laws are now

AV what you can and can't do is complex, still trying to figure out HOW to do

RB but note the legal issues

DM Similar situations? Keybox for example, only the fire department, not the building owner

RB recommend bringing to the attention of OASIS legal XML group

BS can provide specific examples of what to be alert to, in the proof of concept connect A to B to C, with the amount of money in the economic stimulus, worries him there could be missed opportunities if this drags out

TC there are several proof of concept in commercial, but in standards make them repeatable and can scale. For example communication between city departments like Chicago. Have found for posing a street, they don't want to share working, policies and staffing but are beginning to share PDF and live sensor data. Moving past proof of concept into a specific way

RB can you provide the set of legal considerations, we can keep in the repository, building for important things to consider, at least be aware of

BS from state, feds, model fire code, transportation code etc, rerouting detours all these things are in legal environmental required documents for the city of Huntington Beach. What Toby is bringing up is important, the proof of concept is to tie geospatial to the alert system, dealing with specific standards....BIM has some capability for building Owners and insurance companies

AV Workshop slides scenario that David Holmberg, yes and have seen the graphical ppt that Bob is talking

DM the standard access point

RB case study of why an SOA needs to be designed

AV does everyone have the scenario document? Deborah is mapping that scenario onto those slides, some confusion how things work, but the one The workshop slides, the lower right is where the building is, automated alerts come out from there to a server that monitors one or more set of buildings.

See shared screen

Basically came from the orange cloud, the lower right corner then connects to proxy servers, initially intended as an internet network. At that point the CSA and 9-1-1 will talk or PSAP upper right hand side.

If any of these happen in the order you expect to happen in a fully functional city, they will receive the CAP messages then call back to the building to confirm, they can forward onto 9-1-1 future network that takes information to route to proper PSAP to dispatch appropriate responders. The dispatch people call the proper personnel who can then get into the building information - this is where the rules and security - once you are in the building you can attack the fire the proper way knowing where the fire is. Right now they don't know where the fire is

TC before can get the position, GIS, floorplans - when the building sends something out. Take a huge building at any given time there could be emergencies (heart attack, burglar) need to go back to get the alert - need to add an identifier for the building says Event 62, I'm the certified provider for Event 62

RB agree, what I'd really like to have, practioner steering group, DHS, IAC, OASIS working on a submission for the technical committee in February for a situational reporting specification, that will be the next large spec to work on under the EDXL family. This will be in there, developing a way to get a better ID. The CAP messages once they are sent out, who ever takes that responsability is addressing the false positives, as part of that, this particular piece of information - how to go about that. A suggestion about that aspect

AV buildings are sending out information from devices, each one has an identifier, I'm in alarm mode, here is my identifier, by the way my neighbors also have alerts and you should think this building is on fire. Send either to NG9-1-1 or directly to the PSAP. Low level alert forming a higher level agent...when the alerts come out, there is a callback URI to get back into the building server. Using proper authorization to get back into. Everything coming out is from the sensors which only know themselves

TC assumes the only information we get is what is the current - one sensor part of several system, same information having different meanings. ADT has taken six alarms and has access, they generate a report attached to those 3 sensors. Might be a good business model

TC continues, have to write as if the agent is entirely stupid, what if we sent this kind of message, you could get the MSDS sheets from the building Do have to walk through the sensors

AV sensor is the lowest level, a smart agent listening at the SI level, if these 4 or 5 devices are going off, will not send off low level like temperature, a smarter agent concept can be done at any level, the sensor, the CSA

RB there is a point in any sensor chain when some human being has to take responsability, that point has to get established, work out in negotiation and legislation, not here. Get the information to the decider, the CAP message can't go out on the network until the nonrepudiation has been resolved. Getting the digital firebox opened up for the responder

AV that is how CSA comes into play, Montgomery County for example, wants filtered. If in the future 9-1-1 will route to the proper PSAP

RB ground level standard in place before hand - whatever jurisdiction

DM want to see the standards - at each step

AV not every part is always there, if any piece is missing

RB getting the information what is there or what isnt there

AV that is why SAP is important, if one bubble is not there, go to the next one, back to square one and no body knows about it. Eventually when they talk back to the building.

MR see chat room notes - there is alert information that can come from any level, it gets aggregated at any level, each information provider has an identifier, some will have access and will be made available when its appropriate, then would have access. What can be retrieved may be policy based, and the incident needs an identifier, is a part of the identifier you need for policies

PPY can we make sure everyone sees the chat.

Michelle Raymond: Focus Area / Deliverable

1)Floorplan representation formats a.Translating data into format X 2)Information content a.Floorplan base layer (common) contents b.Metadata about the building/area c.Sensors and other objects within floorplan 3)Spatial-Temporal correlations a.Sensor events within site b.Architectural objects c.Mobile objects d.Objects with change of state 4)Space naming conventions a.Spaces in and around a building b.First responder naming assigned at event c.Associating data back into the floorplan

Toby Considine: Here is one example among many of legacy sharing data...

Toby Considine: http://www.caddataondemand.com/VisualMenusWrapper.aspx?sess=RC9UZK2FYPO93VE4AXH0

Michelle Raymond: Participants / Data providers: 1) Michelle Raymond, David Coggeshall, Toby Considine, Deborah MacPherson 2) SB30, Dan Farley, 3) connect with the survey standards a. Learn about survey standards for location (origin point, reference points, relationship between points) b. Connect with surveyors 4) NIEM has geospatial name code lists 5) NFPA GIS committee - Jim Smally

DC want to get to the initial subject of the call which is the floorplans, trying to get started on

MR agree, the focus area and deliverables are typed in, start in 10 minutes specifically for the NIST floorplan working group

TC how we identify instances at the global level, how to identify the provider, need to drill these down into the floorplan. Another perspective is spatial reporting, at a demand response group for the power grid, when there is potential brown out and start to negotiate they talked about getting from a GIS point up, then polygons going up for buildings, the report might include this is the area where the power goes out, but now the polygon says send a policeman where traffic lights are out. OGC helps this to work, spatial location, big shapy thing with with all these things in it

RB its called GML, we don't have a markup language for buildings yet. For 2D have GML and that is adapted in EDXL RM and EDXL HAVE.

TC I heard the need to have thumbtacks on map but relevant polygon also to enclose those six thumbtacks

RB there are ways to do that

TC now that zooms us down to the building itself

RB permissions there are a number of things to release the floorplans, if what we want to talk about is what we do when we have the floorplans

DC getting mixed up, representing floorplans in XML markup that is yet to be invented and nobody is using, repurpose and reuse existing floorplans via a target format, easy for a building owner to translate into.

RB OGC the GML getting to the building location

DC trying to repurpose existing floorplans into useable format, we don't have that capability in place yet. In NYC there is a local law for building owners of a certain size, need to submit in electronic readable format, submit to the fire department.

DM use PDF

TC for now that makes sense for someones hands tomorrow

AV like David, lot of people can't read the BIM

TC at least you can see something, there are still problems, come up with queries that have interactive information in it.

AV how do we map a sensor location onto the pdf?

MR the drawings, regardless of format, the base floorplan is still something that is input, that you then overlay the sensor data, where objects are, it acts as an image on the base level, you add information on top. Right now the primary tool is a printout and they use colored markers to put symbols on. This is where this belongs on the floorplan - if scaling and coordinate points are correct, then you can record

That base layer, where are the outer walls, rooms, doors, where are the architectural things that aren't supposed to have moved?

Like NYC that they required yearly updates. Most times JPG or PDF, need to find what NIST group can say what they would like to have.

DC the current requirement by code, to post evacuation floorplans in elevator lobby for exiting, that is a precedent for building owners to come up with an uncluttered floorplan with stairwells for example. This would be easy to get as level 0 or 1. Could be PDF, JPG, Scalable vector graphic, even if they just had those it would be a big step ahead. Where are the sensors is very advanced. Need to start with the primitive, you have to find who has the floorplan. Many times the deliverables are from the architect

DM try COBIE data, architect schedules every space, the MSDS sheets, goes in and out of XML very easily

TC start with a PDF, display on my PC, my iphone, the static PDF Level 2 is the interactive information with a variety of products on the market, toolkit to build those Longer term, COBIE is dead on with the right way to get it. There are some things going to affect COBIE coming up, not here today, the IFCs are the right way. Today, still need the solution for today.

DC the common operating picture, also want to do indoors and outside the building using displays made up of standard elements using JPG as background, can the PDF be sourced into a webpage? or does it have to be a generic raster file?

AV JPG would be better,

DC start with JPG as a raster background, add SBG, HTML area definitions, SBG is barely universal that could give hotspots on top of a JPG background

AV as far as implementing - JPG is easier, tied to SBG

TC would the SBG be isolated from background, the detail that is not needed to be live objects can be flattened. The difference is that a JPG is easy to get to if you are turning in a floorplan but don't have the responsability for the live drawings

DC Who will sheppard the composite drawing? Marrying to live objects?

TC If I take my floorplan as a spatial infomration, put a scalable vector thing in front of it.

DC I'm saying if you have all the technical capability, what would be a good end product. Combination raster vector format, flatten inactive, room perimiters and safety elements can be SBG on top. Both coming from the original vector source. What I'm hoping is a proof of concept what it would look like at the end result, get a feeling for wouldnt it be great for the fire department to have this?

MR may I talk about the other NIST groups in workshop? within NIST not just the floorplans but Scott Parker - is the lead over the CAP message format, what is the message? One thing he needs to provide is the list of information needed, where the staircases are etc - he is asking for required and desired elements list, not just floorplans could be events? That portion can be offline from the floorplan discussion. Send to Scott Parker by the first.

MR the floorplan working group focus

TC see the link on the chat room, a proof of concept from outside, would love for SBG to be real. In terms of results, see the link for the strawman. Take a peek at that and need to include in the study.

MR The floorplan working group came out of the NIST workshop, the focus area and deliverables

Floorplan representation format - how do you translate from one format to another? want to use NBIMS, IFC, look at whats available, doesn't answer the backward interoperability? Representation format and translation needs to be looked at

Information content - how do we break into the pieces? what goes into it? what belongs on that base layer? walls and doors? other elements? metadata about the building and areas in or near the building, defining the spaces in the building, for example egress route. Final in this are sensors and other objects.

Spatial temporal correlations - sensor events happening within that site, architectural objects, things that may be moving, may be preplaced emergency response objects for example oxygen. Objects that change their state, for example shutting off the gas or elevator moving.

Space naming conventions - in and around the building, now fire cheif says this is A, B, C, D sides of the building which all use to talk about when going - associating data back into the floorplan. Take these things that have been named and get them back into the floorplan?

Have I covered what is expected? Take on particular

DC what other people doesn't do any good, named and numbered by the owner, cant expect new layers or naming conventions, Those standards are great for internal documentation, this process starts with the floorplan and taking it from there....may go back to the owner with ambiguity or rooms that dont have names or numbers, or levels aren't named - but can't go impose a new additional requirement on every buidling owner out there. Its going to be hard to get buy in and participation unless very easy

AV list of things, has to be very easy for the owner, what they mean by first floor, does the fireman call it lobby? no matter what we have, there still has to be somekind of mapping over to the first responder, label, click on floor 1, level 1? Standard for labeling floors

MR will specifically call that out

DC how the building owner has their spaces identified and labeled is the starting point, then the requirement to turn that in which will differ in places, fire department, planning department. Once it gets to the city the follow up action is the fire department doing building inspections, start with the floorplans provided to see any conflicts between the labeling they prefer, feedback to the buidling owner to adjust the nomeclature, but again its going to be different in every single city, state - what they do with it - has to be put into a system of all the other floor plans. It has to be conformed to a format that can then be distributed. A standard electronic (or paper) format

MR agree with what you've said and one place to look for recommendations is NIMS typing. stay with these when feasible, will be clashes between NIMS and NIBS then make a recommendation to put into practice and in front of users

AV if we have a way of naming ahead of time and hand over to translations to pdf and jpg, as they create the floorplan for F1 or L1 then the file also has to be named. Type in F3 so it puts the right image on the screen for them. There has to be a convention, if they had a list ahead of time to pick from the list...here are your available floors, roof top or whatever correct 2 carachter representation. Trained to recognize those symbols

TC I hear that, but standard floors are a quagmire. Knows is 8th floor but sees 7 on all the doors

RB we have a mechanism we developed in EM TC - doesn't seem like it would work in the heat of an emergency, developing the connections SOA can use, if you have a naming scheme, publish it, anytime we are dealing with you, we will use your list. ValueListURN. It should cut down confusion

DM what is needed is a translator then

DC want to point out its next to impossible to have owners change their nomenclature, for example where hazardous materials are stored, unilaterally accept whatever their nomanclature is, the FEMA 120 types don't match up to California, need both stick with what everyone is familiar with, side by side column where one does follow a standard. Ex: 3 basements B1 B2 B3 another A B C in either case, owners won't change but if decide our standard for basement us U1 U2 U3 then we need to make the correlation between what the Owner calls it and what we call to be conformant to a standard to work with other things. That is a uniform naming scheme in addition to the owner, adding to, not changing. Particularly true when floor is used as the first letter of a room number. Be non=invasive adapt what is given to us.

MR back on the 4 main areas: representation formats, it seems DC is a good point person for that for Information Content, spatial temporal could be combined, space naming DM will be a point, MR can be the point for content formats, is Toby or Rex interested in the other? For now, MR will combine 2 and 3.

Move everything into the open through the BSP list

DC

looking at chronological, in and around the building, 1st responder naming should be in spatial temporal,

STATIC - from building owners, fire department goes out to validate 1 floorplan is fine, 4 should be 2 for naming conventions (they are static and can be prepared ahead and be on file),

DYNAMIC - interoperable, systematic 3 is now information content, would be the discrete elements relevant to safety and response, 4 spatial temporal is when an incident starts, changing state, real time

MR discussion forum list

DC has building samples on a science center 4 or 5 story building with alot of hazardous materials in labs, the facility manager is happy to work with to provide plans, and cooperation in naming and updating to make a good case study. Here is a starting example of the kind of floorplan, then talk with the fire department to make sure is accomodate.

DC you should get another building

BS would it make sense with Kimon Onuma? A few use cases taken from the actual world, one from the physical world, one from the digital world

MR like David Holmberg had the scenario, if we put the scenario into those buildings, what is static data, what can be put into a common format, what differs across areas, what needs to be put in real time

DC Request and suggest it would be useful for a half page or full page used to introduce to Kimon and Robert Anderson seeking participation and involvement? Who is in charge is this a NIST project? Ontolog? OASIS whoever owns the project from an administrative view, intended deliverables? would right away send to Robert Anderson NBIMS and IFC for floorplan layout

AV the fire response side

MR the floorplan working group, MR is lead on that, AV is a member, DC and DM members, reporting back to NIST. The larger project for work space and ownership is BSP, will take the lead. Just describe the floorplan portion of the project.

MR will be the lead on this specific project, with point people for specific things, Alan will you be the NIST liaison to ensure are meeting the workshop goals.

BS quick question for Alan - is there a typical after action report? could we study? if there was a list of questions could relay to Montgomery and Fairfax counties.

Peter P. Yim: Welcome to the BuildingServicePerformance Project Team Conference Call - Friday 28-Nov-2008 (1P5L)

Session Title: Connecting Building Information with EDXL (1P5M)

Session Chair: DeborahMacPherson (1P5N) Conference Call Details: (1P45)

  • Date: Friday, Nov. 28, 2008 (1P46)
  • Start Time: 3:00pm EST / 12:00pm PST / 20:00 UTC (1P47)

o ref: World Clock (1P4

  • Expected Call Duration: 2.0 hours (1P49)
  • Dial-in Number: (1P4A)

o from a US telephone (US): +1-218-486-3600 (domestic long distance cost will apply) (1P4B)

o When calling in from a phone, use Conference ID: "4389979#" (1P4C)

Peter P. Yim: Please point your browser to the session page at: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance/ConferenceCall_2008_11_28

Please change your name from 'anonymous' using the Settings button

anonymous morphed into DeborahMacPherson

anonymous morphed into AlanVinh

anonymous1 morphed into Toby Considine

anonymous morphed into Rex Brooks

Peter P. Yim: Resources (slides etc.) are now accessible at: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance/ConferenceCall_2008_11_28#nid1P6J

Michelle Raymond: Focus Area / Deliverable 1)Floorplan representation formats a.Translating data into format X 2)Information content a.Floorplan base layer (common) contents b.Metadata about the building/area c.Sensors and other objects within floorplan 3)Spatial-Temporal correlations a.Sensor events within site b.Architectural objects c.Mobile objects d.Objects with change of state 4)Space naming conventions a.Spaces in and around a building b.First responder naming assigned at event c.Associating data back into the floorplan

Toby Considine: Here is one example among many of legacy sharing data...

Toby Considine: http://www.caddataondemand.com/VisualMenusWrapper.aspx?sess=RC9UZK2FYPO93VE4AXH0

Michelle Raymond: Participants / Data providers:

1) Michelle Raymond, David Coggeshall, Toby Considine, Deborah MacPherson 2) SB30, Dan Farley,

3) connect with the survey standards

a. Learn about survey standards for location (origin point, reference points, relationship between points)

b. Connect with surveyors

4) NIEM has geospatial name code lists

5) NFPA GIS committee - Jim Smally

Michelle Raymond: Note participants were from list at NIST workshop

Michelle Raymond: Additional potential participants: Robert Anderson Rex Brooks David Holmberg Finith Jernigan Kimon Onuma

Michelle Raymond: Alert information can come from many levels - sensor 1, sensor 2, event agreggate service, building information server, PSAP

Michelle Raymond: Each information provider will have an identifier

Michelle Raymond: Some alert infomation providers will have Web Service access and their connection identifier will be made available when appropriate

Michelle Raymond: What additional access can then be retrieved may be policy based

Toby Considine: This leaves out that the *incident* may need the identifier as well

Michelle Raymond: Addition potental partipants: Bob Smith and ?

Rex Brooks: One of the "principles" we're gathering into the Emergency Data Exchange Language-Reference Informaton Model (EDXL-RIM) is that IDs (Identifiers) are almost always composites, e.g. Incident + DateTime + Sender for a particular message.

Michelle Raymond: EDXL also supports that the Incident identifiers can be "pointed-to" in a Distribution Element that aggregates those Incidents into a higher level "newly declared" Incident. Example: multiple alert Incidents declared a Fire at Building 101, Example: burglary at Bldg 101 Incident, bombing in greenspace gazzebo Incident, fire in Bldg 107 - becomes Terrorist Attack at North Campus

Rex Brooks: Yup.

Michelle Raymond: Format of floorplan - A) from building owner (phase I) - PDF B) for interactive computer tool - translate to JPG

Michelle Raymond: issue is scaling

Michelle Raymond: issue is distortion

Michelle Raymond: issue is naming the location of "dots" within the view

Toby Considine: SHould it be based upon the newly defined TinySVG format and a defined subset of the modules

Toby Considine: DIstortion and Scaling may not matter - we are not building the space, we are providing a schematic

Toby Considine: There is also a proposed very light, GBXML-light 3d format derived from IFCs that may arrive as an OASIS TC presently (Rex - I would love to tug on your coat off line)

Rex Brooks: Go ahead. I'll do my best to respond in a timely fashion.

Rex Brooks: I speak AutoCAD, 3DS, GeoVRML and several other dialects.

Toby Considine: AutoDesk has some interest in starting a TC on lightweight 3d modelling. It would be lossy, but that's on purpose, bechause they want it small. It might be close to the subset of NBIMS you can get into and out of Sketch-Up

Toby Considine: <xsd:simpleType name="buildingTypeEnum"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="AutomotiveFacility"/> <xsd:enumeration value="ConventionCenter"/> <xsd:enumeration value="Courthouse"/> <xsd:enumeration value="DiningBarLoungeOrLeisure"/> <xsd:enumeration value="DiningCafeteriaFastFood"/> <xsd:enumeration value="DiningFamily"/> <xsd:enumeration value="Dormitory"/> <xsd:enumeration value="ExerciseCenter"/> <xsd:enumeration value="FireStation"/> <xsd:enumeration value="Gymnasium"/> <xsd:enumeration value="HospitalOrHealthcare"/> <xsd:enumeration value="Hotel"/> <xsd:enumeration value="Library"/> <xsd:enumeration value="Manufacturing"/> <xsd:enumeration value="Motel"/> <xsd:enumeration value="MotionPictureTheatre"/> <xsd:enumeration value="MultiFamily"/> <xsd:enumeration value="Museum"/> <xsd:enumeration value="Office"/> <xsd:enumeration value="ParkingGarage"/> <xsd:enumeration value="Penitentiary"/> <xsd:enumeration value="PerformingArtsTheater"/> <xsd:enumeration value="PoliceStation"/> <xsd:enumeration value="PostOffice"/> <xsd:enumeration value="ReligiousBuilding"/> <xsd:enumeration value="Retail"/> <xsd:enumeration value="SchoolOrUniversity"/> <xsd:enumeration value="SportsArena"/> <xsd:enumeration value="TownHall"/> <xsd:enumeration value="Transportation"/> <xsd:enumeration value="Warehouse"/> <xsd:enumeration value="Workshop"/> </xsd:restriction> </xsd:simpleType>

Toby Considine: <xsd:simpleType name="spaceTypeEnum"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="ActiveStorage"/> <xsd:enumeration value="ActiveStorageHospitalOrHealthcare"/> <xsd:enumeration value="AirOrTrainOrBusBaggageArea"/> <xsd:enumeration value="AirportConcourse"/> <xsd:enumeration value="AtriumEachAdditionalFloor"/> <xsd:enumeration value="AtriumFirstThreeFloors"/> <xsd:enumeration value="AudienceOrSeatingAreaPenitentiary"/> <xsd:enumeration value="AudienceOrSeatingAreaExerciseCenter"/> <xsd:enumeration value="AudienceOrSeatingAreaGymnasium"/> <xsd:enumeration value="AudienceOrSeatingAreaSportsArena"/> <xsd:enumeration value="AudienceOrSeatingAreaConventionCenter"/> <xsd:enumeration value="AudienceOrSeatingAreaMotionPictureTheatre"/> <xsd:enumeration value="AudienceOrSeatingAreaPerformingArtsTheatre"/> <xsd:enumeration value="AudienceOrSeatingAreaReligious"/> <xsd:enumeration value="AudienceOrSeatingAreaPoliceOrFireStations"/> <xsd:enumeration value="AudienceOrSeatingAreaCourtHouse"/> <xsd:enumeration value="AudienceOrSeatingAreaAuditorium"/> <xsd:enumeration value="BankCustomerArea"/> <xsd:enumeration value="BankingActivityAreaOffice"/> <xsd:enumeration value="BarberAndBeautyParlor"/> <xsd:enumeration value="CardFileAndCataloguingLibrary"/> <xsd:enumeration value="ClassroomOrLectureOrTrainingPenitentiary"/> <xsd:enumeration value="ClassroomOrLectureOrTraining"/> <xsd:enumeration value="ComfinementCellsPenitentiary"/> <xsd:enumeration value="ComfinementCellsCourtHouse"/> <xsd:enumeration value="ConferenceMeetingOrMultipurpose"/> <xsd:enumeration value="CorridorOrTransition"/> <xsd:enumeration value="CorridorOrTransitionManufacturingFacility"/> <xsd:enumeration value="CorridorsWithPatientWaitingExamHospitalOrHealthcare"/> <xsd:enumeration value="CourtSportsAreaSportsArena"/> <xsd:enumeration value="CourtroomCourtHouse"/> <xsd:enumeration value="DepartmentStoreSalesAreaRetail"/> <xsd:enumeration value="DetailedManufacturingFacility"/> <xsd:enumeration value="DiningArea"/> <xsd:enumeration value="DiningAreaHotel"/> <xsd:enumeration value="DiningAreaFamilyDining"/> <xsd:enumeration value="DiningAreaLoungeOrLeisureDining"/> <xsd:enumeration value="DiningAreaMotel"/> <xsd:enumeration value="DiningAreaTransportation"/> <xsd:enumeration value="DiningAreaPenitentiary"/> <xsd:enumeration value="DiningAreaCivilServices"/> <xsd:enumeration value="DormitoryBedroom"/> <xsd:enumeration value="DormitoryStudyHall"/> <xsd:enumeration value="DressingOrLockerOrFittingRoomGymnasium"/> <xsd:enumeration value="DressingOrLockerOrFittingRoomCourtHouse"/> <xsd:enumeration value="DressingOrLockerOrFittingRoomPerformingArtsTheatre"/> <xsd:enumeration value="DressingOrLockerOrFittingRoomAuditorium"/> <xsd:enumeration value="DressingOrLockerOrFittingRoomExerciseCenter"/> <xsd:enumeration value="ElectricalOrMechanical"/> <xsd:enumeration value="ElevatorLobbies"/> <xsd:enumeration value="EmergencyHospitalOrHealthcare"/> <xsd:enumeration value="EquipmentRoomManufacturingFacility"/> <xsd:enumeration value="ExamOrTreatmentHospitalOrHealthcare"/> <xsd:enumeration value="ExcerciseAreaExerciseCenter"/> <xsd:enumeration value="ExcerciseAreaGymnasium"/> <xsd:enumeration value="ExhibitSpaceConventionCenter"/> <xsd:enumeration value="FellowshipHallReligiousBuildings"/> <xsd:enumeration value="FineMaterialWarehouse"/> <xsd:enumeration value="FineMerchandiseSalesAreaRetail"/> <xsd:enumeration value="FireStationEngineRoomPoliceOrFireStation"/> <xsd:enumeration value="FoodPreparation"/> <xsd:enumeration value="GarageServiceOrRepairAutomotiveFacility"/> <xsd:enumeration value="GeneralHighBayManufacturingFacility"/> <xsd:enumeration value="GeneralLowBayManufacturingFacility"/> <xsd:enumeration value="GeneralExhibitionMuseum"/> <xsd:enumeration value="HospitalNurseryHospitalOrHealthcare"/> <xsd:enumeration value="HospitalOrMedicalSuppliesHospitalOrHealthcare"/> <xsd:enumeration value="HospitalOrRadiologyHospitalOrHealthcare"/> <xsd:enumeration value="HotelOrConferenceCenterConferenceOrMeeting"/> <xsd:enumeration value="InactiveStorage"/> <xsd:enumeration value="JudgesChambersCourtHouse"/> <xsd:enumeration value="LaboratoryOffice"/> <xsd:enumeration value="LaundryIroningAndSorting"/> <xsd:enumeration value="LaundryWashingHospitalOrHealthcare"/> <xsd:enumeration value="LibraryAudioVisualLibraryAudioVisual"/> <xsd:enumeration value="LivingQuartersDormitory"/> <xsd:enumeration value="LivingQuartersMotel"/> <xsd:enumeration value="LivingQuartersHotel"/> <xsd:enumeration value="Lobby"/> <xsd:enumeration value="LobbyReligiousBuildings"/> <xsd:enumeration value="LobbyMotionPictureTheatre"/> <xsd:enumeration value="LobbyAuditorium"/> <xsd:enumeration value="LobbyPerformingArtsTheatre"/> <xsd:enumeration value="LobbyPostOffice"/> <xsd:enumeration value="LobbyHotel"/> <xsd:enumeration value="LoungeOrRecreation"/> <xsd:enumeration value="MallConcourseSalesAreaRetail"/> <xsd:enumeration value="MassMerchandisingSalesAreaRetail"/> <xsd:enumeration value="MediumOrBulkyMaterialWarehouse"/> <xsd:enumeration value="MerchandisingSalesAreaRetail"/> <xsd:enumeration value="MuseumAndGalleryStorage"/> <xsd:enumeration value="NurseStationHospitalOrHealthcare"/> <xsd:enumeration value="OfficeEnclosed"/> <xsd:enumeration value="OfficeOpenPlan"/> <xsd:enumeration value="OfficeCommonActivityAreasInactiveStorage"/> <xsd:enumeration value="OperatingRoomHospitalOrHealthcare"/> <xsd:enumeration value="OtherTelevisedPlayingAreaSportsArena"/> <xsd:enumeration value="ParkingAreaAttendantOnlyParkingGarage"/> <xsd:enumeration value="ParkingAreaPedestrianParkingGarage"/> <xsd:enumeration value="PatientRoomHospitalOrHealthcare"/> <xsd:enumeration value="PersonalServicesSalesAreaRetail"/> <xsd:enumeration value="PharmacyHospitalOrHealthcare"/> <xsd:enumeration value="PhysicalTherapyHospitalOrHealthcare"/> <xsd:enumeration value="PlayingAreaGymnasium"/> <xsd:enumeration value="PoliceStationLaboratoryPoliceOrFireStations"/> <xsd:enumeration value="PublicAndStaffLoungeHospitalOrHealthcare"/> <xsd:enumeration value="ReadingAreaLibrary"/> <xsd:enumeration value="ReceptionOrWaitingTransportation"/> <xsd:enumeration value="ReceptionOrWaitingMotel"/> <xsd:enumeration value="ReceptionOrWaitingHotel"/> <xsd:enumeration value="RecoveryHospitalOrHealthcare"/> <xsd:enumeration value="RestorationMuseum"/> <xsd:enumeration value="Restrooms"/> <xsd:enumeration value="RingSportsAreaSportsArena"/> <xsd:enumeration value="SleepingQuartersPoliceOrFireStation"/> <xsd:enumeration value="SortingAreaPostOffice"/> <xsd:enumeration value="SpecialtyStoreSalesAreaRetail"/> <xsd:enumeration value="StacksLibrary"/> <xsd:enumeration value="StairsInactive"/> <xsd:enumeration value="Stairway"/> <xsd:enumeration value="SupermarketSalesAreaRetail"/> <xsd:enumeration value="TerminalTicketCounterTransportation"/> <xsd:enumeration value="WorkshopWorkshop"/> <xsd:enumeration value="WorshipPulpitChoirReligious"/> </xsd:restriction> </xsd:simpleType>

Rex Brooks: Interesting. We have a way of handling lists in EDXL called a Value List URN for a published, reference-able list accessed or activated by a "keyword" another part of the EDXL-RIM we'll be including.

Toby Considine: The above list is from GBXML, which is an IFC-derived standard used in the energy modelign world. Several CAD programs can export it.

Rex Brooks: Exactly the kind of reference-able ValueListURN we mean.

Toby Considine: I think we can get AutoDesk to bring this to OASIS

Michelle Raymond: Requirements / Considerations

1) Use NBIMS unless there is a stated reason otherwise

2) How do we create a grid that can represent ANY Floorplan for the software vendor to use?

3) What is the geo-reference point for any floor plan? Northeast corner?

4) How do we map a sensors location to this floorplan?

5) How do we label floors? E.g., 1-18=floors, L=lobbies, A=arcades, B=basements, PH=penthouses, P=parking levels

6) Best use of NIMS, IFC, Smartcodes

7) Altitude to floor issue.

Future world where you have a floorplan vs. sensor located in building without benefit of floorplan display.

Rex Brooks: Eliminates the need to get agreement on "master" lists, and lets you use anyone's list.

Toby Considine: AutoDesk bought GeoPraxis who originated GBXML on a CA DOE contract during the "Enron Year"

Rex Brooks: I think it might be better for AutoDesk to take it to the Web3D Consortium, since they're the keeps of the ISO Standard for 3D on the web.

Toby Considine: Michelle - do not forget the traditional re-numbering of rooms

Rex Brooks: keepers, I meant.

Toby Considine: *I* think that there should be standards transforms on a BIM-lite to TinySVG with defined Modules requirements for the desired interactivity ...

AlanVinh: If we have a standard way number/name the floors then when the building owners submit their floorplans, then can use the proper naming convention so that the FR will recognize the floors.

Toby Considine: ANd the use only TInySVG for transmission to the client system

AlanVinh: The sensor has to list what floor it's on - e.g., SmokeDetector on F1 = Floor 1, so bring up "F1" to see that floor.

Toby Considine: How close is the SPatial IFCXML format to anything recoongizabe by the OGC?

Toby Considine: <xsd:simpleType name="surfaceTypeEnum"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="InteriorWall"/> <xsd:enumeration value="ExteriorWall"/> <xsd:enumeration value="Roof"/> <xsd:enumeration value="InteriorFloor"/> <xsd:enumeration value="Shade"/> <xsd:enumeration value="UndergroundWall"/> <xsd:enumeration value="UndergroundSlab"/> <xsd:enumeration value="Ceiling"/> <xsd:enumeration value="Air"/> <xsd:enumeration value="UndergroundCeiling"/> <xsd:enumeration value="RaisedFloor"/> <xsd:enumeration value="SlabOnGrade"/> </xsd:restriction> </xsd:simpleType>

AlanVinh: Sensor msg/CAP should have building's address (recognizable by CSA & NENA), then it's location within that building such as F3 & geolocation. If we have a standard/base floor plan, then when we bring up F3, we can map that sensor's location on to F3.

Rex Brooks: I'm back. Toby, I don't know.

AlanVinh: Deborah - I got on this conference call via e-mail so I'm not on this ontolog "list". Should I be added to your list?

Toby Considine: Alan - Sign up for Ontolog, and then you can be added to the list by (a little help, Peter?)

AlanVinh: Toby - can you give me the link for signing up? Thanks.

AlanVinh: Toby - I signed up with a user ID and PW but it didn't ask for my e-mail addres so how do I get e-mail msgs when people post to the list?

Rex Brooks: Peter, Alan needs to be added to the BSP mailing list.

Rex Brooks: I don't recall if we have an administrator for BSP?

Michelle Raymond: Floorplans for Buiding Information Exchange: BSP "ownership" for workspace. NIST BFRL goals - first deliverable

Peter P. Yim: I am sending Alan the link on how to get that done below ... by the way, Bob at 1talltrees.com, debmacp at gmail.com, michellearaymond at gmail.com, peter.yim at cim3.com, rexb at starbourne.com and Toby.Considine at unc.edu are all list-administrators for [bsp-forum]

AlanVinh: My e-mail is alan.vinh [at] nist.gov

Peter P. Yim: Alan ... to join BSP ... see: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance#nid1DS2

Peter P. Yim: and, ... to join Ontolog, see: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J

Peter P. Yim: now that I have your email address, shall I sign you up for both Ontolog and BSP?

AlanVinh: Peter - please stay behind to help me out with joining the lists. Thanks.

Peter P. Yim: sure ... no problem