IFC for LARK – Eksempel brukt i Revit

English translation – Click here

Denne oversikten viser hvordan LARK kan benytte seg av eksisterende programvare og tilpasse den så godt som mulig til LARK sin måte å jobbe med 3D objektbasert modellering. Undertegnede har gjennomført ulike landskapsprosjekter i tidsrommet 2005 til i dag 2012 basert på  Autodesk Revit som 3D modelleringsverktøy for prosjektering, tegningsproduksjon, mengdekontroll, kostnadsoverslag, utsettingsdata osv. Denne oversikten prøver å ta de erfaringer man har fra gjennomførte prosjekter og de LIM objektene som vi nå har kommet frem til i denne rapporten og sette dette i system.

Denne oversikten viser at vi kan klare å levere mye Landskap mot IFC hvis vi nå i første omgang er villig til å forenkle LIM objektene og ser sammenhenger og muligheter i eksisterende programvare som er mer tilpasset for andre fagdisipliner. På lengre sikt bør LIM objekter få sin egen IFC definisjon. Der det i denne oversikten kommer IfcBuildingElementProxy bør man kunne komme frem til egne IFC definisjoner i Norge som vi kan benytte her frem til vi får på plass en internasjonal IFC standard for Landskap.

Ved praktisk bruk av denne oversikten vil det komme frem mange viktige punkter som igjen er bra å ta med inn i et standardiseringsarbeid med tanke på IFC for LARK. Denne oversikten er kun ment som et første utkast basert på egne erfaringer og ønskes supplert av andre med tilsvarende erfaringer.

 

Oversikt over funksjoner i Revit og hvordan de kan tolkes og brukes av LARK for 3D objektbasert modellering.

De viktigste arealer/flatene som LARK bør bruke aktivt i Revit er enten <Toposurface> eller <Floor> hvor <Floor> gir de største fordelene med tanke på objektbasert modellering.

  • <Floor> IfcSlab
  • <Toposurface> IfcBuildingElementProxy

<Floor> i Revit gir store muligheter for LARK. Alle lag som man bruker på dekker, veier, plasser og vegetasjonsfelt kan legges inn i <Floor>. Dermed er det enkelt å ha kontroll på mengder, tykkelser, detaljtegninger osv.. når totaltykkelsen på alle <Floor> til en hver tid er korrekt.

<Floor> har mulighet til å sette høyde på alle ytterkanter eller hjørner men også legge inn punkthøyder eller knekklinjer manuelt.

Når man benytter <Floor> for Landskap bør man ikke benytte <Levels>. Man bør oppretter et nedre nivå som man definerer som Havnivå +/- 0.00. Alle dekker modelleres på dette nivået og «løftes» så opp til riktig høyde over havet. Alle justeringer, og høydepåskrift vil da hele tiden gi høyde over havet (kotehøyde) noe som er viktig når man jobber med landskapsarkitektur.

Høydejustering på <Floor> kan gjøres på flere ulike måter. På detaljnivå bør man kun la <Floor> ligge på Havnivå +/- 0,00 og man løfter flatene ved å bruke funksjonen <Modify Floor> / <Modify Sub Elements>.

Denne måten å sette høyde på <Floor> gir mulighet for å lage dobbelkrumme flater der det er mulig.

Ulempen med å jobbe med <Toposurface> er at det kun er en flate uten tykkelse. Hver gang man gjør en endring på flaten bruker den mye datakraft på å generere flaten på nytt. Jo mer kompleks flaten er jo lenger tid tar dette

<Roof> benyttes ikke av to viktige årsaker. Den ene er at <Roof> alltid forholder seg med fast høyde på bunnen. Hvis man endrer tykkelsen på <Roof> forblir bunnen på samme nivå men toppen endres. For LARK er dette problematisk da høyde på topp er viktigst for å ha kontroll på fall. Den andre årsaken til at <Roof> ikke benyttes er at landskapsobjekter ikke kan <Hostes> (objektet forholder seg høydemessig) til denne flaten.

