Closed macumber closed 5 years ago
@macumber
I will add string to XML in the next release of the basic viewer
https://developer.mozilla.org/en-US/docs/Web/API/DOMParser
you can parse XML from a string using the parseFromString() method:
@macumber
The fixes mentioned below are in the new develpment branch here:
setGbXml method for setting the gbXML as a string
GBX.parseFileXML( text ): now converts a string to XML
getGbXml method for getting the gbXML as a string (useful if the editor has changed anything)
New function: GBX.getStringFromXml( xml ) returns an XML file converted to a string
Add a new method that can be called to determine if edits have been made.
The official gbXML way is to edit the meta information to the gbXML document itself. See:
http://gbxml.org/schema_doc/6.01/GreenBuildingXML_Ver6.01.html#LinkD1
The full version of gbXML Viewer can appropriate meta data to the document history upon user request. The current functionality is more or less a stub awaiting further refinement.
The full version also enables you to create a 'do these edits' file that can be used over and over again as each now export comes out from the CAD program and this file could be tweaked to include revision data.
So we should revisit this item as, when and where fixing/editing abilities are brought on board
Cool thanks @theo-armour, I think an npm package is very good. I guess we'll have to set something up on our side to build it. I am an equally derp myself so I'll have to see the best way to do this.
@macumber
The Spider goal is to supply Open Studio with gbXML files that just work. I am working with Michal to automate the process of fixing up Revit files for Open Studio. The goal - after an office/job-specific parameters are set up - is to accomplish fixes with a single click.
Currently, we test only as far as getting gbXML data into Open Studio Geometry View without errors. The next step will be to add all the measures and whatever so that we test based on successfully creating full open Studio reports.
The vision is that instead of spending hours fixing broken files, engineers may, heh heh, devote their energies to designing better buildings.
More objectives include:
But I think a really important objective addresses your comment:
I guess we'll have to set something up on our side to build it. I am an equally derp myself so I'll have to see the best way to do this.
The viewer and all it's ancillary scripts are written mostly entry level plain-vanilla JavaScript. The idea is to make the code comfortable for people who are not full-stack JavaScript developers. The code is written for people with extensive domain knowledge or extensive experience in a language that is not JavaScript but who want to see their data online using minor hacks on code they find easy to read and does not take days to set up and learn.
My guess is that you are a really good example of the target audience for what Spider needs to put together. You have both programming skills and domain knowledge. The question is how can we fit a really good gbXML process into both your workflow and/or normal Open Studio workflow with a minimum of disruption and maximum ease.
Anyway, we are here to help. And, thinking out loud, it might be a good thing to talk things over so we can get all our priorities aligned. I'm happy to have a chat via Google Hangouts or phone any time.
Thanks @theo-armour, I'm going to put out an iteration build (2.6.1) this week that includes the embedded spider and gbXML merging functionalities. I'll write by email to set up a google chat so we can walk through it and talk about next steps!
@macumber @ladybug-tools/spiders
I'm going to put out an iteration build (2.6.1) this week that includes the embedded spider and gbXML merging functionalities.
Fingers crossed it all slips in easily. Your Spider friends will be here for help at any time.
Dan: you have been invited to the 'Spiders' GitHub Team and I have responded to your Doodle request for a meetup time.
I will update the dev version to build soon. And I will upgrade to a revision system similar to the ways Three.js handles things as and when I figure out how to do this.
There are getting to a large number of scripts under the 'Spider' name and which is which gets confusing. A while ago Michal and I decided that each family under Spider - eventually - should have it's own code name. 'Aragog' the name of nice spider in Harry Potter was chosen as the name for the big gbXML Viewer.
It seems logical that gbXML Viewer Basic should also have a code name. Much as I Like the idea of naming scripts after fictional characters, it might be better to avoid these in order not to create any trade mark issues. Therefore the logical choice would be to use one of the Latin names of a real spider (genus or species). Here is a list of spider names: https://en.wikipedia.org/wiki/Spider_taxonomy
Dan: would you or your team kindly give us the honor of suggesting a spider code name for this project?
awaiting contributor with Node.Js experience
When running the gbxml viewer in another web app need an API that can be used to interact with it. Suggested API methods: