BSP Subcommittee on Floor Plan Data Exchage    (1QV8)

Attendees    (1QXI)

Regrets    (1QWU)

Notes    (1QXJ)

Michelle - part of larger project    (1QXS)

David - today is the bare minimum, others built on top as infrastructure Ready by the 12th, the plan including cover letter for BSP approval to set context, this is a small core project in a much larger multi-faceted project including security and interoperability    (1QXM)

Bob - all should be represented in the updated Domain map, core starting activity with 4 parts, then additional related projects that extend beyond the core, other items on Alan's plan. Need to show some time and deliverables.    (1QXN)

Michelle - in regards to overarching responsibility - lets go through this process, what is beneficial in both directions and will bring forward items as needed.    (1QXO)

Alan - 4 agenda items on that document - placement of project in larger context of Michelles floorplan area and even larger context of project leaders.    (1QXP)

David - being clear to understand only the floorplan browser    (1QXQ)

Alan - then is related to what SB30 might become, ties into Michelles system, need both for the system to work    (1QXR)

David - SME are lots of floorplans, Rex is standards and consulting reviewer especially EDXL. Will work for Kimon and Toby's feedback.    (1QXT)

Alan - Security is separate, then the current statement is focused, will add clear statement this is only about the floorplans.    (1QXU)

David - DHS may be related to full Phase 1 work later, we want to prepare a general purpose document to flesh out in 60 to 90 days to present to potential funders to incorporate in final    (1QXV)

Alan - The end of Sept / Oct budgets are planned, another proposal is in January, do not know their turn around time. NIST will be asking for this one piece.    (1QXW)

David - will be providing a document next week, track record, larger team, setting context of the need for this etc. Need consensus on these requirements first. Larger bracketing document will be around this - Project Prospectus - Phase 0. Will fill out an outline to present. Currently a 12 item outline, the Functional Requirements is first four. 5 to 12 will be just in outline form, subject of planning period along with the demo.    (1QXX)

Alan - this all makes sense, we should move forward. Will keep updated about what everyone wants.    (1QXY)

David - will provide what you need for your proposal will also go out to engage other potential funders. Writing to be unsolicited proposal to virtually anyone.    (1QXZ)

Bob - is 12th too early David - no the DHS schedule is separate (portions of the discussion not recorded)    (1QY0)

Round Robin - focusing on glaring errors or missing elements    (1QY1)

Modular, standards based, standalone capabilities    (1QY2)

Can be put in service by larger applications    (1QY3)

Ability to provide UI for viewing, navigating, manipulating    (1QY4)

Can present data    (1QY5)

Either put in service or incorporate from background    (1QY6)

Michelle - the one thing we included from NIST is to show tie in to the Industry Foundation Classes    (1QY7)

David - there are 2 versions, publishing standalone SVG like a user client but its not the factory that makes it. On the factory side, see end of 3rd page for format construction model capable of exporting and changes to the model, once implemented press a new standalone version and publish it. There are several options, right in the CAD system or build an auxilliary function. In that construction model is the IFC    (1QY8)

Michelle - may have an out of date document, looking for the word publish.    (1QY9)

David - has to be a model like OPS, Vectorworks, where floorplans get registered and conform, then publish the SVG small lightweigh.    (1QYA)

Michelle - yes for the NIST workshop portion, that translation point and ability to get back through to IFC needs to be supported. Is an adjunct activity.    (1QYB)

David - that is right. See item E. Expect to have floorplans in 5 different conditions - no plans to advanced CAD    (1QYC)

Deb - still need to mention the open standards then, open broad and vague but needs to include this key objective    (1QYH)

Alan - agree with Deb and Michelle, whatever represents this floorplan needs to be neutral    (1QYI)

Michelle - do think SVG is neutral using a standard and is appropriate to get the information and port it. Clarifying that we do need to have an appropriate IFC model. That will fall under michelles larger piece. David's is floorplan representation    (1QYJ)

Alan - do you think is technically ok for Kimon or any other company to take this and use?    (1QYK)

Michelle - yes    (1QYL)

Alan - can convert and display whatever via XML, and keeping things neutral for everyone involved    (1QYM)

Michelle - Honeywell won't do SB30 for example but they can go to the IFC for example    (1QYN)

David - clarify SVG, is an XML specifically to represent vectors etc. What he's doing is at a native level to add Java script without a plug in    (1QYO)

Alan - that all might be too much information at this level, can be implemented this way for now, but overall...    (1QYP)

David - that is the difference between your letter and the Functional Reqs 4 page document. "This is the way I would do this"    (1QYQ)

