Art V

Or is the reference object only meant to measure the location's real world coordinates to compare with the coordinates of the stake in the viewport so that it is possible to determine the offset of the viewport's coordinates relative to the designlayer?

Not related to architecture but it does give an idea of how generative design can lead to solutions that may in the end not be that practical/useful after all even if it does meet the input criteria. https://www.engineering.com/story/when-generative-design-backfires-vws-new-wheels

Or you could use the vendor provided content if it meets your requirements and convert it to custom (own) content if possible, that will save you some time. Most vendor content is ok for general purposes or if it is meeting some international standard to meet that standard. But it's not uncommon to need something slightly different so the advice to build your own content is definitely a good one. That way you will get to keep "outdated" content as well in case you need to update old drawings according to older standards if required. With relying on vendor content you risk that such content may be removed when it is updated/removed if standards etc. develop further/change.

@Matt Panzer Thanks for the clarification, so moving something by (0,0) causing object attributes to change to default atrributes is a bug in itself though it is in this case it happens to solve an issue with another bug if I understand this correctly.

That worked. Does that mean that whenever I move a wall it will change attributes based on default attribute settings? In theory moving an object should not reset/change its attributes. If this happens to a wall when moving it by (0,0) are there perhaps other objects where this could happen as well? If so is this by design for a movement by (0,0) or could this also happen with e.g. duplicate in place?

Well... this would be another reason to avoid putting annotations inside a viewport. I used annotations inside a viewport for only a very short while because it was just too cumbersome for my use case so don't know how much putting annotation inside a viewport would affect the center location. In DWG based software the annotation on a layout (sheet layer in VW) is on top of the viewport and not within the viewport so the viewport itself is never affected by annotation on the layout. If putting annotation inside a design layer does change the boundaries and therefore also its center point then imo it is not a good design as it could cause unwanted side effects. Yes it needs to be made clear to the developers what is needed and how it should be implemented/work. Especially the latter can be quite important as it may make the difference between somewhat useful or really useful. E.g. in my other CAD program they implemented something that solved a quite major issue but the implementation while not bad in itself causes a new issue that needs to be solved. Had I known in advance how they would be implementing it then I could have mentioned that and they could have made a change in the implementation to avoid that issue. Software developers are not always aware of how things are done in practice so they need to be made aware how you would like it to work.

Without knowing how the solid was created my guess would be that there might be underlying geometry that extents into both sections and causes the two sections to be treated as one object. I've seen similar behaviour in other software for that reason. But there ungrouping solves the issue. What happens if you convert the solid to a generic solid and then section it? Do you get two different objects in that case?

In theory the 3080 should be a noticeably faster card IF Vision can and does use it to the full extent. Vectorworks system requirements advises a RTX 2070 for a mid-level profile and a RTX 3080 for a high end profile and states that in general the more powerful the graphics card the better the performance could be. Basically, based on the system requirements and without knowing what you are designing... if you have drawings loaded with Vision equipment then a 3080 would be advisible, if you have modest amounts of equipment (e.g. small to medium sized venues with modest amounts of equipment) then a 2070 might be sufficient for the near future (2-3 years). If you want to use the card for e.g. the next 5 years and expect your projects to get larger then it might be worth to invest in a 3080 anyway for futureproofing because Vectorworks will be offloading more and more to the GPU in the longer run. Having to buy two x070 cards in five years might be more expensive than buying the most recent x080 card over a 5-year period.

If you really want to put the stakes in the annotation layer of the viewport then you could try to size the viewport to the minimum extent needed to show the area and position the center point of the viewport in such a way that the coordinates inside the viewport align with those on the design layer. I.e. Figure out the exact difference in x,y and relocate the center of the viewport to compensate for that difference. In theory this difference should be proportional to other viewport sizes with the same length/width ratio and same scale and a shift of the center would then be a matter of adjusting for that proportional difference. If the viewports have different length/width ratios then you would have to do the whole process of finding out the exact x,y difference and compensate the center position for each viewport, which can become quite tedious if you have a lot of viewports. In that case putting the stakes on a design layer is probably the more efficient route to take.

