Domain Map    (1QDS)

http://ontolog.cim3.net/file/work/BSP/FPML/DomainMap.jpg    (1QDT)

Comments    (1QG7)

Background    (1QET)

Agenda    (1QF1)

Attendees    (1QOK)

Follow-up call will be January 5 at 11 PST / 2 EST Work session call on functional requirements to write up Phase 0 Deborah to send out invitations.    (1QOU)

Meeting Notes    (1QOV)

2008-12-30 Meeting Notes    (1QOW)

Deborah MacPherson Session Chair and submitting notes herein for comment and approval.    (1QOX)

Brief Introductions    (1QOY)

AV = Alan Vinh BS = Bob Smith DC = David Coggeshall DM = Deborah MacPherson KO = Kimon Onuma MR = Michelle Raymond RB = Rex Brooks TC = Toby Considine    (1QOZ)

MR: Clarification:    (1QP0)

- "The Floorplan Project" is an encompassing project. For NIST Building Information Exchange for First Responders    (1QP1)

- "Floorplan Data Exchange" is a specific project (perhaps sub-project of "The Floorplan Project") with the goal of a recommended method of encoding floorplan information with ability to integration information about objects and events into/onto the floorplan.    (1QP2)

- Floorplans are made of concepts. X Y Z and Time are visual representations.    (1QP3)

DC: XY location vs room locations are a difficult area that warrant discussion on its own, for purposes of the the Floorplan Data Exchange project, will defer to room or space number and name (ahead of XYZT location).    (1QP4)

KO: OPS background on how and where we are Believe strongly in SVG, would like to building on the fly from databases to dynamically generate plans Important for the level of detail to be appropriate to the task For instance, can attach simple Excel file to a polygon using the building as an interface. IFC Industry Foundation Classes may include geospatial tags, XYZ location, lat and log information An OPS drawing can be only a conceptual representation at a site with attached files OPS uses their own XML format for export KML files may be static or used as a network link There is not only one way to do anything OPS preference is to keep the building data live and light Other information such as utility lines may appear Rooms may be shapes Equipment lists can open up stating a room has this or that content, not graphically, but using XML like a table to list components Predetermined sets can be established, also one person can monitor or be responsible for the equipment as simply as an Excel table which can then flop out in other databases. Web services are used to accomplish the update Equipment is placed in a room like a delivery truck, may not be in the exact location BIMstorm and OPS can be used to document a LOT of buildings quickly    (1QP5)

AV: NIST BFRL is interested in mapping alerts to floorplans. Need an indicator who/where/what to map to static floorplan    (1QP6)

RB: Interested in an icon library, may be a deliverable and demonstration. For example, set up 5 objects to map and display, define zones (such as sensors or alarms) then place these 5 objects correctly.    (1QP7)

MR: Icons shall comply with NFPA Code 72 Annex    (1QP8)

DM: Build a library with a set of objects, deliver these examples to buildingSMART alliance and others following a similar process to AGCXML. Library, Objects, Mapping Procedures    (1QP9)

TC: Zones are tricky, for example a big box store is like one big room that still has zones, ISO standard is in progress What we need to do is stir together GB-XML, Light BIM's like Kimons and see what we get. The end result needs to be able to be pinned to Google Earth, perhaps using CityGML to hold the objects    (1QPA)

DM: Looking back to the original NIST BFRL Building Emergency Response Scenario, we have covered the building servers, and perhaps higher level servers based on the OGC graphic as context. What we have not talked about yet are the SAP Standard Access Points, Alan can you please clarify.    (1QPB)

AV: The only role of the PSAP is to recognize message type, and confirm who can talk through this portal. NIST has a number of security personnel to consult with. What is important is being able to cross into all SAP. Not for validation, only type CAP, NIM, BIM, the Standard Access Point is only a gateway for messages to go through.    (1QPC)

DC: Focusing on the prototype. Main priority is the display format - compatible and interoperable with Onuma Planning System and others The first phase is to do this and establish the steps to go through to see where information rightfully belongs. A well formed proposal will be developed from here to be written up and reviewed by the group. The short term plan is Phase 1 approximately 1 year, approximately $120,000 Phase 0 can be accomplished for $15,000 to $20,000. The first step is defining the Functional Requirements during January and February A robust plan will follow and take Phase 1 to complete over the rest of the year.    (1QPD)

DM: Initiated vote in chat room, direction for project phases 0 and 1 were approved.    (1QPE)