SVG is a data format for representing graphic object structures, that is the way you transport the data, it can be manipulated with many techniques with all of the geometry and all of the data to display and animate without a plug in. Thats a no cost approach, FLASH and others will let others be built in addition to this. Entry level capability built on standards, SVG and Javascript are the only ones that are 100 percent pure play capability to build on by vendors or custom programmers    (1QYR)

Michelle - this proves the underlying model can be extracted and presented    (1QYS)

David - Kimons client side browser could be more than the bare bones    (1QYT)

Alan - where you're heading is very good    (1QYU)

Michelle - this is a showcase, not the Floorplan project - call the Floorplan Display Project {nid 1QYV} Getting the other objects, naming conventions, this will show can be done    (1QYW)

David - also tightly coupled is display of sensor information, using static background    (1QYX)

Michelle - information integration includes the sensor data    (1QYY)

David - Standalone reference, some level of messaging and connection    (1QYZ)

Alan - in your model can you map to your floorplan?    (1QZ0)

David - absolutely, easy to map sensor data once it comes to us - that is exactly where the project line is. Ready to show the sprinkler zone or the room, or any other element, including the location but not the state of the sensor. Sensor status and messages are not part of this scope.    (1QZ1)

Deb - add this to the founding document and domain map    (1QZ2)

Alan - need to version number the document, page 1 composition vector objects and safety elements, that page is not included but it will be for this page to be complete.    (1QZ3)

David - things like stairwells, standpipes, that is a detailed aspect not included in this document but working on it.    (1QZ4)

Alan - see page 2 to clarify what is real time data    (1QZ5)

David - not mapping the sensor but mapping the sensor alert, sensor itself already mapped as part of the reference project. That is an alert which is the integration project    (1QZ6)

Alan - make it red or put an icon on it?    (1QZ7)

David - yes, just like you click on a room for hazardous materials, but the browser can query back to the webservice or RSS to get a small pack of information. In that same way , the room polygons can be connected    (1QZ8)

Alan - also on the harddrive    (1QZ9)

David - vision of this software is you get that folder, drag onto an SVG enabled browser, drop into your host to overlay the live data, access through web protocols or move into your department, or go to the internet at its reference points - can play from anywhere    (1QZA)

Alan - how do you propose a location, how do you know it maps in real time? example part of floorplan x, this alert came to me in this status, its location is y, belongs to floorplan x - how can you identify    (1QZB)

David - agreement on sensor identification    (1QZD)

Alan - how do you know?    (1QZE)

Michelle - you actually don't care, there are 2 representations, the pixel location is not important, however that is, the encoding includes this    (1QZF)

Alan - maybe not terms xy, mean bldg 101, why sensor 103? How do I know that belongs there?    (1QZG)

David - the full identifier includes site, building, and floor. Sensor instantiation places in building context. All the spaces appropriately identified are a jigsaw puzzle that fit together.    (1QZI)

Alan - a string to represent this item with coordinates    (1QZJ)

David - both xy and coordinator    (1QZK)

Alan - not a square building and some coordinate system?    (1QZL)

David - is the pixel bounding box on the plan, when I say pixel coordinate, I mean the display rectangle (Deb not the shape of the buiding)    (1QZM)

Alan - how about North, South, East, West    (1QZN)

David - drawings themselves, project north to inform ABCD nomenclature. What polygon is this inside of? Both a logical location and xy location. Can only get polygon locations if the polygons have been drawn. Full envelop of the building, then overlapping sprinklers. Its polygonal geometry, have everything needed    (1QZQ)

Alan - comfortable?    (1QZR)

Michelle - stated differently "In which space do I live?" sometimes thats all you need. Then the particulars in larger world, in that space or another context. The coordinate system is based off of the context you are working with. It may be a geocode, it may be xy pixel, there are several options. We would problably never send an xy in an alert message without sending the context of what that location is related to    (1QZS)

David - also the pixel bounding box can be correlated to georeference, they can fit this schema    (1QZT)

-Deb paused in notes-    (1QZU)

Michelle - naming and classification of space    (1QZV)

David - OmniClass etc those are attributes, space naming conventions is room number or name that is by the client    (1QZW)

Deb - that is exactly part of this work    (1QZX)

David - cannot mandate owner nomenclature for the number on the door, that is the user id which can be further classified by spaces by functions etc, they are attributes and types, the name of the room is the only one that says 103 on the door. We have to go in and adopt whatever system is in use. Hallways are identified, a fully enumerated space covers the entire floorplate without overlap    (1QZY)

Alan - all these pieces have names and are understood - hallway a b c at NIST for another example, if they are 1 2 3 some where else    (1QZZ)

Deb - this is taking the next step further, owner can call whatever they want, the classification is underlying what the building itself is called - it does not matter this is what puts them in the middle of the screen.    (1R00)

Michelle - this is the data about the space, where it goes is from the unique identifier    (1R01)

