search

ladybug-tools / spider-gbxml-tools

Scripts to help you view and manage gbXML files
https://www.ladybug.tools/spider-gbxml-tools/
MIT License
14 stars 3 forks source link

Implement methods for embedded use #2

Closed macumber closed 5 years ago

macumber commented 6 years ago

When running the gbxml viewer in another web app need an API that can be used to interact with it. Suggested API methods:

theo-armour commented 6 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:

theo-armour commented 6 years ago

@macumber

The fixes mentioned below are in the new develpment branch here:

gbXMLViewer Basic R5

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

macumber commented 6 years ago

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.

theo-armour commented 6 years ago

@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.

macumber commented 6 years ago

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!

theo-armour commented 6 years ago

@macumber @ladybug-tools/spiders

Your message

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.

Invites

Dan: you have been invited to the 'Spiders' GitHub Team and I have responded to your Doodle request for a meetup time.

Releases

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.

Code name for the gbXML Viewer Basic

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?

mdengusiak commented 5 years ago

awaiting contributor with Node.Js experience