@Benson Shaw I'm not that wise person lurking out there but your approach is how I would do it as well in such a case, probably the guides version as preferred option. Maybe VW should get similar functionality as DTP software with master grids and pages for sheet layers, especially for structured layouts this would be nice to have.

I'm not using a mac but VW does not support opentype features, so I can imagine this autocorrection to stacked fractions etc will break calculations in the OIP. It should be possible to turn of this autocorrection, does that solve the issue when you try again? If yes then it is this autocorrection, if not then you might have a bug specific for your configuration and then VW support should have a look at it.

The halved text at the top is most likely caused by the boundary of the image frame overlapping the text. Does moving the image up a bit solve the issue? Regarding the upside down text, did you perhaps mirror the lines that have the associated text upside down?

Well at least in Canada you may not have to figure out if the feet are plain imperial feet or US Survey feet for the legacy survey data 🙂

This is where a fix constraint would be nice to have so that it forces another point to move even if two constraints are counteracting on each other.

For the issue in the first video, did you try putting the dimension at the center of the top edge instead of the left top corner? In case it is a polygon there is a chance that will move only the corner node and not the entire edge but putting the dimension at the center of the edge should in theory move the entire edge, assuming this would work in VW as well.

In that case the two details are separate view(port)s and I would expect them the associated crops to export as independent symbols, also because the views may or may not be aligned. That being said, it depends a bit on the drawing structure and concent how clean the export will be, but exporting sheet layer content as symbols and multiple viewports into DWG is not really desirable in most cases. Even with relatively clean (structure wise) drawings I may need to clean up DWG files to some extent, so yes export to DWG could be improved but this is (fortunately) one of the things listed on the roadmap for improvement. Something to keep in mind is that not everything translates to/from DWG from/to Vectorworks in a straightforward ways so workarounds will sometimes still be necessary to keep it visually correct. It's an issue with other software as well where things can't be translated 1:1 because of differences in implementation and functionality.

@J. Wallace Thanks for the link, I'll check it out. I do recognize the website as you have referred to it some time in the past.

I was wondering about that mentioned splash screen as well, mostly because there is not any info on intent and purpose of that item so I have no idea if I should support it or not. That is imho the bigger issue with some of the roadmap items rather than whether it benefits me or not and therefore should support it or not. It may even lead to people supporting a roadmap item because of what they expect it to be rather than what it actually is going to be and be disappointed in the end and complain about bad implementation of a feature. Notwithstanding that, some people may suggest a feature that they think is nice to have/useful because they have it in another program while those with more experience with VW may realize it is not of that much use within VW because of (reasons why) and it should be possible to voice such opinions and why it may be better to drop that feature or to suggest an alternative instead. The latter bascially means saying that the feature should be dropped, even if it is not explicitely said that way. Saying that making such comments, provided these comments are stated in a decent manner, are not appropriate is imho counter-productive.

Could you please share what course it is? It may be useful for those (relatively) new to (Q)GIS so that I can refer people to that course if applicable. Thanks in advance.

