Vlado

This is a different thing and it is intended that way. GetRField really returns a string, so it more picky of the precision. However, it is specifically implemented to preserve the precision of dimensions and control points. This is the same for both script languages.

@David Bengali oh wow, you have found a bug. I never realized this was there, yes the doubles are truncated when going from vectorworks to the python, and it is python specific. Unfortunately, we just released SP4, so it will be fixed in the next SP and the next version. Until then, you can use vs.GetRField to access the parameter values with full precision. it's a string you get back, but it has full precision number. I'm sorry for the bug, it's a sneaky thing. Thank you for reporting it!

Hi @P Retondo This is a known issue, and there are wishes to update this tool. We have it high on our lists to update and improve the workflows with. Regards, Vlado

If it works in general but not for a specific database, maybe there is a specific things about the SQL language of that database, like comma or quotations. We have a configuration file that can set these things up, as from Vectorworks perspective they are all the same, we just sent requests. What's the database you are using? I've managed to this during my tests with another DB. I am using VW 2020 SP2.2R1 in german. It looks you've found a place where the buttons should have been disabled but they are not. Symbols are not accounted for when exchanging data. Which one would you recommend? It's either say, all these use the same API.

Hi @Bogdan Ciocan How do you do this? You surely have objects in the drawing for this? The fundamental concept is that you connect a database to your VWX drawing. Then you define the format to be connected to a table, and establish which format field connects to which database table column. Note, there is no data flow at this point, only connections that tells it how the data will flow, and where the data will be stored in both places: <vectorworks' format field> to/from <db table column> Now, when you have a record of this format, which is the actual instance of a record, and can only be attached on objects in the drawing, then you have data, which is stored in a row of the data connected to this format. fields, i.e. db table columns, define how the data from that row will be exchanged with the record. So, now, if you edit a symbol definition, having nothing selected means that you are editing the defaults values that will be attached when this symbol is placed in the drawing. Noice that the 'Object Database Connection' is disabled in the context of symbol edit. Now, if you insert this symbol into the drawing, the record is attached to that symbol, and you can use the Data pane button, or menu Tools -> Database -> Object Connection to associate a row of the db table to this record. Note you can do that on a single selection or multiple selection in Vectorworks. The single selection will be like either add or select a row to provide the data for this symbol instance, where multiple will give you a chance to add or find rows depending on cirterias. As far as I understand, you are trying to build up a library with prebuild values from symbol defintions connected directly to db. This can be possible with scripting (either python, vectorscript or marionette). But there is one main question: if you add multiple instances of this symbol definition, you'll have repeating data...essentially the key will be duplicated, so several objects will contribute to a single row in the db table. Maybe your data works that way?

Hi @Bogdan Ciocan, Well, technically, the symbol definitions are pre-set graphics that are ready to be placed in the drawing. They do not store any information, well they hold default values, but not countable information. Then they cannot be connected to the DB as it holds actual data. So, maybe your question is how to connect the default values of the symbol data to a database? But that would be strange as when you insert the symbol in the drawing, you can have several copies of the same data. Is that required? What is the workflow you want to implement? At the moment, a DB table for vectorworks is a Format and Record at the same time. Format represents the table and it's columns (the definition), and a record is a single row. This way, when you have several records of a format, you are dealing with several rows of that table. Following my thought from above, if you have a record attached in the drawing, you can associate it to a single row from it's DB table. So, if you symbol instance has a record attached to it, you can associate it with a DB table row and get/put the data there. This works via the 'key' columns (one or several) identified when connecting to the database. They are used in the 'WHERE' of the SQL to identify a single row. this is the so-called primary-key and secondary-key of a table, and unique so they can identify a row uniquely. This means that your format needs to connect to these columns, so when you connect a record, it has a place to store the 'keys' to uniquely identify that particular row in the DB table always. Yes, selecting multiple objects and trying to connect them with the menu command, will allow you to use logic to associate the multiple objects to multiple rows in the DB table using pre-existing values in the keys. You can also use the Data Manager to exchange data between records and parametric objects. Regards, Vlado

@David Bengali > clarify further on the process and its relationship to .pyc files, and how to ensure that the source code truly cannot be accessed in some way. The python would compile the .py files into .pyc files before execution. This is part of python and always happens, it always executes the pyc files, and it has some smarts to not compile if the py didn't change. The pyc files are binary files that are byte-code of the python code. I guess you can read more about them in the python documentation. As far as I know, it can be uncompiled but it doesn't restore variable names, comments, etc. The process of encrypting a python plugin in Vectorworks consist of bundling all .pyc files into the vsm, vso, or vst files. It essentially, copies the binary files as is, one after the other in the vso, vsm, and vst file. This adds a little protection too as it's becomes one big binary now. Even though, if you really wanted, and analysed the bytes, you can figure it out. let me know if you have more questions. Regards, Vlado

