Art V

No Vectorworks cannot do this, you will need a dedicated GIS program. A free GIS program that can do this is QGIS, a cheaper alternative to ArcGIS is Global Mapper (Windows only) which can also georeference images. If you are going to work on GIS I strongly suggest to get at least QGIS or a good but not expensive alternative to ArcGIS such as e.g. Global Mapper or other programs. This to verify the import/export went correctly. As much as I like Vectorworks, given the past issues I recommend for now to check against another GIS capable program to see if the import went well. If so there should be no further problems if you leave the georeferencing alone from then on in the document. Upon first export I'd also check the output. If that is ok too then future imports/exports into/from the document should be ok as long as the georeferencing of the document has not been changed. Though I'd do additional checks if you are going to import from one a different CRS than specified in your VW document. Currently the list of datums (though not all items listed as datums are real datums from a technical perspective) is limited so conversions may not always be correct. Which is why I'd like to see the EPSG catalog to be implemented in a future version of Vectorworks, as this may alleviate quite a few conversion concerns.

The past few version of Vectorworks had a number of bugs with regard to shapefiles and CRS's, some have been fixed over the past versions though new bugs kept showing up. One of the things was that depending on your CRS the false easting may have got ignored upon import, hence incorrect coordinates in your document. However, upon export the fase easting was added back causing issues again if you had corrected the document coordinates. Once that bug got corrected it appeared that under certain conditions the central longitude of the CRS was not always recognized properly depending on how the CRS was set up and again resulting in incorrect coordinates. This could be fixed with making manual corrections. In VW 2016 these bugs should more or less have been solved, but I haven't got to proper testing yet. If the documents were created in/for VW2012 and you are importing them into VW2016 it may be that you are seeing some side effects of the issues depending on the CRS used in the documents. I've always been surprised there was so little discussion on this in the forums, though I do realize not everyone using VW is working in a lot of different CRS's so it may not always show up.

Not sure if it is the same on a Mac as on my Windows machine... when I first started using VW2016 it was noticeably slower at startup than 2015. However, if VW2016 was closed and then opened again later on the day it was opening much faster to the extent that it was even a little faster than VW2015. For me it is only the first time start-up of VW2016 that is noticeably slower, subsequent start-ups during the day (provided the computer has not been restarted) are faster. It still beats AutoCAD start-up by a mile, so you won't hear me complain. :-)

Bruce, If the graphic applications of the others can import dwg files you may want to export your template as dwg file (or dxf). It should work well enough for Illustrator, CorelDRAW and a quite few other vector-graphics programs (Serif, Xara etc.) if you use standard fonts like Arial. You may want to check the latest dwg/dxf version they can import and export to that version or the lowest common denominator. That way you still have some control over the layout of the template.

Or... as one of my software programs does, deactivate all other installs upon installing beyond the authorized number of installs. E.g. when installing a copy on a third computer, upon activation it will automatically deactivate all other installs of the same license and you will have to activate one of them again to be back on two activated installs. I'd rather prefer the VSS (or other VW if you are not on VSS) account option to be able to deactivate installs on a computer as that way you can always deactivate an install.

It seems deactivation by the user is still not possible? Some software deactivates the license upon uninstall, which would be ok. Even better would be if it could be possible to deactivate a license through an option in the Vectorworks menu or license dialog or through your VSS account in case you cannot uninstall at all (e.g. computer crash) or if the deactivation is only temporary (e.g. when making major updates on the computer that may cause the system to be recognized as a new computer and the current activation to be lost, had that happen with some software in the past) Imagine things going wrong during holidays and you cannot (re)activate for days while you are on a deadline. This is not good. So if user deactivation has not been implemented yet, then please consider this to be a ++++100 support for the deactivation wish list request.

+1 for better display, and would prefer hierarchical display to be an option next to alphabetic. Sometimes it is useful to go by the record if different fields of that same record are being used, that would make it easier to find the records than searching by name (e.g. if one field name starts with "A" and another starts with "T" they would be close to each other)

+1 It would be better if it would be possible to define size as the paper size you want the object to be and the design layer and viewports scale the object relative to their scale so that it will match the defined paper size. This way the output will be independent of layer and viewport scales. For viewports it would simply be a conversion factor being the ratio between the design layer scale and the viewport scale. When the design layer or viewport scales get changed the object should resize accordingly to maintain the paper size. The same should apply to text as well, so that I don't have to fiddle with text sizes on design layers to get something on paper output that has the right size. This would be similar to paper units of the hatch design tool in the resource browser.

