billholt

I haven't tested this with version 11, but I know that with earlier versions one thing you had to make sure of was that the boundary of the proposed dtm was completely within the boundary of the existing dtm. Otherwise an error occurred.

Glad to help, Charles. What most scared me about this one was the case where the azimuth was near 45 degrees ... in which case the user would likely not see the error. May I suggest, in addition to the DMS formats already available, that you include an implied DMS where the user merely leaves a space between each value: 45 0 30 instead of 45d 0m 30s. I'd guess you're already having to parse down to this to before converting to D.DD ... it would make input much easier; and easier is more reliable and more useful. This is a very nice tool developing.

Unless there's some sort of weird corruption in my installation, the PL tool has a serious, sneaky flaw. Entering an azimuth in the d.dd format creates a property line correctly (measured cw from north) while entering the equilivent azimuth in the DMS format creates a propertly line in the mathematical format (measured ccw from east). Here's an example. The INPUT for each boundary was identical, except that for one I used d.dd and for the other I used DMS format. This occurs even within a single boundary ... appears to be an error in parsing the dms entries to/from d.dd for internal calculation. SFAIK, the d.dd and dms approach work correctly when bearings are used instead of azimuths. Unless this is the result of some sort of corruption on my installation, I suggest that you might want to warn users of this problem until it is fixed. Some poor schmuck is going to put a building in a wrong place, and you can imagine how pissed off people get when they have to move their buildings after they're built.

Thanks Robert. I hadn't gotten to the point of exploring the PL tool yet. Still in a very steep part of the learning curve.

The "Send to Surface" command is proving very useful for a purpose that may not have been expected: preparing an illustration that a client easily understands, with property lines shown tracing the actual surface in a rendering of a site. It's similar to viewing an areal photo with property lines added by hand, but with the great advantage that it can be accurate, and viewed isometrically. My question - looking to get even more utility from this: Is there any way to use a proposed DTM as the surface that a 3D poly is sent to? If that can be done, I'll have a few clients wetting their pants with joy ... a good thing if you don't stand too close.

Allow me to clarify/confuse the issue further. I'm probably pushing the program a bit. My current filesize is meg, with no bitmaps of any sort - all hard data. Imagine that you have an existing conditions dtm. Then, imagine a "U" shaped "pad" modifier with the Z value set to indicate cut. Then, imagine a second, smaller in plan, "U" shaped pad, nested within the larger U, set to a lower Z value to indicate a step downward toward the center. No contact between them, of course. Finally, imagine a roughly circular pad in the center, set to the lowest Z value, to define the bottom of a proposed excavation. Initially, this all worked nicely. Each of the U shaped pads showed as benches, as expected, and the area between them was a regular transition. The area between the inner U and the center pad also showed a regular transition and the overall result was as intended. Then, I edited the xy shape of the center pad (bottom of the excavation). As a result, all of the transitional areas ... the areas between the U's, and between the inner U and the center pad ... lost the transitional charactoristic. That is, all of the "transitional" area became unaffected by the nearby modifiers and the surface of those parts of my "hole" is lifted back to the original surface. The result is that my U shaped pads now appear to be U shaped slots dug into the site. Fortunately, I save files as a series of proigressively named files ... but I don't know if I'm crossing a program glitch, a glitch in my fresh system, of if the result that I initially see, and expect to see, is actually the malfunction. Perhaps the transitonal areas aren't supposed to occur? But here's the spooky thing. A few minutes ago, while working with version 6 of my drawing - the last one to show a hole with benches and transitions instead of a group of slots - the fubared rendering appeared and then, when I clicked back to 100%, the "correct" rendering appeared. Another possibility that I know, by experience, to be a contender is that of "operator error." If that turns out to be the case, I'll report it here when I understand it. Added observation. Version 7 of my drawing is the last one to show the proposed surface in the configuration I want. It may, possibly, have been created under v10.5 of VW ... not sure. However, I've observed that all I have to do to see the fubared surface is to have the prop dtm regened - with no changes on my part. Perhaps someone would like to look at this file?

Trouble shooting .... I have seven versions of the plan, numbered. 1 - 5 are VW10 docs. (site plan5 is 4.3 meg) 6 - 7 are VW 11 docs. (site plan7 is 1.5 meg) Regenning the proposed dtm does not cause the blow-up in drawing 4. It _does_ cause the blowup in drawing 5. Therefore, the problem is not in the VW10 to VW11 transition but in something that has changed in the drawing. Checking drawing 4 vs drawing 5, element by element. Ah ha! The problem is the most common of problems I've encountered ... operator error. In drawing version 4, I have a "fence" coincident with the property line. In drawing version 5, it's gone. After replacing this item, everthing works in version 7 (VW-11) of my drawing. Nevermind.

re: "Check 3d polys will find duplicate points, or anywhere the drawing has crossover points." Is dup filter new to version 11, Katie? I woulda sworn it didn't happen that way in version 10.5.

The modifiers which shape my proposed dtm have shown a tendency to lose their effectiveness. What I mean by this is that after some small modification of a modifier, typically reshaping, the data points from the existing dtm will start to penetrate what had previously been a surface defined by the modifier and totally screw up the works. Is this new with VW11? OX 10.2.8 QD6.5.1 G3 machine