<Building Pad> er også vanskelig å benytte for Landskap. Den påvirker <Toposurface> og dermed bruker mye datakraft ved små endringer. Den største begrensningen ligger i justering av høyde og skjæringsvinkel mot terreng. <Building Pad> skjærer kun vinkelrett i terrenget. Enten vertikal skjæring eller vertikal fylling. Hvis man ønsker å ha fall på <Building Pad> kan man kun benytte <Slope Arrow>. Både på <Floor> og <Building Pad> har man begrensning til kun å bruke en <Slope Arrow> per flate. Hvis man kunne benyttet flere <Slope Arrow> på lik linje med <Roof> ville det kanskje gitt flere muligheter for å bruke både <Floor> og <Building Pad>.

Kantstein som avslutning på <Floor> benyttes <Slab Edge> eller <Model In-Place>

  • <Slab Edge> IfcBuildingElementProxy

I detaljnivå benyttes <Component>/ <Model In-Place>. Under valg av <Family Category> and <Parameters> velges <Walls>. Ved valg av <Forms> velges <Sweep>. Ved valg av <Sweep> velges <Pick Path> og <Pick 3D Edges>. Grunnen til at man velger dette er fordi <Slab Edge> klarer ikke å generere 3D volum hvis kanten er del av dobbeltkrum flate og buet. Andre ganger klarer ikke funksjonen å koble volumer sammen. For at man skal være helt sikker på å få med seg riktig volum av kantstein hele veien bør man bruke denne funksjonen. Valg av <Walls> er for at man da kan ta ut mengder på lengden av kantstein. Det beste var om <Slab Edge> kunne klare å lage volum også på dobbeltkrumme kanter samtidig som man kunne fått ut antall løpemeter i <Schedules>.

Det fins ingen gode løsninger for kantstein på <Toposurface> direkte i Revit. Da må man over på SiteWorks og LandCAD fra Eagle Point. Distribuert i Norden gjennom Cad-Q.

Alle landskapsobjekter (Component) som benyttes utomhus må kunne <Hostes>til både <Toposurface> og <Floor>. Disse objektene kan enten alltid forholde seg horisontalt eller følge vinkel på overflaten. Fordelen med disse objektene er at de enten kan linkes til en flate eller man kan overstyre og låse objektene til en faste høyder over havet. De objekt <Family´ene> som gjør dette i Revit er:

  • <Furniture> IfcFurniture
  • <Lighting Fixtures> IfcLightFixtureType
  • <Parking> IfcBuildingElementProxy
  • <Planting> IfcBuildingElementProxy
  • <Plumbing Fixtures> IfcFlowTerminal
  • <Site> IfcSite
  • <Structural foundation> IfcFooting

I LIM prosjektet har vi skissert opp en liste med objekter vi mener bør være en del av LARK sine objekter. Hvis jeg prøver å sette disse objektene inn i system i forhold til  Components> nevnt i teksten over vil det bli som følger:

 

<Floor>: (LARK) (Eksempel)

  • Terreng (Soft landscape)
    • Vegetasjon (Vegetasjons oppbygging avhengig av Vegetasjon og grunnforhold. Ulik oppbygging om det er på dekker, jord, løsmasser, sprengstein, fjell.)
      • Trær
      • Busker
      • Stauder
      • Blomster
      • Gress
      • Plastring
      • Løsmasser
  • Plasser (Hard landscape) (Eksempler se NBS National BIM Library, UK, Objedt types, Hard Landscaping)
  • Veier (Roads)

 

<Furniture>: (LARK)

  • Utemøbler
    • Bord
    • Stoler
    • Benker
    • Avfall
    • Sykkel
    • Pullert
    • Plantekasse/urner
    • Stammevern
    • Treomramming – (<Nested Families>) Inn i en <Generic Model floor based> for å lage hull i gulvet for utsparing for trestamme og rotvolum.
    • …….
    • Lek og idrett
      • Lekeapparater
      • Sklie
      • Huske
      • Klatre
      • Hoppe
      • Sandkasse
      • Tårn
      • Mål
        • Ballspill
          • Fotball
          • Håndball
      • Nett
        • Badminton
        • Tennis
        • Volleyball
      • Kurv
        • Basket
    • Skilt
      • Innfelt – (<Nested Families>) Inn i en <Generic Model face based> for å kunne linkes til en flate. Flaten vil kunne variere på vegg, inn i granittelementer osv. Må kunne forholde seg til flere type objekter
      • Veggmontert – (<Nested Families>) Inn i en <Generic Model face based> for å kunne linkes til en flate. I hovedsak vil denne flaten kunne være en vegg men noen ganger kan den også være lurt å kunne linkes til andre objekter som ikke er vegg og derfor <face based>.
      • Puller
      • Mast
      • Henge – Forholde seg til høyde over terreng og derfor ok slik den er

 

