Quantcast
Channel: OpenRoads | OpenSite Forum - Recent Threads
Viewing all articles
Browse latest Browse all 19084

[Ss2 & Ss3] Civil DA vs Civil Survey Scale Issues - XIN based.

$
0
0

While our Primary client is still not even 100% into XM, we are attempting to move forward using modified versions of the XIN files from their workspace. In those efforts, I am trying to get DA in Ss2 and Survey in Ss3 to run using Annotation Scale. It would appear that the cells work in Survey SS3. In DA ss2, the cells are defaulting to 50 Scale, no matter what I try to prevent this.

In Civil Survey Ss3 I find I must set my annotation scale to 1" = 1' prior to import if I want my non-annotative scale cells to come in at 1:1. Other wise, they come in at the current annotation scale. Once they are imported, I can change the annotation scale and they remain at 1:1 and the annotative cells and non physical linestyles scale with the annotation scale. I feel like the annotation scale should never have any effect on the non-annotative scales.

Among my tools for working, maintaining and testing, I have an XML report that writes out a TDS RAW file using every Alpha Code in an XIN file. It sorts them alphabetically, by alpha code, which makes it easier to figure out where in a list the problems are. It also places two points for each code and on the first point, if the code is set to Draw Line to Previous Same Code, it places an ST on the first point of the pair. If the code is not set to Draw Line to Previous Same Code, but is set to Draw Connecting Line, it adds a JPT<point number> on the second point of the pair, indicating the number of the first point of the pair as the JPT point..

The resultant file, when imported can help me determine if everything is WAD in any XIN file.

I already have a CR in to allow the use of unmodified InRoads codes via a configuration variable. But I would like to point out the issues as this exists.

ST is the default start code. In my RAW test file, when I try and place two points, 100 feet apart with the codes BRST, the first point works. However, the second poitn gets coded as BR with a ST code.

Next in my alphabetized Alpha code list is MISCPT. In this instance, both points gets coded as MI with two link codes StartPC and ArcPT. Next to error is PAST. As in BRST, the first point is stored as coded correctly but the second is stored as PA with an ST linking code. The next error is on my points coded as POST. In this instance, both points are coded as PO with an ST link code.

The next Error is on TPC - both points are coded as T with the linking code of PC. The final error is on my points LOCUST. Again, both points are stored as LOCU with a linking code of ST.

For one point of a point pair to not fail while the second point does, is hardly what I would expect. Also, from what I read in the help documents. Many more codes should have failed. The help file states that alpha codes cannot contain any linking codes and uses STEP as an example.  Since I have STEP, I am actually glad the help appears to be in error - especially since along with STEP, we have STANK, STAR, STONE and STUMP.  And that's not even taking into account our PSTOPB, MASTARM, PTREE, BRSCP, MISCBL, UGELECSHA, etc. which contain ST PT SC CS. There may be more, but you get the idea.

One last question - is there a way to refresh the data already read? For example, we edited the XIN and want to update the graphics. For a real life example, today, we had a brief power break and my laptop remained working and my connection to the DGN was not lost, but my connection to the standards drive was lost briefly and now all of my linestyles are missing. 


Viewing all articles
Browse latest Browse all 19084

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>