The property-set and property extraction sites had the identical
first-paragraph truncation: descriptions ending at a colon lost their
bulleted lists and follow-up paragraphs. Route all four sites (IFC2X3 +
IFC4, pset-level and property-level including recursive children) through
extract_full_description, and make the existing HISTORY: changelog split
case-insensitive, since 21 pset docs use "History:" which only becomes
reachable once the walk passes the first paragraph.
Data refreshed from the same local buildingSMART doc sources with the
merge-only-description discipline: IFC4 376 descriptions completed
(34 pset + 342 property/child), IFC2X3 147 (20 + 127), zero artifact
regressions, all other fields byte-identical.
Example: Pset_DamperOccurrence.SizingMethod previously ended at
"...nominally or with exact measurements:" and now includes
"NOMINAL: Nominal sizing method. EXACT: Exact sizing method."
Generated with the assistance of an AI coding tool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Three IFC2X3 type descriptions leaked HISTORY remark text that is not
wrapped in a blockquote in the source markdown: a literal "> HISTORY ..."
tail inside the definition paragraph (IfcEnergyMeasure,
IfcHeatFluxDensityMeasure) and an inline "HISTORY: ..." sentence
(IfcMetricValueSelect). Teach extract_full_description to skip leading
HISTORY paragraphs and cut at inline/lazy remark markers, and clean the
three affected data entries (all other descriptions unchanged).
Generated with the assistance of an AI coding tool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
get_entity_doc returned incomplete descriptions for many entities and
types, e.g. IFC4 IfcAlarmType ended mid-sentence at "The set of shared
information may include:". The DocExtractor took only the FIRST <p> of the
markdown-derived HTML (BeautifulSoup .find("p").text), silently dropping
any bulleted list embedded in the definition and every paragraph after it.
Add DocExtractor.extract_full_description, which walks all top-level
<p>/<ul>/<ol> elements in document order (list items rendered as "- item"),
stops before any <blockquote> (HISTORY/NOTE remarks), and strips inline
kramdown attribute markers. The four entity/type extraction sites now use
it; the property-set extraction sites are left untouched to keep this
change scoped.
The shipped schema JSON data is refreshed from the buildingSMART IFC doc
sources (IFC4.0.2.1 and Ifc2.3.0.1): 1491 entity/type descriptions are
completed. Only top-level description fields change; attribute
descriptions and all other fields are byte-identical to the previous data,
and 11 regenerated descriptions containing extraction artifacts were kept
at their previous text.
Verified: IfcAlarmType now includes the full "may include" list and the
closing paragraph; IfcBeamType, IfcWindow and IFC2X3 IfcWallStandardCase
spot-checked complete with no HISTORY leakage.
Generated with the assistance of an AI coding tool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
API for docs works the same way as it worked for ifc2x3 and ifc4.
Besides changing `doc.py` and adding `.json` schemas added `ifc4x3dev_scrape_data_for_docs.py` (it's kind of hacky now and relies on `server.py` code from the further mentioned repo) that's used to parse some entities descriptions from https://github.com/buildingSMART/IFC4.3.x-development for later use in `doc.py`.
Types schema located in separate json file, it's structure:
{ ifc_type_name: {"description": type_description, "spec_url": type_spec_url} }
I've also added new API function to get type data - `get_type_doc(version, ifc_type)`
Added information about parent entity to schema (it's located in "parent_entity" entity parameter inside schema), both for Ifc2x3 and Ifc4.
Modified get_entity_doc and get_attribute_doc - now you can use additional optional parameter `recursive=True` with those functions - then parent entities attributes will be included to the list of entity's attributes. For example IfcWindow will also have attributes from IfcBuildingElement, IfcElement, IfcProduct etc...
Now you can access Doc API functions directly (like `ifcopenshell.util.doc.get_entity_doc(...)`) without setting up DocAPI class.
To make it work I've set up singleton DocDatabase class and made all paths relative to module location.
The schema for IFC4 the same as it was for IFC2x3.
Properties schema for IFC4 includes both quantity and propety sets.
Also cleaned up entities description for IFC2x3 from HTML code and IFC tags.
* IFC v2.3 json schema and parsing tool to regenerate it
Added entities and propeties schema in json format.
ifc2x3_entities.json format:
entity_name -> description, url, attributes;
attributes format: attribute_name -> attribute_descrption
ifc2x3_properties.json format:
property_set_name -> property_name -> description, children
children format: child_property_name -> child_property_description.
Also added doc.py script that can generate the same json schema files but requires docs IFC 2.3 docs in the same folder (https://github.com/buildingSMART/IFC/tree/Ifc2.3.0.1)
* Moved all json schema files to /util/schema
* Moved json files back to /util/, changed doc.py export location
* Added specification urls for entities and properties
Added specification urls for entities and properties.
Also added a function to parse actual property sets domain from the website to generate specification urls (domain on website and on github do not match).
Schema structure was changed:
ifc2x3_entities.json format:
entity_name -> description, spec_url, attributes;
attributes format: attribute_name -> attribute_descrption
ifc2x3_properties.json format:
property_set_name -> properties, spec_url
properties format: property_name -> description, children_properties
children_properties format: child_property_name -> child_property_description.
ifc2x3_property_sets_domains.json format:
property_set_name -> ifc_domain
Petru Conduraru