<Ligting Fixtures(RIE/EL)

  • Utebelysning
    • Nedfelt – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der lysarmaturen kommer.
    • Innfelt – (Nested Families) Inn i en Generic Model face based for å kunne linkes til en flate. Flaten vil kunne variere fra opptrinn i trapp, på vegg, inn i granittelementer osv. Må kunne forholde seg til flere type objekter
    • Veggmontert – (Nested Families) Inn i en Generic Model face based for å kunne linkes til en flate. I hovedsak vil denne flaten kunne være en vegg men noen ganger kan den også være lurt å kunne linkes til andre objekter som ikke er vegg og derfor face based.
    • Puller
    • Mast
    • Henge – Forholde seg til høyde over terreng og derfor ok slik den er

 

<Parking> (LARK) (All oppmerking på dekker)

  • Oppmerking
    • Vei
    • Parkering
    • Symbol (HC)
    • Tekst
    • Lek og idrett
    • Taktil
  • <Planting> (LARK)
  • Vegetasjon
    • Trær
      • Løv
      • Bar
      • Frukt
    • Busker
      • Busker
      • Roser
    • Slyngplanter
    • Hekkplanter
    • Stauder
    • Bunndekke
    • (Blomster) – Inngår som del av beskrivelse av overflate på <Floor>. Evt eget volum som ligger over Floor og definerer ulike områder med plantemix.
    • (Gress) – Inngår som del av beskrivelse av overflate på <Floor>

 

<Plumbing Fixtures> (VA)

  • VA (Vann og Avløp)
    • Sluk – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der sluk kommer.
    • Rist – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der Rist kommer.
    • Renne – (Nested Families) Inn i en Generic Model floor basedfor å lage hull i gulvet der Renne kommer.
      • Slisserenne
      • Nedfelt renne
    • Kumlokk – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der Kumlokket kommer.
    • Vannpost
    • Brannhydrant

 

Frittstående konstruksjoner som LARK modellerer utomhus er identiske med de objektene arkitekten har til å modellere i bygg. De objektene som nå nevnes er tilnærmet identiske for ARK og LARK. Derfor kan disse brukes uten noen store tilpasninger for Landskap når det gjelder klassifisering i IFC. Formgiving, egenskaper og relasjoner på objektene må endres noe for å kunne brukes godt også ute.

  • <Wall> IfcWall
  • <Structural Foundation> IfcFooting
  • <Stair> IfcStair
  • <Ramp> IfcRamp
  • <Railing> IfcRailing
  • <Floor> IfcSlab

 

<Wall> (LARK)

  • Støttemurer (RIB/RIG)
    • Plasstøpt
    • Prefab
    • Gabion
  • Murer
    • Plasstøpt
    • Prefab
    • Gabion
    • Murt
    • Stablet
  • Spunt
  • Vegger
    • Vegg i bygg
    • Leevegg (evt <Railing>)
    • Ballvegg
    • Støyskjerm (evt <Railing>)

 

<Structural Foundation> (LARK)

  • Fundament for Utemøbler
    • (Se relevante objekter definert under <Furniture>)
  • Fundament for Belysning
    • (Se relevante objekter definert under <Ligting Fixtures>)
  • Fundament for Vegetasjon (Rotsone for trær?)
    • (Se relevante objekter definert under <Planting>)
  • Fundament for Konstruksjon og bygg
    • (Se relevante objekter definert under <Wall>, <Stair>, <Ramp>, <Railing )
<Stair> (LARK)
  • Trapper
    • Terrengtrapp
    • Eseltrapp
    • Frittstående trapp
  • Amfi
    • Sittetrinn
    • Trappetrinn
<Ramp> (LARK)
  • Mindre rampekonstruksjon med repos
    For store terrengramper anbefales å benytte <Floor> da <Ramp> kun har begrenset mulighet for innstilling av fallforhold. <Ramp> har ikke mulighet for lagvis oppdeling av dekker slik som man kan med <Floor>, noe som er relevant når man skal jobbe med store ramper i terrenget.

 

