Jump to content

timking

Member
  • Content Count

    9
  • Joined

  • Last visited

Everything posted by timking

  1. VW 2017. Don't know what we're missing here or if it's broken. No problem creating a set and saving it. No problem editing it - but when we save, the edited version disappears leaving only the original set. Can't delete a set (well, we can, but when you go back in later it's still there). So by the end of a VW version cycle you might have masses of these things stuck in the system. Sets seem to attach to an individual install ie they don't travel with the file. They can't be exported so that we can use them as a shared resource. I must admit, I was expecting VW to save these sets as simple xml's or something, the way it handles other similar resources. But damned if I can find where they're hiding. In short, a fabulous feature taking VW much closer to GIS while being able to remain in a vastly superior design environment. But not being able to use these sets in a workgroup environment or even manage them sensibly puts a real limit on things. Please tell me all I need to do is....
  2. Thanks Benson. Nice set of questions, most of which I could tick off quickly. Pads v contours and possibly Z looked like where the problem was. Checking the modifiers carefully 1 of them was set to 'angle' instead of 'none'. Ha! I thought, a Z problem. But no. Then I redrew the Grade Limit poly to intersect as much as possible with the existing contours at a vertex. Don't really know why - just thought if it was having trouble figuring out an intersection point and elevation a vertex might be easier to recognise. Call it operator's white magic. And it worked! So is that a rule? (or just a quirk of this particular file, like its size? - 35ha and 40-50MB for the site model itself) An interesting observation from going through the process in minute detail though was that when you create the modifier (contour) from a poly (as opposed to using the Site Modifier Tool) you enter an elevation. If you then select the modifier the OIP says Z=0. 1 more step to fix it. Anyway, problem solved. Thanks for the questions ;-)
  3. Ok. I see that the images appear in-line and don't have their file names. Ignore the 2 small examples - they just show when we do exactly the same thing to a small set of contours it works as advertised. Subset of the same site model. The larger images - if you look a Model - exist.jpg you can see the modifying poly's (red) and the Grade Limit boundary (also red). The existing site model has orange majors (5m) and grey minors (1m). Model - propose.jpg is the result. In the proposed model, looking from left to right, it's almost as though instead of grading evenly from the 1st modifier to the 2nd, VW leaves a hunk of the original terrain in the middle and then tries to make good. The higher modifiers are better, I guess because at this stage there's little original material between contour modifiers, but there's still a bit of the same messiness going on. In the early trials we drew the Grade Limit poly from contour to contour ie intersecting each contour with a vertex. This version uses a simplified poly. Result pretty much the same. In the interim we've manually adjusted the original model so we can work the overall design, but this doesn't give us eg cut/fill volumes, or a fast way to tweak the reshaping in response to the developing design. Any light you can throw on matters very, very gratefully received. Thanks: t
  4. Can anyone see what we're doing wrong here? Attached screen shots Model - exist & - propose. The 2 test images show that it works for us at a small scale. The existing site model is about 40MB, covers about 35ha. It's only a small part of it that we want to change. Grade Limit poly is hightlighted. You can see VW doesn't want to throw away any rock and builds these little mounds between the contours that include all of the elevation I want to get rid of. Commendable frugality - just not what I want. Modifying contours created through the Create Objects from Shapes > Site Modifier > Contour dialogue Of course, the 1st thing we do in these situations is go back to JP's SST manuals. But following instructions meticulously and repeating our methodology on the small sample model produce the same results - correct on the small 1, hopeless on the big. Just hoping it's an obvious and elementary rule we're breaking... VW 2016. Gear used is an HP quad-core Xeon, 16MB and Quadro K4200, so that shouldn't be a a problem.
  5. A postscript - solving the issue WITHOUT SCRIPTING!! The answer was in (re)discovering the Plugin editor. The Property Line tool was close, it just needed several extra fields. It produces a report with a few clicks and the data in that can be export to an Excel sheet via odbc. We now don't need an external database - Excel is fine for the full development model. All the other features of modifying by record also seem to work for what we want. The Plugin Editor has now gone to my all-time favourite VW feature! t
  6. Yes, worksheets and classes is how we do it now. This gives us a whole lot of information which we manually take out to build a 'development model' (consisting of all sorts of things like market factors, development period, cost of finance etc). External database. Hence my idea to use records (which also gives me the chance to manipulate some of the geometry from within the record. The 'design model' (ie the shapes within VW) is constantly changed, so I really don't want to do any of this manually. I think we've maybe found the answer by scripting, but jeez, my eyeballs are beginning to bleed. I didn't sign up for this. To paraphrase Goebells (I think) - When I see the word 'Scripting', I reach for my gun. Suicide, obviously - Tim
  7. I was hoping to avoid any manual cut and paste. We're urban designers so there'll be thousands of shapes to manage, and it's the constant changes as a design develops we want to capture. So I take it you're also suggesting we can use a worksheet to return all the geometric quantification (area, length, perimeter, etc), then the record field is referenced to the worksheet cell. Correct? We're beginners at this - can't find the method for referencing. Help? Might be worth mentioning we're exporting the record data to an external database. Tim
  8. Just getting into records to build external development models and have a problem. I have a polygon, say, and want its area to appear in the 'Area' field. I can type it in manually (long and boring when there are '00s-000's) but this is hopeless once the poly's start to be resized. A Property Line report does it, and if I could link a cell there to the record field maybe that would be ok? But a bit clunky, and I also want to do the same thing for other qualities such as 'length', perimeter', etc. Surely there's a nice simple solution? Tim
  9. Hi Matej: I think this is a 2010 bug (haven't tried it in 2009). This is the behaviour I get on Mac and PC (XP and 7, 32 and 64) versions. My workaround is to export the model back to v12.5 where I can continue to cut sections till the cows come home. cheers: Tim

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...