Hi,
I am trying to create are reverse curve (-R to +R) in PRT . I am trying to insert a spiral between the two curves such that for half it's legth the radius varies from -R to 0 and in the rest of the length the radius varies from 0 to + R. But however when i add a spiral between the two curves the change in radius along the transition is not as expected. The transition has an at the end of the firstt curve, an initial Radius of a positive high value and it gradually becomes + R at the start of the next curve.
When I try to create two spirals, there s no option in PRT to create a spiral from/to another spiral. Please do help me in finding a solution
Hi guys,
I’m a user of Powercivil (fP) 08.11.09.878. I have problem with CIVIL_XIN_FILE configuration.
I have already changed hundred times the path to my XIN. Unfortunately powercivil changes access to my xin into default XIN.
Yes, I saved ufc file.
Any idea?
Thanks in advance
psz
Check out this article on point coding, looks like the CloseShape linking code is what you need: 
When I exit a file in our PW managed workspace, I often get this a message box carrying this message. The dialog title is Bentley InRoads V8i (SELECTseries 4) so I am attributing this error to InRoads and not Project Wise. If that is wrong, feel free to move this post to that forum.
Hello,
I am using Power Geopak SS2 V8i.
I am working with Plan/Profile Sheet Composition Tool. I have tried to build sheets using this tool but am finding that the first sheet is built but then the program fails and does not build anymore after the first sheet. Also, sometimes the profile sheet cell is included in the sheet build but not always. I know I have selected the profile cell and I have selected the number of sheets specified in a file. What is the likely reason this tool is failing and does not build all the sheets nor adds the sheet cells?
Thanks in advance for any suggestions.
Hi Amita:
The dataset that is struggling was created in Power InRoads (SELECTSeries 4), so there shouldn't be a mismatch in the parameters, which is what is making it really strange. I'm happy to upload the alg., dtm, and xin that we have been using. to see if you can spot why it doesn't work.
What would be the best way of sending this to you?
Thanks,
Paul Tonkin
So we have an option to edit specific cross sections. I tried using it just now.
I have two cross section spaces currently open. When I right-clicked the cross section space I was going to edit, the cross section for the other corridor came up, and the title was as follows:
> Editing Template at Station 27+05.6803 R1 only
I canceled the operation and then right-clicked the other cross section space to edit that corridor's cross section. It had the same:
> Editing Template at Station 27+05.6803 R1 only
So I canceled the operation and then right-clicked the first one I wanted to edit. Finally, it correctly displays the station I was expecting, the material of that cross section, and the expected title:
> Editing Template at Station 39+74.9920 only
Using SS4 .878.
When GR-F-CLZ-L has an offset from EP-L locked at -20' (as shown in both screenshots above, for testing), this template processes as described above: the whole side slope is unbroken at 1:6, but at least some solution is found. The same is true when the offset is locked at -10'.
When GR-F-CLZ-L has an offset from EP-L locked at -30' (as the typical section calls for), this template doesn't process the fill condition properly and falls back onto that bogus condition that Rock-L is part of.
There are no other distinctions between (partial) success and complete failure.
It's clear to see that adding 10 feet to that 14' dimension won't cause any distinctly different solution, whether the further slope is 1:6 or 1:3, so why does it vanish?
I thought this might break the solution, but if the offset is locked at -10' as above, and I lock the vertical of GR-F-TIE-L to +1 from ES-L--meaning above the shoulder point--the 1:6 slope persists.
Using OR SS4 .878, I'm seeing strange behavior on this template drop.
The annotations here show that the slope all the way to a bogus terrain model (just for testing purposes) is 1:6. I have confirmed that the point at the left end of the 14' dimension is GR-F-CLZ-L. And you can see the flat element at the bogus tie location. (Normally it's right on top of the tie point, but as you can see I'm having issues and want to simplify the process of testing.)
Instead, it should be 1:3 outside of the break, as you can see from the template:
Point GR-F-CLZ-L has no end condition properties toggled on. It is locked into position by slope from ES-L and offset from EP-L.
Point GR-F-TIE-L (toe point) has all end condition properties toggled on (except do not construct). It is locked into position by slope from GR-F-CLZ-L (33%) and vertical from ES-L (not that this fact should matter).
FYI, the Rock-L point is for testing as well, as a fallback to test end conditions.
I have two drops of this template: the one I'm having an issue with is in a fill condition; there's another that has a cut condition and that one appears to be fine.
I'm using Power Geopak SS4 .878. My project started with international feet as my working and storage units but with coordinates matching survey feet. I've converted all files to survey feet using a VBA macro. I know that you can expect to get a message when attaching a survey feet file to an international feet file and vice versa, warning you that the coordinates are going to be off. I haven't been getting that message.
My existing DTM from survey is in one file. In my corridor file for phase 6, I have complex terrain model that serves to simulate the existing terrain at the beginning of phase 6. (This seems to affect other phases too, but at the moment I'm working in phase 6.) As mentioned, both files use survey feet.
I took a look at corresponding points out on the fringe. I measured the distance, which turned out to be exactly the value of the lower (southwesterly) coordinate*[(1-2e-6)^-1 - 1]. The factor here suggests that one file must be survey and the other international. But when I attached the files, no warning showed up. In the references list, I noticed that the DTM file scale is 1:1 whether True Scale is on or off. (Otherwise, when the units differ, it flipflops between 1:1 and 1:1.000 002, or between 1:1 and 1.000 002:1.)
To clarify, the survey DTM holds the larger coordinates. Something in the system (apparently) is telling the complex terrain that the survey DTM's points are in international feet. Therefore, the complex terrain model uses smaller values for coordinates.
Apparent root of the problem:
In my phase 6 corridor file, where I also have created the complex terrain model, my survey DTM is attached with 1:1 scaling. The complex terrain model is scaled down as mentioned, so looking at a fringe point, I see two distinct points: one from the survey, one from the slightly smaller scale. I have no explanation for this behavior.
Further exploration:
I took the time to get into VBA to confirm the units. In both the survey DTM file and the corridor file,
MasterUnit.UnitsPerBaseNumerator = 39370 MasterUnit.UnitsPerBaseDenominator = 12000
to represent 39.37 inches per meter over 12 inches per foot. Same for StorageUnit.
SubUnit.UnitsPerBaseNumerator = 39370 Subunit.UnitsPerBaseDenominator = 1200
to represent 39.37 inches per meter over 1.2 inches per tenth of a foot.
Any ideas on what might be the problem here? Any ideas on how to fix this?
I filed an enhancement request on your behalf
Enhancement 567681:Template editor point properties improvement
http://communities.bentley.com/products/road___site_design/f/5922/p/385245/editpost?ContentTypeId=1
I have some suggestions to improve the user experience of editing templates.
When you doubleclick on a stack of components, it gives a 4-entry list. You press the escape key to advance the list (which fact is not obvious or even suggested at). The interface should be a little more obvious, and why not list more than just 4? Anyway, as you mouse over each component's name, the linework for that component is highlighted.
An improvement to this would be to "bring to the front" all points that belong to that component and highlight the names of those points.
When looking at a point's properties, there is a list of components of which the point is a member. When I click any of these entries, nothing happens.
I feel like when I do that, it should highlight the component's linework and the other points in that component in the same way that, above, I'm suggesting should happen when you are selecting the component. Additionally, I feel like the interface should list other points in that same component. The list of points should be listed in order along the component's surface. Furthermore, I should be able to double-click each one to edit that point.
We should be able to rearrange these points, so that if one of them is out of order, I can just shift it into the correct position. It's conceivable that the implementation of this last recommendation should be an option in the component properties, but I feel like (if it can be in only one or the other windows) it would be better to belong in the point properties window. As of right now, in order to do this we have to open the ITL as an XML file and rearrange the vertices. Since text editors often don't handle such immense files as ITLs, I'd rather be able to do it within the interface to reduce corruption.
I have instructions for how to display features In cross sections for SS2 but the commands no longer are there in SS3. I need to display these features in my SS3 cross sections imported from my surface. How do I go about doing this?
MicroStation V8i (SELECTseries 3) - Version 08.11.09.714 Windows x86 with Bentley InRoads V8i (SELECTseries 4) V08.11.09.845
The XIN being used probably originated in an earlier version. I am very comfortable working with an XIN file in an editor, like Notepad++. So I went looking in the file and found that in the header for every preference are the following attribute assignments:
EventOmitInCurves="0"
HighPointOmitInCurves="0"
LowPointOmitInCurves="0"
POVBOmitInCurves="0"
POVEOmitInCurves="0"
PVCCOmitInCurves="0"
PVCOmitInCurves="0"
PVIOmitInCurves="0"
PVRCOmitInCurves="0"
PVTOmitInCurves="0"
However, in the interface, only the PVI leaf has an "omit in curves" toggle. Are these normal?
And today, when I used the tool, although it took almost a full minute to annotate a profile, the Omit in Curves setting seemed to now work as designed. Trust me, I tried multiple times and with different preferences yesterday before posting. Chalk it up to Gremlins.
I saw that one of my CR's made its way into Ss4 - to allow annotating PVI with its curve data when there is a curve, and to omit it at its actual location. However, what I am seeing occurring is the following:
If I enable the Omit in Curves toggle on the PVI leaf, only the initial PVI is annotated. If I have also enabled POVB & POVE, they too do not annotate.
The only way I can get the non-curve PVI's and the POVB & POVE to annotate is to turn off the Omit in Curves toggle and then every PVI gets annotated. But the Curve PVI's get annotated twice - once at their location and again within the curve data.