<Railing> (LARK) (eksempel)

  • Rekkverk
  • Håndløper
  • Gjerde
  • Ballnett
  • Skjermer
    <Railing> funksjonen har store fordeler ved at den er regelstyrt. Mange eksempler hvor denne funksjonen har store fordeler. Forholder seg høydemessig til en <Slope Arrow> som man finner igjen i <Stair>, <Ramp> og <Floor> . Hvis man jobber med høydesetting på <Floor> på andre måter en <Slope Arrow> fungerer ikke relasjonen mellom <Railing> og <Floor>. <Railing> fungerer heller ikke i forhold til <Toposurface>. LandCAD for Revit har funksjon som fungerer bedre mot <Toposurface> og <Floor> hvis man bygger opp <Railing> med objektfamilier som kan <Hoste> seg til flatene <Toposurface> og <Floor>.
<Floor> (LARK)
  • Konstruksjonsdekke i bygg (Likt som for Arkitekt)
  • Terrassegulv
  • Brygge
IfcSlabTypeEnumeration=
  • baseslab’ for gulv på grunn (Veger og plasser)
  • floor’ for dekke(r) over bakken (Brygger)
  • roof’ for topp- eller takdekker (Takterrasse)
Oversikt over hvordan det er direkte link mellom mengder i tabell og modell når det plasseres ekstra treomramming da disse automatisk lager hull i <Floor>. Se i tabell og sammenlign mengdeoversikt på dekke.

IFC for Land. Arch. – Example from Revit

This is an overview how LA can use existing software and adapt it to their workflow in order to work with 3D object-based modelling. The author has completed a range of landscape projects between 2005 to 2012 using Autodesk Revit as a 3D modelling tool for design, plan production, quantity takeoff, cost assessment, survey data etc. This overview aims to use the experience gained from these projects, coupled with the landscape information model objects we have discussed in this report, to better understand their codependency.

The overview shows that we can deliver a substantial amount of landscape data in IFC at this stage if we are, initially, willing to simplify the LIM (Landscape Information Model) objects and look at connections and options in existing software developed for other disciplines. Looking further, LIM objects should obtain their own IFC definition. In place of the IfcBuildingElementProxy where standard definitions does not suffice, there should be developed IFC definitions we can use nationally until we establish an international IFC standard for landscape.

Through practical use of this overview, there will be many important points to consider in a standardisation process concerning IFC for landscape architecture. The text is, however, a first draft based on personal experiences. Supplements from others with similar experiences are both wanted and encouraged.

Overview of functions in Revit and how they can be interpreted and used by landscape architects for 3D object-based modelling.

The <Floor> in Revit has high potential for LA. All layers used in ground covers, pavements, roads, squares and vegetation areas may be inserted in <Floor>, allowing control of quantities, layer thickness and build, section details and more when the total thickness of the <Floor> objects are correct at all times. <Floor> allows for elevation control along all edges or corners, but it is also possible to insert spot elevations or breaklines manually.

Notably, when using <Floor> in landscape, one should avoid using <Levels>. Rather, one should establish a lower level defined as Sea level +/- 0.00. All surfaces are modelled on this level and then elevated to the correct elevation above sea level. As a result, all adjustments and annotation will depict the correct surface elevation (contour height).

Elevation adjustment in <Floor> may be achieved through various means. On a detailed level one should control the <Floor> set in Sea level +/- 0.00 through the function <Modify Floor> / <Modify Sub Elements>.

This method of controlling the <Floor> allows the creation of double curved surfaces whenever possible.

The disadvantage of working with <Toposurface> is that it is simply a surface sans thickness. Every time it is adjusted, however small the adjustment may be, the program needs to compute the entire surface anew. The time spent computing increases in tact with the complexity of the surface.

<Roof> is not used, of two important reasons: First, <Roof> always has a fixed bottom elevation. Changing the thickness of  the <Roof> does not change the bottom elevation, only the top. This is problematic for landscape architects, as the top elevation is used to control slopes. Second, <Roof> cannot Host landscape objects, meaning objects does not relate to the <Roof> surface elevation.

<Building Pad> is also problematic for landscape. It affects <Toposurface>, resulting in high computational needs even when small changes are made. The greatest limitation, however, is in the elevation adjustment and cutting angle towards terrain. <Building Pad> only allows perpendicular cuts in terrain; either vertical or horizontal. If a slope is desired on a <Building Pad>, one can only use <Slope Arrow>. Neither <Floor> nor <Building Pad> allows more than one <Slope Arrow> per surface. If additional <Slope Arrow> could be used, similar to <Roof>, it might increase the viability for both <Floor> and <Building Pad>.