If set up properly, probably none. I would have to test again with VW2022, but VW tends to import DWG files based on its WCS (equal to VW's internal origin). I've run into issues when DWG users had used a (rotated) UCS that was not aligned with the WCS. So if you have to collaborate with someone from the DWG side then make sure the coordinates etc. are set up the same way. In general I align all georeferenced data to the internal origing of VW and use rotated plans/views where necessary and unrotate before export. The DWG side should preferably to the same, i.e. change any active UCS back to WCS when sending the file to you. This way the changes of things ending up at the wrong location should be minimized. At least I never had issues roundtripping with DWG this way. There are other issues with DWG roundtripping but those are not related to georeferencing and need to be fixed by VW improving some things with the dwg import/export. Also make sure you are using the same units, some DWG users have a habit of drawing at scale instead of 1:1, e.g. their units are set to mm but they treat it as metres and therefore draw it at a 1:1000 scale. VW may think upon import that the drawings units are in mm and you end up having to fix it on your end. If you have a need to strip elements etc. from the drawing, change coordinate origins etc. always work on a copy. There is no need to compromise your drawings because you have to export to DWG.

This is why I always put stakes with coordinates on design layers with the same scale etc. as the layer with the objects to be annotated so that I can be sure it stays correct. In theory annotations should be put in the viewport, but frankly that can be a quite tedious experience if you need the same annotation in multiple viewports with different scales etc. so most of the time I put the annotations on a design layer.

🤣 Absolutely agree with that naming formatting decision comment. Though these naming conventions and other things were designed with "machine/computer automation" in mind, not humans, so the results can be somewhat bizarre at times.

@Dave Donley This is the kind of thing that makes people wonder why some things are on the roadmap. What would make it the roadmap more useful for us would be a description of the intent of why something is on the roadmap, what are the arguments in favour for a roadmap item. E.g. to use the "more interactive welcome screen" as an example... what is the intent and why do(es) the person(s) making that roadmap suggestion to consider it think it is in improvement? Right now it only shows one line without any information so I have no idea whether it would be worth upvoting or not so based on that I would definitely downvote it if possible. Some things may seem not worth the effort unless you know the why behind a request, it may also cause others to come up with a possibly better solution/alternative. That way everyone may benefit. Just two more examples from the development section: "3D Modeling - Push/Pull enhancements Posted April 2021 A new tool will be added to offset edges of planar and non-planar faces. Push/Pull mode will be added to provide push/pull behavior as soon as edges are offset. Existing Push/Pull tool will be enhanced to support non-planar faces." This is a bit non-descript to some extent, I'm not sure if it means what I think it might mean. If it does then it would be really nice to have but I can't be sure. Maybe it is implemented in a way that is of little use for me but I don't know so I can't suggest possible improvements after all and will only find out when it is released. Then I would probably be commenting on how half-baked the implementation is and how it could be improved. "Roadway Posted April 2021 Layout and networking features" This is just too general, what can be expected? Is it something that I would want to support, should I make a suggestion for (additional) improvement or could my suggestion be something that is already being worked on.? A bit (or lot) more information would be useful.

Not just a few years ago, it comes up almost every year and I'd vote for that as well. Up to a point I do agree with that, but being diplomatic in one's wording is not always a compliment if you consider the following definition of diplomat... a diplomat is someone who is an expert in using the nicest words to say the nastiest things. Given the first quote and lack of response on that from VW I sometimes have a feeling that Andrei Gromyko is still alive and has a position at VW somewhere though at least he would have said something, if only just one word. 😁 It's the lack of some clear explanation, i.e. not some vague wording that doesn't really tell much, of why something takes so long or hasn't been done that is probably just as frustrating as things still not having been fixed for years without knowing why. It would already be something if there is a statement of whether some issue is going to be tackled or whether it is considered as a matter of no interest by VW. At least then you know what to expect (or not expect). That would be a good alternative, there needs to be a bit more fine grained range of responses to clearly indicate how much priority a feature should have, e.g. "nice to have" would be 2 or 3 stars in a range of 5 stars.

Just checked the SHP file. VW imports some of the polylines as groups of multiple lines. Maybe this is causing the issue. When importing the shapefile into BricsCAD with Spatial Manager (with assigning the ELEVATION attribute as Z value) it says there are 235 objects that have been imported as 285 features due to the complexity (i.e. grouping) of some objects. Both QGIS and Global Mapper import it fine as well and also state that there are 285 features after import. Except for VW I get the polylines/polygons at Z-value i.e. as a 3D terrain after import of the SHP file. It could be that QGIS somehow groups same elevation polylines and that VW is not splitting the objects back into separate polylines or VW is grouping those lines upon import and therefore may not be adding the Z value properly. But that is just a guess on my end. I suggest you have VW support take a look at this shapefile to see if this is the issue or that something else is going on that causes VW to not properly import the shapefile.