GIS is becoming increasingly important so it would be nice if the GIS part of Vectorworks Landmark and Architect could be further improved. Recently I spoke with a senior geodesist who is also member of the EPSG group and discussed the use of GIS in Vectorworks and he had a few comments/suggestions: 1. improve the formatting/structure and handling of the WKT information in VW as it is sometimes a bit sloppy compared to formal formatting. It may not cause problems too often, but if it does it can be nasty. 2. implement the new WKT format (ISO 19162) for importing/exporting WKT files as this may become the new standard for WKT files. Before this ISO standard was developed there were multiple variations of formatting of WKT files. New WKT standard as per ISO 19162 3. Implement the EPSG Geodetic Parameter Dataset, including the datums and not just the projected CRS's if coordinate transformations are going to be an option. It can be implemented for free if the data is not the main part of the software. This will reduce the possibility of errors in georeferncing compared to manually copy/paste of WKT files in the WKT dialog of VW if you want to use a CRS that is not included in Vectorworks. http://www.epsg-registry.org/ ArcGIS is very picky about the parameters and formatting and needs to be paid for using its dataset to ensure troublefree compatibility, but using the EPSG database would already be a considerable improvement in the GIS functionality ov Vectorworks as a lot of GIS software is also using the EPSG information.

When exporting symbols with attached records, the records end up as block attributes in a dwg file. When exporting objects (e.g. a polygon) with an attached record the information does not get exported into the dwg file. It would be nice if in the latter case the record contents would be exported as extended entity data attached to the object.

+1 Though a really good vectorizer is not cheap. I've tried a few even though the outcome was not bad it wasn't always very useful either depending on the complexity of the drawings. At times it required so much time cleaning up that I might as well redraw the whole thing. For relatively "simple" drawings it would be nice if the tracing in VW would actually usable, so yes it can use quite a bit of improvement.

This may be a graphics card/driver related issue as I have noticed similar behaviour in Microsoft Visio on occasion, though I have not been able to replicate it predictably. Did you check if your graphics card drivers are up to date and that you have enough memory on your system?

Jim, I've done some testing on the very large files, but was a bit surprised it took quite some time for the files to have the GDI count get close to 10,000 before it would crash. On a lighter file, when adding lots of text and copying text items/panning/zooming the 10,000 count was reached faster and VW would crash. One time it also crashed around 6,500. Hardly any other things were done during those sessions besides the adding text on a design layer. Changing classes of items was very limited. Other than this GDI count issue VW2016 has been quite stable for me and not that much slower if at all than VW2015 with these drawings. Based on the differences between the heavy and the less heavy drawing it seems to me it is not as much as the number of items being regenerated for class properties in the drawing but more the number of actions/regenerations that makes the GDI count go up quickly. i.e. updating 300,000 objects for class properties twice is not going to do much, but updating 300 objects for class properties during panning/copying 70 times is more likely to cause issues and increase the GDI count more rapidly.

This would work for most people, but if you are working with large (100+ MB up to multiple GB) images duplicating the image(s) is going to be unwieldy. Normally I put the big image on a layer of its own, lock the image and then on other layers draw everything on top of the image at the required location(s). Often I have multiple options on the same background and then have multiple sheet layer viewports, one for each option. For example... I have a large aerial/satellite image covering an 50km x 50km area and have items on two or three different locations with connecting items etc. There will be an overview drawing showing the whole area and then a series of drawings zoomed in on individual locations with possibly multiple options for each area. In the overview drawing there is little to crop, but for the "zoomed in" drawings there is quite a bit to crop from the full image. Copying into multiple images with crops and delete the outsides is just going to increase the overall file size without additional benefit because I still would need the full image as well. When exporting the sheet layers to PDF it would be nice if the image part of the export would automatically be cropped by the viewport boundaries. I don't worry about the file size of the VWX file itself with a single full image that much, but it would be nice if I wouldn't have to do a reduce file size every time I export PDFs to get rid of the crops as this can add up with relatively fast review/update/review/etc. cycles if there are a lot of PDFs to be generated.

This option has one problem, it removes all parts of the image outside the crop, though I may need those parts at a later time. e.g. when using an aerial image background to position a project, if I would crop the image and use "delete outside crop" and then need to move my project to an area that is outside the current crop then I would have to reimport the image and if it is not georeferenced then I would have to resize/reposition it as well. Which I why I would prefer to have the parts outside a crop to be left out at the export to PDF stage instead of permanently removing it within Vectorworks.

If the purpose is exporting to another program for editing, you could try exporting to DWG or Collada and see how that turns out, assuming the other program can import these formats. If it is only for presentation purposes outside Vectorworks then 3D PDF may be an option. Most good PDF viewers that can handle 3D PDF allow showing sections of the model in PDF if this is needed.

I often send a PDF along with the native file for reference so that the other party can check if everything is still there or how it should look when they open it in their program. For 3D this should apply as well, especially when sending the file in a different file format/version than the original. Edit: sorry, misread this as being about 3D PDF export.

