Jump to content

shorter

Member
  • Posts

    3,100
  • Joined

  • Last visited

Posts posted by shorter

  1. We are being asked to add two classifications to Doorsets.

     

    We need to tag the doors with both an Ss code and a Pr code.

     

    Doing this in the classification (Ss) and classification 2 (Pr) fields in the IFC data fields results in only one, the classification field, being exported.

     

    We have been told we should use an 'IfcSystem' for this but I was always under the impression that 'Systems' were for MEP.

     

    It works though.  I have created an IfcSystem called 'Doorsets' and given it the code 'Ss_25_30_20', and we do indeed get both classification codes, but I am not sure this is the correct application.

     

    How else would you get two classification codes into a Door?

  2. Always model/draw true north and use rotate plan.

     

    Align internal origins first and foremost.

     

    Then set user origin.

     

    Get Revit users to use scope boxes so that they model in true north and use not project north.

     

    if they use project north make sure the angle of rotation from true north is exact and the same as your rotate plan angle.

     

    0.0001 degrees equates to 0.1mm over 100mm.  Survey accurate to +_ 50mm if topo so rationalising the angle of rotation on existing building is no big deal.

     

    ifc only works if internal origins are aligned.
     

    internal origin and project base point should align in Revit. If they don’t make sure internal origin in your model is in the same location relative to their model.

     

    project base point is specific to Revit and has no relevance.

     

    All this should be in the BEP and SMPs.

     

    In addition to our bim management services, We offer a service whereby we set up files for revit consultants to use to set up their project models correctly.

     

  3. May have asked for this before, but we need to be able to search in worksheets via IFC 'field value' as one can a standard record format.

     

    So for example, if we wanted to search for all doors with the 'IsExternal' parameter ticked...

     

    Currently we are permitted to search by IFC Entity, and Field Value, but IFC 'records' are not included in the 'Field Value' selection criteria.

  4. ps  from the looks of your other posts, I suspect you have created a door style, with just the jambs showing, ie. a cased opening, and this is now the styled used by your doors.

     

    Or, you are not in Top/Plan view.

     

    That said, I did experience an issue with doors a while back that is similar to your problem.  Cannot recall how I fixed it though.

    • Like 1
  5. it always helps to post the file here for someone with too much time on their hands to have a look at it... 😉

     

    I would always suggest opening a completely new, fresh blank file, i.e. not one of the VW templates, and repeating what you did to see if you can replicate the issue.

    • Like 1
  6. 2 hours ago, Tom W. said:

    So a completely ridiculous situation really.

     

    It is.  The whole geo-referencing setup feels wrong to me.  The fact that you can cheat and geo-locate a stake, for example, would for me be the same as editing a dimension to say 3m, when it is really 3.1m.  It is an absolute no-no.

  7. 2 hours ago, Tom W. said:

     

    I only see this when I say 'yes' when it asks me 'Project the pasted objects into the georeferenced layer'. I always say no. I think it's to do with transforming the objects to match the projection of the coordinate system or the curvature of the earth...? If I say no to projecting the objects all is fine.

     

     

    I've never had any issues importing point clouds into georeferenced files in this respect. They always come into the file in exactly the right place as regards x/y/z + orientation. HOWEVER the issue I have is that they come in with missing points due to distance-from-internal-origin problems: the point cloud will only import whole (with all the points intact) if the internal origin is coincident with the user origin which is obviously not going to be the case in a georeferenced file. So a completely ridiculous situation really. But that's a different issue to the original post...

     

    I very rarely ever click a dialog that comes up giving me the option 'Yes'.! 😉  I did in this case because I was feeling mischievous.  But this is very unexpected behaviour.  I do not recall ever giving the layer geo-referenced settings which is why I was surprised to get the message.  Clicked Yes to see what would happen and lost the plan!

  8. If I copy and paste objects, or more specifically, a group from a file with no geo-referenced layer to one with a geo-referenced layer, it scales the object!

     

    Not only that it rotates the object and moves it 1000s of meters away with no apparent logic.

     

    Is this a known issue?

  9. I would love to be able to create a saved view from a sheet layer viewport.

     

    Currently, in order to do this we double-click on the viewport, navigate to the design layer, hold our breath while we wait to see if the coordinate system and user origin are still intact, unrotate view, and save the view.

     

    A single click to do this would be a great asset.

     

    The view is useful for a number of reasons, such as previewing what's on the sheet layer but also for exporting DWG reliably from modelspace since DWGs from paperspace are like playing the DWG version of russian roulette sometimes.

     

    As mentioned before we would like to be able to link a saved view to a sheet layer viewport and vice versa too.  This could be a neat way to maintain the sheet from the modelspace.

     

     

     

     

    • Like 3
  10. I know this is not the right forum for this but...

     

    Why is it that certain consultants using the 'other' BIM solution, the one that some seem to think 'is' BIM, have absolutely no idea what IFC is for, and when they receive your IFC never ever tell you that they have had issues using the model you issued on day one until 6 months down the line when the sticky stuff is about to hit the fan, fingers are being readied for pointing, the goats have been scaped, they suddenly start complaining and say 'we have never been able to open your model' or 'there were things missing so we didn't bother using it' or 'it didn't arrive in the right place and we got fed up moving it each time' or 'we can't use your model because it is not producing very nice drawings', or 'we can't use your IFC because it has no text', or 'it's not the right file format', despite knowing from the outset that we are sharing the iso19650 recommended file format for BIM, IFC, as the primary exchange file format because the Client and BIM coordinator have sensibly deprecated proprietary file formats.

     

    And relax...

     

    Seems that we need a caveat with each issue of model data.

     

    Something along the lines of:

     

    We herewith issue 2D DWG r2018 and 3D IFC2x3 in modelspace, in millimetres, at 1:1, in OS coordinates, aligned true north, in accordance with the spatial statement defined in the BIM Execution Plan.

     

    If you are using 'the other software' link these files 'auto - by shared coordinates' and advise of any problems immediately.

     

    Subsequent complaint will not be entertained.

     

    Discuss.

    • Like 1
  11. Aha!  Very interesting you should ask!  We have always wondered too.

     

    However, I have it on very good authority (i.e. @Martyn Horne told me), that an 'issue' is the moment at which the file is issued, and what for, e.g. Issue 1, 06/10/23, Issued for Information.  In ISO19650 this would be the 'P01', 'C01', etc.

     

    A revision on the other hand is what has been revised on the drawing, e.g. 'Rev. A, Door Position amended'.

     

    Thus on Issue 1, we have:

    revised the door position, rev A

    changed the position of the column, Rev B., etc.

     

    Now I may have got the wrong end of the stick here but I think is it eminently sensible and totally logical, albeit nothing like how we use it in the UK.

     

    We use 'Revisions' alone.

     

    Unfortunately, neither system is 'compliant' as we cannot add 'Checked' and 'Approved' to the revision, so we add it to the sheet.

  12. Perhaps it's workflow related.

     

    In our models, Section Viewports would only exist for GA sections and elevations (because the model is max. GA LOD).  3D Detailing does not happen in the model.  It's coordinated 2D and placed traditionally on the sheet as a standard viewport.

     

    Therefore we would rarely need or have multiple section viewports on top of one another.

     

    However, I can imagine a tiled sheet (i.e. 4 drawings of a single section, for example) because of the size of the building and therefore potentially need 4 section line instances, but even then, these would be located in a key plan, most likely and therefore be independent.

     

    It might be useful to be able to associate one section line to more than one viewport if in this example the section line were placed in modelspace instead.

  13. 43 minutes ago, Tom W. said:

     

    This gets to the nub of the discussion. There is no defining section line: sure, there is the one you use to create the VP but all subsequent lines are not instances or copies, they are multiples of the definition. Also as you allude to you can have a section VP + chose not to display a section line for it anywhere. Likewise you might create a section VP on the Design Layer then immediately delete the resultant section line + enable it in a VP instead: would 'navigate to section line' take you to the original - now deleted - SL on the DL or the subsequent version in the VP? This is why I think the idea of a standalone defining section line in its own special edit group is a good idea. Keep the defining section line + those you display in VPs as two separate things.

    It does all seem unnecessarily complicated, and not in a good way.

  14. 19 hours ago, Tom W. said:

     

    Often not e.g. a series of section VPs spread over two or three sheets with each sheet displaying a small scale 'key' plan containing section lines for all of the section VPs

    What I mean is, each section viewport has a single section line associated to it, or should.  Right click, ‘navigate to section line’ should be sufficient to take you to the section line instance.

     

    of course, if you have copied the section viewport and it has no section line… that’s another story.

  15. On 9/10/2023 at 8:58 AM, Matt Overton said:

    Yes please, 

    It strikes me as odd section viewports can't just be double-clicked to get the the section line like a perspective view has navigation to the camera as an option.

    It really should be as easy to navigate from a viewport as it is to navigate to a viewport.

     

    Right click on Viewport and 'Navigate to Section Line'.  That's how the competition does it.

    • Like 4
  16. Am modelling the post-demolition model.

     

    It is great that we can model with ifc entities directly.

     

    However, I have noticed a slight inconsistency in the way IFC data is retained (or represented), depending on how we model.

     

    I have imported an IFC of the existing building to use as the reatined model with demolitions then...

     

    Method 1

     

    I have used the automatic plane detection to draw a rectangle on the face of an ifc entity (IfcWallStandardCase) then used push/pull combine mode to cut an opening.  I have then filled the opening with an extrusion that is noted as 'Demolished'.  Slightly long-winded but gets me where I want to be.

     

    If I use automatic plane detection and cut the opening using alt-click, or push/pull combine mode, the object clipped, i.e. the wall, retains it's IFC data or at least is visible still in the Object Info Palette.

     

    but

     

    Method 2

     

    If I model the opening separately (it may be more complicated than a simple extrusion) and then use 'subtract or section solids', retaining the subtracting solid, the ifc data is stripped from the clipped ifc entity, although still present when I edit the resulting solid subtraction.

     

    Why?

     

    Why does one method work and the other not?

     

    What logic is at play here?

     

    The resulting object is the same in both cases; a solid subtraction.

     

    Or is it a visibility issue in the object info palette because when I modify the solid, the wall clipped has retained it's data in method 2.

     

    Does this mean that I should be using the latter method and not draw on surface and subtract solid?  It is arguably more efficient but the apparent loss of data in the OIP is not ideal.

     

    Also the results are very different when re-exporting the IFC.  Method 2 does not export the object via IFC despite both the wall, and the solid clipping the wall being IFC entities.

     

    Strikes me that what we need also is an option when using the push/pull combine mode to retain the subtracting object.

×
×
  • Create New...