To create a curbstone edge to a <Floor>, one may use <Slab Edge> or <Model In-Place>.

On a detailed level, <Component>/ <Model In-Place> is used. By choice of <Family Category> and <Parameters>, <Walls> are selected. By choice of <Forms>, <Sweep> is selected. By choice of  <Sweep>, <Pick Path> and <Pick 3D Edges> are selected. The reason for this approach is due to the fact that <Slab Edge> cannot generate a 3D volume if the edge is part of a double curved surface, as well as curved itself. In other instances, the function is unable to connect volumes properly. To ensure the volume of curbstone is calculated correctly, one is better off using the approach above. The choice of <Walls> is to be able to extract quantities of the curbstone length. A better situation would be if <Slab Edge> would be able to create volumes on double curved edges as well as providing a length measure in <Schedules>.

There are no proper solutions for curbstone placement on <Toposurface> directly in Revit. This requires Siteworks and LandCADD from Eagle Point, distributed in the Nordic countries through Cad-Q.

All landscape objects (Component) for outdoor use must be able to use <Toposurface> and <Floor> as a Host. These objects may either relate to a horizontal plane or an angle on the surface in question. These objects have the advantage that their position can be linked to a surface, but also overridden and locked to a user defined elevation. The object families in Revit that supports this behavior are as follows:

  • <Furniture> IfcFurniture
  • <Lighting Fixtures> IfcLightFixtureType
  • <Parking> IfcBuildingElementProxy
  • <Planting> IfcBuildingElementProxy
  • <Plumbing Fixtures> IfcFlowTerminal
  • <Site> IfcSite
  • <Structural foundation> IfcFooting

In the LIM project we have suggested a list of objects we feel should be a part of the landscape architectural set. Adding these in relation to the Component system would create the following:

<Floor>: (Land.Arch.)

  •  Terrain (Soft landscape)
    • Vegetation (build according to vegetation type and soil conditions. The build depends on whether it is placed on hard surfaces, packed or loose soils, rockfill, bedrock.)
      • Trees
      • Shrubs
      • Perennials
      • Annuals
      • Grasses
      • Erosion control
      • Loose soils
  • Plazas (Hard landscape – see NBS National BIM Library, UK, Object types, Hard Landscaping)
  • Roads

<Furniture>: (Land. Arch.)

  • Outdoor furniture
    • Table
    • Chairs
    • Benches
    • Trash bin
    • Bike parking
    • Bollard
    • Planting box
    • Tree protector
    • Planting frame – (<Nested Families>) Into a <Generic Model floor based> to create a hole in <Floor>, allowing space for the tree trunk and root system.
    • Play and sports equipment
      • Playground equipment
      • Slide
      • Swing
      • Climbing structure
      • Jump
      • Sandbox
      • Tower
      • Sports goal
        • Ballgame
          • Football
          • Handball
      • Sports net
        • Badminton
        • Tennis
        • Volleyball
      • Sports basket
        • Basket
    • Signage
      • Inset – (<Nested Families>) into a <Generic Model face based> to be linked onto a surface. The surface will vary from walls to granite elements etc. Must be able to relate to several types of objects. 
      • Wall mounted– (<Nested Families>) into a <Generic Model face based> to be linked onto a surface. Primarily a wall, but in some cases there will be a need for it to be linked to other objects. 
      • Bollard
      • Mast
      • Hanging – Relates to elevation above surface, as such suitable as it is.  

<Lighting Fixtures> (Electrical)

  • Outdoor lighting
    • Enshrined – (Nested Families) into a <Generic Model floor based> to create a hole in <Floor>, allowing space for the lighting armature. 
    • Inset – (Nested Families) into a <Generic Model face based> to be linked onto a surface. The surface will vary from walls, steps and stairs to granite elements etc. Must be able to relate to several types of objects. 
    • Wall mounted– (Nested Families) into a <Generic Model face based> to be linked onto a surface. Primarily a wall, but in some cases there will be a need for it to be linked to other object.
    • Bollard
    • Mast
    • Hanging – Relates to elevation above surface, as such suitable as it is. 

<Parking> (Land. Arch.: All markings on pavement)

  • Markings
    • Road
    • Parking
    • Disability symbol
    • Text
    • Play and sports
    • Tactile