DC: The aim is to complete 3 to 4 pilot studies over the 1st year. Case studies of multiple buildings with lots of floors and rooms to prove the system is scalable Putting into IFC may be related to vagaries of the market, the purpose is an open system For example there could be 7 levels of compliance for old buildings, new buildings We will deliver a set of recommendations anyone can base their software rules on The task at hand is to prove the concept of a lightweight floorplan browser The fire department is the first user group, it has to work and be easy to use to change or integrate into existing process The system needs to be able to work in standalone formats, working unconnected with the building servers or 9-1-1 servers but it must coordinate with other systems, probably through XML 10-20 organizations may be approached with this plan in writing seeking Phase 0 and 1 funding DHS, NSF, Corporations and others may be approached with the completed test case    (1QPF)

DM: Alan, what is the wish list of NIST BFRL particularly the scenario and intended follow up workshop results?    (1QPG)

AV: The floorplans need to be converted from any format into one format, then converted again in a standardized formats. There is no typical mixture of existing floor plans, they may be hand drawn, there may be none at all. We need to get to a point like PDF that anyone can read, then translate into XML with georeferences to attach a single room.    (1QPH)

KO: This was the task for the San Francisco Shelter Database    (1QPI)

RB: Some of this can be automated and some cannot. "Here is a list of spaces, swap this out with live data".    (1QPJ)

DC: There is no silver bullet that can automate the entire process, there is a large manual component.    (1QPK)

RB: But the point is to automate as much as possible to accelerate the process and then to deploy in general.    (1QPL)

DC: The floorplans are not built directly, they follow rules for some level of a model that can be updated and revised. The network and system derives to publish as a standalone SVG.    (1QPM)

DC: Need to complete the following over the next few days or week: Input references, gather wish lists, define the nominal or minimal tasks.    (1QPN)

DC: The proof of concept must: be a format, be easy to provide, easy for fire departments to incorporate, and effective to update.    (1QPO)

MR: Other important aspect to define are scoping, integration and the timeline.    (1QPP)

DC: Toby and Kimon are you willing to serve as subject matter expert consultants?    (1QPQ)

TC: Yes, this is a good part of larger projects.    (1QPR)

KO: Yes, glad to see this focused starting point. Would be good to define the overall scheme, workflow and different outputs such as IFC's and other data    (1QPS)

Closing remarks were made by all.    (1QPT)

David Coggeshall, BobSmith, and DeborahMacPherson to take the lead in Phases 0 and 1. Follow up conference call next Monday 2 pm EST / 11 am PST. DM to send invitations.    (1QPU)

Future Work    (1QFY)

Conference Call Details:    (1QCU)

Chat Room Copy/Paste    (1QPV)

DeborahMacPherson: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance/ConferenceCall_2008_12_30    (1QHR)

anonymous morphed into RexBrooks    (1QHS)

toby: Flor Plan Data Exchange    (1QHT)

RexBrooks: Remember that the header of an XML message will need to contain the metadata necessary to distinguish the building, its location, whehter there is a floorplan or set of floorplans available, and if available, how/where to get that, or access it from an existing disconnected or offline database.    (1QHU)

toby: Commercial retailers may have one big room but numerous fire-sensitive zones    (1QHV)

RexBrooks: So one requirement would be that a floorplan must have a defined minimum set of metadata.    (1QHW)

toby: Light BIM? AutoDesk wants an ISO "light BIM" that is 3D capable. Specifically not REVIT....    (1QHX)

toby: SVG and Cell Phones and supported "Profiles"    (1QHY)

MichelleRaymond: Clarification: (Potentially under BSP, et. al.) - "The Floorplan Project" is an encompassing project. (For NIST Building Information Exchange for First Responders) - "Floorplan Data Exchange" is a specific project (perhaps sub-project of "The Floorplan Project") with the goal of a recommended method of encoding floorplan information with ability to integration information about objects and events into/onto the floorplan.    (1QHZ)

toby: Cataloguing of "Items of Interest" varies from jurisdiction to jurisdiction    (1QI0)

RexBrooks: Listening to Kimon, I'm struck with another requirement: that a floorplan needs to have metadata for the range from lightweight to intensive information density. Also, his system cries out for an active internet connection to a central Emergency Operations Center database of current building information for the locality, e.g. town, district, facility, etc.    (1QI1)

MichelleRaymond: Note: The Floorplan Data Exchange Project charter is to be submitted next week to NIST.    (1QI2)

toby: It goes past that. Sensr data may be managed by 2rd parties who are *not* in the building. Query point for live rpocess data may be external to building point.    (1QI3)

RexBrooks: Jurisdictions will need to be educated that they need to building, assemble and maintain this responder database alongside or in conjunction with city planning departments.    (1QI4)

RexBrooks: Okay, noted. Good to know. Management companies need to have their insurance carriers be responsible for ensuring such maintenance information is kept up to date.    (1QI5)