Well, the equivalent of the console command 'python' is a Vectorworks document script. You can execute pip-like stuff that way. Also, note that python is very flexible in the sense of libraries. Perhaps you can try moving only the necessary stuff into the users folder: <user name>/Plugins By default vectorworks will add that location to the search path of the python engine. So if you can isolate necessary needed pieces, you can provide them there. This is, of course, if there is no conflict with the exiting packages in the app bundle. I'll make it a point to update for the next release.

Hi @relume and @JBenghiat did you manage to get it to work? First note that Vectorworks embeds the python engine, which means that Vectorworks is the python. So, if you just update your local python you are not really affecting vectorworks at all. So as Josh suggested, you can download the 3.5.2 on the side and manually copy it over into the Vectorworks bundle. However, there might be problems with this. There are two sides of python: first it's the engine itself, it is linked, embedded into Vectorworks, and there is no way to change it unless we rebuild Vectorworks on our end. The second part is the python built-in libraries. This is what you would be updating if you just copy them into the Vectorworks bundle. I guess it would work as long as python engine supports the new bundle directly. Of course you can try, just test it out carefully as not to have strange effects on other python based features. Regards, Vlado

@orso b. schmid i'm sorry, i've missed all these posts and the reference to me. I'm sorry to hear that vectorlab is down. It is absolutely possible to merge any information you have from vectorlab into the developer.vectorworks.net wiki. Also, i can give rights to anyone who is willing to support it. Page edit requires logged in user, page creation requires admin. User registration requires a request as we've seen lots of bots creating users and spamming the pages, but i create users for anyone who asks. Unfortunately, I currently have no team to support it actively and produce nice examples. I'm working on this to change, but i cannot promise timeline at this point. Again, if you have the db, or any set of articles from the vectorlab, i can merge it in.

@SeanR @maccadingo @loretta.at.large I just confirmed, the build is ready and it will be released tomorrow morning EST

@SeanR @maccadingo @loretta.at.large hi all, there have been a problem with a different issue that the release was fixing which delayed the release. At the moment it is scheduled to be released on monday, Dec 16

Hi @SeanR, great. a patch for this will be released very soon. Regards, Vlado

Hi @SeanR, this sounds like a known problem of Vectorworks 2020 SP2. The plant tool misbehaves when the user origin is changed. can you confirm that it works correctly if you don't change the user origin? a fix for the issue i'm thinking of will be released very soon. Regards, Vlado

@JeremyLondonRMLA I should clarify that I don't think this will compromise the accuracy of the drawing as the geometry wont move. It will be a script that calculates the adjust origin's lat-long based on the current user origin so the internal origin is at the same place.

Hi @JeremyLondonRMLA This change was needed to make things more stable. You see the User Origin is something that is not fixed and can be changed freely, typically for adjusting the numerical values of the geometry. Essentially relying on the User Origin was requiring the user to be aware of its significance and this was leading to misalignment and confusion. So, in Vectorworks 2020 it's the Internal Origin that is the point that matches the GIS and CAD layers. It was there before, but it wasn't enforced as much as now. Basically, the GIS layers (the layers marked as Georeferenced) are layers that belong to the Earth and they will move when you use the Geolocate tool. Then, the 'adjust internal origin' option will define the lat-long coordinate that the CAD layers will be placed at. That is correct, the Geolocate tool is just a visual way to set the 'adjust internal origin' options. This sounds to me like an issue of setting up appropriate georeferecing as your old drawings are already located around the internal origin, but if the shapefile import doesn't match means the the 'adjust origin' options are not matching. That would be easy to calculate and set via a script. Please contact me at vstanev@vectorworks.net and i can develop a script for you to use in these cases. Regards, Vlado

@ericjhberg message received. these are the things at the top of our list.

You can log in to ESRI inside Vectorworks' new feature. Essentially, when you browse for service, you can log in to browse the ESRI's full catalog of services. From those available services, we can only communicate the Image Layer services (raster image). The others are Feature Layer services, the shape file equivalents, which we will support in the future.

Well, the main part is selecting appropriate coordinate system for where the project is located. Then locate your drawing and everything you draw will be properly georeferenced. Not with the default maps. We only have satelite and map image services if you haven't logged it. If you log in, you can search for data in the area of the project. But for now we only support raster images. You can ask or look up the servers for your county. They often use ESRI, and you can type in the server address in the Vectorworks feature, and Vectorworks will request imagery from there. This also works with WMS servers.

That's correct. Also, higher resolution images, elevation information, and other analytic information (raster images only at the moment in Vectorworks though)