<Planting> (Land. Arch.)

  • Vegetation
    • Trees
      • Deciduous
      • Conifers
      • Fruit trees
    • Shrubs
      • Generic shrubs
      • Roses
    • Climbers
    • Hedge planting
    • Perennials
    • Ground cover planting
    • (Annuals) – part of a description of a <Floor> composition, or a separate volume above <Floor> defining different areas with a mix of plants.
    • (Grasses) – part of a description of a <Floor> composition. 

<Plumbing Fixtures> (Drainage work)

  • WDr (Water and drainage)
    • Drain – (Nested Families) into a <Generic Model floor based> to create a hole in <Floor> for the Drain.
    • Grate – (Nested Families)  into a <Generic Model floor based> to create a hole in <Floor> for the Grate.
    • Gutter (Nested Families)  into a <Generic Model floor based> to create a hole in <Floor> for the Gutter.
      • Slit drain
      • Lowered Gutter
    • Person Hole Cover (Nested Families) into a <Generic Model floor based> to create a hole in <Floor> for the Person Hole Cover
    • Water post
    • Fire hydrant

Independent outdoor constructions modelled by the landscape architect are identical with objects architects use for indoor modelling.  The following objects are nearly identical for the architect and landscape architect. These may therefore be used without significant adaptations for landscape when classifying in IFC; however design, properties and relations in the objects must be altered slightly to be suitable for outdoor use.

  • <Wall> IfcWall
  • <Structural Foundation> IfcFooting
  • <Stair> IfcStair
  • <Ramp> IfcRamp
  • <Railing> IfcRailing
  • <Floor> IfcSlab

<Wall> (Land. Arch.)

  • Retaining walls (Construction engineering)
    • Cast in place
    • Prefabricated
    • Gabion
  • Walls
    • Cast in place
    • Prefabricated
    • Gabion
    • Bricked
    • Stacked
  • Sheet pile wall
  • Walls
    • Building wall
    • Windbreak (optionally <Railing)
    • Practice wall
    • Noise barrier (optionally <Railing>)

<Structural Foundation> (Land. Arch.)

  • Foundations for outdoor furniture
    • (See relevant objects defined under <Furniture>)
  • Foundations for outdoor lighting
    • (See relevant objects defined under <Lighting Fixtures>)
  • Foundations for vegetation (Root systems)
    • (See relevant objects defined under <Planting>)
  • Foundations for constructional elements
    • (See relevant objects defined under <Wall>, <Stair>, <Ramp>, <Railing )

<Stair> (Land. Arch.)

  • Stairs
    • Terrain stairs
    • Donkey stairs
    • Solitary stairs
  • Amphitheatre
    • Amphitheatre seats
    • Amphitheatre steps

<Ramp> (Land. Arch.)

  • Smaller ramp construction with landing
  • For larger scale ramps in terrain, it is recommended to use <Floor> – as <Ramp> has limitations in its slope settings. In addition, <Ramp> has no option for composition layering as opposed to <Floor>; highly relevant when working with ramps in terrain.

<Railing> (Land. Arch.) 

  • Railings
  • Handrails
  • Fence
  • Ball net
  • Barriers
  • The <Railing> functionality is advantageous as it is rule based. It relates in elevation to a <Slope Arrow>, found in  <Stair>, <Ramp> and <Floor>. When working with elevation on <Floor> other ways than using <Slope Arrow>, the relation between <Railing> and <Floor> is lost. <Railing> does not work in relation to <Toposurface>. LandCADD for Revit has more suitable function when working with these elements when <Railing> is built with object families hostable to <Toposurface> and <Floor>.

<Floor> (Land. Arch.)

  • Contructional surface in buildings (identical to the architect element)
  • Terrace floor
  • Pier

IfcSlabTypeEnumeration=

  • ’baseslab’ for pavings on ground (roads and plazas)
  • ‘floor’ for pavings above ground (piers)
  • ‘roof’ for top- or roof surfaces (roof terraces)

Overview of the direct link between quantity takeoff and model when extra planting frames are placed, as these automatically create a hole in <Floor>. Observe the table and compare with the pavement quantities. 

 

One comment on “IFC for LARK – Eksempel brukt i Revit

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*


*

Du kan bruke disse HTML-kodene og -egenskapene: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>