David - will add to that 6,000 rooms and totally adopted their system and found duplications and omissions, their system indigenous to their site, needed room number, whether on the doors or not, should appear in floorplan. May not be contiguous    (1R02)

Un numbered spaces?    (1R03)

Quality control with the owner. It at least needs a unique number and name    (1R04)

Michelle - there are more problems, 107 in one conventions, 12A_ in another, and something else in another set. Even more blueprints, found 5 conventions in one building    (1R05)

David - this consistent system to interface to outside world for public safety    (1R06)

Michelle - even our own internal space    (1R07)

David - this is the format preparation guidelines, conformed convention that generates and registers the polygons, price of doing business, can use their numbers and names as long as unique, its just an alphanumeric string.    (1R08)

Alan - keep in mind firefighters need Floor 1    (1R0F)

Toby - most traffic side, uphill side, point is to consistently communicate    (1R0G)

Alan - consistent way to get to the same part of a floorplan    (1R0H)

David - not typing, more point and click    (1R0I)

Alan - need to know where they are first - in the lobby back of floor 2    (1R0J)

David - nothing will eliminate everything, responded to by fire departments approved as a pre-plan, caught in normal inspection process    (1R0K)

Deb - those are future work to have underlying connections    (1R0L)

Michelle - firefighters would appreciate a standard, and that is not realistic, all we can do is bring about recommendation of naming, all we can do is recommend    (1R0M)

Alan - for future buildings call these these things, for what we have now, use what you have    (1R0N)

Michelle explains some situations where a Section would work    (1R0P)

Deb - not getting to perfect    (1R0Q)

Toby - step closer is a good thing, taking on the worst problems, standardized floorplans move us closer to standardized models    (1R0R)

David - Toby and Kimon most experienced and hands on with facility issues, do you have specific comments or glaring omissions or additions, still keeping slim    (1R0S)

Toby - some are ambitious, the casual reader won't realize which are the hardest things, getting something done, getting some momentum to getting this done. If I have comments will share with groups, I'd have naming groups but don't want to say on the front because its confusion. There's classes of SVG objects for example, maybe best not to mention    (1R0T)

David - yes the 60 to 90 days will go into much more detail    (1R0U)

Strategic approach -    (1R0V)

Toby, leaning on CSS as well to lean on, that is the only quibble not mentioned    (1R0W)

David - solves problem with all these different attributes    (1R0X)

Michelle - CSS cascading style sheets?    (1R0Y)

Toby - all the behavoirs can be done by style sheets, not just a room but a room filled with smoke, a behavoir to repurpose the data. The problem is not a one-off sample but scale to all buildings in north america. Place related, fire related, models that support that let people scale out and prepare. Having the clean separation early between spatial representation is going to be good and move forward    (1R0Z)

David - user interface considerations, thats one of the ways to repurpose the content appropriate to the delivery medium    (1R10)

Michelle - just worried yet another CSS    (1R11)

Instead of floorplan calling the building plan, another under that is exchange, working closely under the same umbrella, that is what OOR is also doing    (1R14)

This document geared specifically toward an open display model, Michelle also will put out related work with the ontology focus, space naming will tie into much more. Where all 3 overlap we aren't working in isolation, working from same core model. Not coming up with multiple versions of the same thing, whole point of bringing together under Ontolog as a work space for the open components is to make sure collaborating.    (1R15)

Deb - getting the open components ready to be open    (1R16)

Michelle - live within BSP and Ontolog and OOR space, because of that can look at what else is going on with other efforts for best practices. Would also like to see in 6 months from now sign up for a Thursday spot.    (1R17)

Deb - underlying will be hidden, solid model    (1R18)

Michelle = show it can be used.    (1R19)

Deb - anyone else have anything to add, have gone through the agenda    (1R1A)

David - reaffirm request for letter, responding to need perceived by NIST and helpful to the NIST agenda    (1R1B)

Alan - group returns on Wednesday    (1R1C)

David- Deb, Bob will keep going, coordinate with Michelle, look forward to Toby comments, will put together 12 to 14 page for 3 months activity    (1R1D)

tune up with today's input. Watch your email and do it quickly so we can keep moving.    (1R1E)

Michelle has a few comments put in and will send    (1R1F)

Skinny version to vote on    (1R1G)

Deborah will send final skinny version to vote.    (1R1H)

Alan - Want to get comments from Rex and Kimon also    (1R1I)

Deb - thanks - will incorporate    (1R1J)

David, Bob, David - get Michelles comments, then one day later, aiming for Wednesday to reconvene and agree on final, including similar floorplan project functional requirements draft by the end of the month.    (1R1K)

Next Call is on 12th    (1R1L)

Will finalize by Wednesday am and deliver Alan and David Holmberg and Jason Averill, to have as a meeting item.    (1R1M)