toby: (see not about commercial above - reason my hand is up)    (1QI6)

DeborahMacPherson: Need to talk about documenting A LOT of buildings and the prototype strategy    (1QI7)

toby: Sort of relevant, got this link by email just now    (1QI8)

DeborahMacPherson: and light bim above    (1QI9)

toby: http://www.automatedbuildings.com/news/jan09/articles/openlynx/081229032033openlynx.htm    (1QIA)

toby: Or standard SVG icon library, pforward cached, to be displayed if queried....    (1QIB)

DeborahMacPherson: that a floorplan needs to have metadata for the range from lightweight to intensive information density    (1QIC)

toby: This model handles diversity of information density, from poorly documented legacy to high density high value current building    (1QID)

DeborahMacPherson: active internet connection to a central Emergency Operations Center AND the static floorplans do encompass most of the NIST scenario steps....except the standard access point    (1QIE)

RexBrooks: That was my point, Deb.    (1QIF)

RexBrooks: We have an education task, as well.    (1QIG)

RexBrooks: We need to let fire departments know that this framework doesn't have to be intensive, and can provide them value from a small investment. Once they've experienced it helping they will want more.    (1QIH)

toby: Deb: Propses some sort of library for a limited set of things    (1QII)

I can imagine a cetral planning office running OPS for the city to support ER. I can also imagine each building sharings its floorplans only on demand. I can also iamgine forward caching of all floorplan data    (1QIJ)

DeborahMacPherson: Library for limited number of things    (1QIK)

toby: XML rendering meets al of those scenarios.    (1QIL)

MichelleRaymond: (note for NIST charter): information representation format is technology agnostic. security methods is situation appropriate.    (1QIM)

RexBrooks: agreed, that's a good idea of how it might progress.    (1QIN)

DeborahMacPherson: central planning office running ops for city to support ER first then sustainable after    (1QIO)

RexBrooks: yup.    (1QIP)

toby: Just described that all communications are messaging based, not API based    (1QIQ)

toby: Is there a need to archive all instances of certain classes of messages    (1QIR)

toby: One page may get data sources from numerous distributed points...    (1QIS)

toby: Floorplan from (building, centeral repository, alarm receiver, fire station)    (1QIT)

toby: Op/Sensor data from (building,3rd party M&O&Analytics)    (1QIU)

toby: Purpose/Use info from enterpise system for CRM/sales/inventory...    (1QIV)

AlanVinh: Some tasks to consider:    (1QIW)

AlanVinh: 1) Requirements analysis to understand the components required on a floorplan for an emergency fire scenario (sensor, standpipes, etc.)    (1QIX)

AlanVinh: 2) Develop a standardized mechanism for representing any buildings floorplan (a.k.a., a standardized floorplan)    (1QIY)

AlanVinh: 3) Develop a mechanism for converting printed drawings, jpegs or pdf files into the standardized floorplan from item 2 above    (1QIZ)

AlanVinh: 4) Develop a standard means of mapping building objects such as standpipes and sensor locations to the standardized floorplan (from item 2 above)    (1QJ0)

AlanVinh: 5) Evaluate and demonstrate using various software techniques and graphical engines such as SVG and Flash to present the standardized floorplan (from item 2 above)    (1QJ1)

AlanVinh: 6) Demonstrate by displaying multiple sensor locations on a standardized floorplan    (1QJ2)

AlanVinh: 7) Floorplan must be lightweight and stand alone    (1QJ3)

DeborahMacPherson initiated a vote - please click the Vote button to cast your ballot take on project (1) Yes (2) No This is a multiple-choice vote.    (1QJ4)

RexBrooks: 1    (1QJ5)

RexBrooks voted for: 1(Yes) (submitted by: RexBrooks)    (1QJ6)

AlanVinh voted for: 1(Yes)    (1QJ7)

MichelleRaymond voted for: 1(Yes) (submitted by: MichelleRaymond)    (1QJ8)

toby voted for: 1(Yes)    (1QJ9)

anonymous voted for: 1(Yes)    (1QJA)

anonymous morphed into Bob    (1QJB)

Bob: David, Rex, Kimon, and Alan have all expressed some workflow ideals and FAILPOINTs to describe and resolve...What are some good ways or tools to describe these workflow and failpoints?    (1QJC)

AlanVinh: NIST is asking the "leads" to give status on their respective research areas by the end of January and a document describing the solution(s) or continuing research being done by the end July of 2009.    (1QJD)

toby: say, examples from other domains?    (1QJE)

toby: Sorry - lot an line thre---"What do these reports look like    (1QJF)