Jump to content

billholt

Member
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About billholt

  • Rank
    Greenhorn

Personal Information

  • Occupation
    Engineer
  • Homepage
    www.notesoft.com
  • Location
    Louisville, Ky
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. 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.
  9. 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
  10. I've gotten the 20,2 error when I had some duplicated data points, which went away when the duplicates were eliminated.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.

 

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...