I've gotten the 20,2 error when I had some duplicated data points, which went away when the duplicates were eliminated.

Originally posted by Robert Anderson: quote: Bill, do you still have a copy of your original file? Would you mind sending it to me with a detailed description of your workflow? I'd love to have it for testing some filtering scripts. Thanks!Send me your email address and I'll send you the files and sequence.

Or, you can use the Print2Pic extension with the tiff PI to generate a high quality pic, and then use Graphic Converter to translate to jpeg. Mucho control. Minimal dinero.

Originally posted by Robert Anderson: quote: Bill, do you still have a copy of your original file? Would you mind sending it to me with a detailed description of your workflow? I'd love to have it for testing some filtering scripts. Thanks! I do Robert, but it will be a few days before I can send it off. My main puter gave up the ghost Friday. Now I'm just doing light internetting on my old 6500 and I won't be able to access that hard drive until my replacement unit gets here. Funny thing, in twenty years of using Macs, this is my second power supply failure ... or at least I think that's the problem.

Well, after eliminating something over 1400 duplicated 3D points, the dtm generates ... and looks pretty reasonable. I have to admit to being pleasantly surprised at the speed - 21 seconds on a 5 year old G3 Mac! I'm semi-amazed. There were 7451 points in the input. Clearly, the dtm engine is fast enough for serious civil work. I'll have to add some dummy points and breaklines to force it into a more reasonable interpretation in some of the areas where the data points are insufficient definition, however I'm delighted with the speed ... once the dataset is cleaned.

I imagine this has been addressed before, but I can't find it. VW10.5, mac 9.2 The error code I get is "misc errors, code 20,2" I'm trying to create a dtm from 3d contours that I've imported. On this iteration, I filtered the contours and replaced them with 3D points using the built in functions. Now, going back through this processed data in detail, I'm finding that there are quite a few instances where the 3D points, generated by these program functions, are duplicated. No wonder the dtm processor is choking. I think the duplications are occurring where the imported contours are represented as a series of polylines with ends touching. Since this is a pretty good size model, going through it by hand is not practical - there were over 100,000 3D points in the model when I tried it without filtering - about 9,000 now. Perhaps there should be a routine to check for, and fix, duplicated 3D points. If there's not one in the works, I'll write one for myself. Also, the routine that checks for polyline crossovers would be infinitely more useful if it placed a marker at each of the locations.

Originally posted by jnr: quote: Here's a thought: Why not give vectorworks ODBC capability ... I know for a fact that that has been on the request list since, at least, version seven. That was about the time that Filemaker Pro was obtaining ODBC capacity, and it could have greatly added to the power of VW. Now, in spite of the improved scripting, it's still true. With FMP Server and ODBC, VW might, relatively easily, achieve a system where one file can be worked on simultaneously by many people. That is a major step into the big time. On the down side, ODBC means more connectivity to M$ products which suggests, to me, an increased risk of things going wrong.

Sorry guys ... I failed to check earlier posts until I'd already posted the above. After clicking the button, I saw the " vectorscript to menu"thread of 01/28/04 which reminded me of the step I was omitting. All is working fine now. After seeing the 1/28 note, it took me less time to fix my problem than it did to post my original note. The benefits of reading the instructions.

My memory, that is. I have a script that I want to incorporate as a menu object in a custom workspace and am having trouble with the next step. However, I have done it before and think I'm doing the same thing now. Possible memory failure. As I recall, here's what I did before: Placed the script in the "plugins" folder with the ".vsm" on the end of the name. Fired up VW. Opened the workspace editor and saw a list of PI-scripts that could be drug onto menus. Did the dragging. Exited workspace editor. Now when I do this, no scripts show up in the left window of the workspace editor. Perhaps I'm forgetting a step?

Nevermind. I'll just do it via a seperate script.

First improvement is under your control: turn off the snap to grid and disable the keyboard toggle for that function via the Workspace editor. The snap to grid creates many snap points that are near-by whatever object you might actually want to snap to, but they're invisible. So, they're easily hit by mistake.

After something of a hiatus, I've recently upgraded to version 10.5 (from 8.5) with Landmark and Renderworks. It seems that VW now has the basic tools in place for serious civil design work, with reasonably reliable dtm processes, but the more detailed tools are very light. For example, the roadway design tools seem adequate for horizontal layout control, but the vertical design tools are limited to creating a representation of the existing profile - only a starting point. So, toward the question: Several years ago I started developing an external application (Filemaker based and X-plat) which facilitates doing the vertical design of roadways. With a simple script I can export the xy data from the profile graphic which is generated by the "Site Model Section" command in VW, but that brings me to within sniffing distance of doing something much more worthwhile. What I really need is the xyz coordinate set which the Site Model Section script must read and consider while it is generating the xy set it uses to create the profile graphic. However, the SMS script is compiled, and unless I'm just missing it, it didn't come in the uncompiled state as part of my installation. As a result, I can't add the few script steps I need to add to get the xyz coordinate set exported. And finally to the question: How do I get a copy of the script in the uncompiled form so I can add the necessary functionality? I guess the significance of this is pretty obvious: if I can receive 3D data from VW, then I can transfer it back into VW as a new polyline that can be used in creating the "proposed" dtm. This extends well to a drainage design package that I've also started work on. Here's a reduced screenshot of my work in progress. Thanks for any help you can provide.