It would be useful to have an option in the PDF export that will allow us to only export the cropped part of an image to PDF instead of the entire image as it happens now. Especially with larger images that have been cropped this may considerably reduce the file size of the exported PDF.

Another thing to take into account is whether the image exported to PDF is a cropped image (e.g. viewport or crop showing a part of the image) or the complete image. If it is a cropped image then the whole image may get exported into the PDF even when only the cropped part shows. Size reduction in PDF software will then remove the parts outside the crop. Even in VW2016 the entire image gets exported, even if it is cropped. I just tried this with a small image and when opened in an image editor and broken down far enough the original full image can be retrieved from the PDF, not just the cropped part. There should be an option in the PDF export settings to export only the cropped area of an image and not the whole image.

Imported AutoCAD symbols will only show with class defaults if the symbol items are complying to the two requirements below when created in AutoCAD: 1. created on layer 0 2. properties (i.e. colour, linetype etc) are set to "bylayer" In all other cases the imported symbol will be have a "fixed" colour, linetype, lineweight, layer (class) in its symbol definition. Pat's script may fix this for you, but you have to make sure that you want the symbol properties to be by class. Setting the colour, linetype etc. to be fixed in AutoCAD might have been unintentional or intentional. In the latter case, upon re-exporting to dwg files your symbols will not be as designed and may not appear correctly when inserted back into the original AutoCAD drawing.

Do you want to change the order in which the data fields appear in the record when displayed in the OIP? If yes, you can rearrange the order of records in the record definition by selecting the record definition in the resource browser and edit it. This will "update" the display order of data fields of the record in the OIP.

A lot of it is just matching industry vocabulary, although there are a lot of discrepancies between US and UK terminology, even though they're both English. Even with the Dutch translation there are language issues, as it is translated in Belgium and they sometimes use terminology that is technically speaking correct but it's use is sometimes outdated in The Netherlands and it takes a moment (or a dictionary :grin: ) to realise what it means. My guess is it might be similar for the German and French translations as these are official languages in multiple countries with regional differences. Maybe an Esperanto version of Vectorworks should be introduced?

Vectorworks basically is scale less when it comes to geometry, internally it works at a 1:1 scale similar to AutoCAD etc. The scale for design layers is just a display thing combined with showing a paper size. If you want you can ignore this and work with Vectorworks similar to AutoCAD. When I first started using Vectorworks (MiniCAD 5 at the time) I found the way it works a bit too weird for my taste and put it aside for a while. Once I realised what I mentioned above I started to like this way of working for certain things. I also often work way away from the page and then it feels just like working in AutoCAD except that I know what units I am working at and still get real world measurements regardless of the sale I am working in. It avoids the need to draw at a certain scale in AutoCAD in model space as I sometimes encounter in some documents and then having to calculate back to real world dimensions. What the scale setting does affect is display of text size etc. on design, but it is not really different from annotative text, dimensions etc. in AutoCAD on model space. Regarding tools like Heliodon, it would be better to improve those in a way that fits what you and others want.

+1 Besides that, sometimes there is a good reason to have design layers having different scales if you want to keep everyting in a single file, it just is a matter of being aware and flexible to deal with that. I still prefer Vectorworks' way instead of e.g. the AutoCAD way of putting multiple drawings in model space with all annotations on paper space and then not having a clue what belongs to what until you look at the viewports.

Output to specified paper sizes is something everybody needs. Sheet layers are the best way to do that. IF there is a need to output to paper, if not text cannot be at sheet layers to start with. For papers/PDF output sheet layers are in 99% of the cases the preferred way unless it is a small and simple document then it is an option to bypass sheet layers. From time to time I do not have to deal with output sizes at all because the output is going into other programs such as e.g. GIS software. Often I have a mandatory paper/PDF output size that I cannot deviate from. In that case it is really convenient to see the page size when drawing and see if it will fit within the output size at the initial scale. If it does not fit I can adjust the scale and continue. If it happens that e.g. I go from 1:20 to 1:25 and then find I have to change to 1:40 I know that legibility issues may start to crop up and take action on that instead of finding out when all is done or while having to switch back and forth between design and sheet layers. Yes I do use sheet layers 99% of the time when paper/PDF output sizes are required. It doesn't work yet because Vectorworks is not supporting this by now. It is supported, but it can be very cumbersome to use. Some of my work requires considerable revamps after review with rearranging quite a bit of objects. Then having texts and dimensions in annotation viewports is simply not convenient as they do not always (read: most of the time not) move along with the objects. I cannot wait with putting in all texts/dimensions until the very end, then having to update multiple viewports becomes a nightmare. I agree Vectorworks can use improvement in this area, but there are lots of uses for Vectorworks other than BIM. Taking things out because it does not fit a BIM (for buildings) workflow is imho not the way to improve Vectorworks.