My philosophical view on this is that GIS is still as complicated, especially the coordinate system component of it. However, with the new feature, you can see if you are correct at all times as you can always use the Geolocate tool, and see how you drawing fit the globe. It's like before you only had to infer to other files to find the mistake, where now you can see the background from the beginning and know when you made it misalign. Your first step should always be to setup the CRS (coordinate system). This is especially true if you work with survey DWG files, which were the source of confusion and complexity before, as DWG doesn't carry CRS. This way whey you imported it in 2019, it would get moved to the center automatically and thus break the GIS. In 2020, you should setup the CRS in Vectorworks, then import the DWG with the GIS option on, and your data will land perfectly on the GIS. And, you can verify this by using the Geolocate tool. The Licensing/Copyright is always a concern when using geo images from services. This is true for ESRI or WMS servers. You should read the licensing for each service you are planning to you always and make sure you can use it in your project. The default satellite and map services that we use from ESRI come with a restriction on image download. This means that we will strip the images form the VWX file on file save. All other export or print will contain them. When you open this VWX file back up, you'll be able to see the Geoimage objects and update them to get the images back. So all the context is saved and the image can be just re-downloaded. In an SP release, we'll make it so the images will be saved if you are logged in ESRI user. Note, this is the same for the geo-image texture that we'll create for Site Models that have the option to texture with GIS image turned on. see above about licensing. we'll not save those images in the main release. SP will make those images be saved when logged in ESRI user. Then it will affect the file size depending how much pixes are being stored, which you have control over, trading size for image quality.

Hi @Clint Alderman, our feature uses the ESRI's map services to request the geo-imagery. It is not associated with any of the other ESRI's products nor QGIS. The feature is essentially asking for images a web service, and we default to ESRI's servers. You can also use WMS servers, and there are several free ones (note though, they still have some limitations on usage): https://wiki.openstreetmap.org/wiki/WMS You can experiment with ArcGIS Online: https://www.arcgis.com This is essentially equivalent of what we have in Vectorworks, only we talk to image services only at the moment. You can play around with this without making a user in www.arcgis.com, click on the 'Map' at the top. Once you log it, you'll have access to more services. Regards, Vlado

Hi Yves, we'll add more information in the documentation on this. While we do, please take a look at this for more information on the meaning of the parameters:

Hi @Jim Smith, I've played around with this file, and i think i can see the underlying issue. This a little bit a workflow issue. Of course, we have to tune up the feature to make it easy, but for the time being you can be mindful of this while using it. First, the align issue is that the PDF page is not rotated nor scaled to match the document in Vectorworks. So if you precisely draw by angle and length it will not match until you position, rotate, scale, and then position again the PDF page under your drawing. And then, there is the issue of clock-wise (CW) vs. counter-clock-wise (CCW) direction of the polygons. If you look on the left side of the PDF page, the lines are at N72°38'40"E and then it turns to N17°59'00"W. The first direction is CCW but the next one is CW. This means that if you draw the polygon of the Landscape are using these values, it will go the other direction than what's on the PDF. This is expecting, as you cannot have a single polygon with conflicting directions. So, for this file i would suggest the following workflow: - start of without importing the pdf, but have it in front of you so you can read the directions; - use the Property Line tool in the Bearing and Distance Mode; - enter the corners one by one using the bearing-distance provided in the PDF. With each corner you have to be mindful of the direction it is going in your drawing to match the PDF. if it goes the other-way as you expect, then go back one (with the 'Previous' button) and edit the bearing by flipping the direction (if 'N' make 'S' and if 'E' make 'W' or reverse), then click 'Update' so you can see the change in the drawing. The "Next' button will get you to the new one to be added again; - at this point you should have a Property Line that resembles the shape of the one on the PDF; - now you can import the PDF page - having the PDF selected, use the Modify -> Scale Objects menu command to adjust the scale of the PDF to match the drawing. You can use the dim-buttons to precisely match points on the drawing. - then you can use the cursor and protractor tools on the PDF object to position and rotate it to match with the Property Line. Here you will note that the bearings from the drawing not always match the PDF. You can use the 'Reverse Direction' checkbox from the 'Segments' group of the Property Line shape pane. But again, in your PDF they are not consistent directions. With a single Property Line polygon you can have them either CW or CCW. Of course, you can break it up into several Property Line objects and each can be set appropriately to match the PDF if that's important. I hope that helps, let me know if you have more questions. I'll see to adding a rectangle for the corner indicators, and think about how do we improve presentation of mixed CW and CCW property line segments. Regards, Vlado

Hi Jim, can you send me a test file, so we can see what's going on and fix it? Please send it to vstanev@vectorworks.net Also, i'll make sure we add the option for rectangles. Thank you for the suggestion. Regards, Vlado