Latest Contributions by DavidWasserman

Hey Majdi, Thanks this is what I was looking for. I felt like it was a CSS option and config I just did not see. Do you know where this element of the config file is documented? My final solution was to edit the field infos field as you suggested, but edited the CSS option to look like this: .dijitTextBox {     width: 100%; } .claro .dijitTextArea {     height: 90px;     width: 200px; } The final box was this: Thanks again everyone! I still need to add a button for submission next to delete (instead of depending on the close X to save it). If anyone has any thoughts on this I can open it as a new question down the line. David ... View more

That should do it. This is why I asked if it was procedural models, but reloaded models I think still need to be imported at the beginning of a scene. Your polygon count was fine. 😃 Glad everything is working. ... View more

Hey Valerio, Can you take some screenshots of the scene window for us? Are any layers locked or special in some way? Are these procedurally generated or imported building models? David ... View more

Hey Scott, Getting the symbols to adapt to short segments has been on my todo list for a while. The short answer is there is no immediate way to do this perfectly without editing the CGA. Something you can try is to simplify the segments that don't have curb cuts, or you can try replacing the bike lane with a buffer that is set to shoulder or asphalt. I can take a look at this when I get home, but for now try simplifying segments or experimenting with various buffer options strategically. HOWEVER, because these are driveway entrances, on the shorter segments it might make sense to use the conflict spacing to denote the bike lane and push all the bike symbols back. This may not work, and did not in my case. I think I will take a look at this later. David Edit: Hey Scott, you get to be a tester. Download the most recent rule update and try and use the conflict spacing. Let me know if the symbols go away this time or if it creates any other problems. ... View more

Hey Ronen, There is another way to make drive way entrances that look very similar to the real thing. What my friend Steve Rhyne​ has done in the past is draw really short segments along the main road way and give them 1 lane width street widths with no sidewalk/crosswalks, etc. While this does not make the ramped driveway, it does represent land access fairly well. Generally the easiest way to do this though is to use the Sidewalk Left and Right parameters and use some of the sloped roof functions to create a ramp cut. I will say though arranging this can be pretty difficult if you want to interact with other sidewalk components. David ... View more

I misunderstood then. Thanks for the clarification. ... View more

This is a mapped attribute problem then, I am pretty certain of it. So I ran into this problem when I was doing data driven cross-section creation not to long ago, and this is an issue a lot of the street rules have. Essentially, there is the shape parameter that actually changes the street width, and then there is the object attribute "streetWidth" that you might actually be using from the mapping starting point. Essentially, you need to adjust both the shape parameter and the object attribute that is mapped as "streetWidth". The reason for this is that the street rule is reading the mapped "streetWidth" attribute over the manually edited shape parameter. You need to make them the same number...it is annoying yet necessary. The street thinks it is less wide than it actually is because the mapped object attribute is saying it is. The reason why the flag function works is that it is geometry function dependent, the reason best fit won't work is that it is streetWidth value dependent. The reason the rule is not geometry function dependent everywhere is...complicated... ... View more

Hey Scott, That should not be happening, I will have to check this out. Can you send me the values of the rule parameters you are using? I notice the parking lane is 1 meter wide? Are you trying to represent a wider lane? If so I would suggest instead using the bike buffer setting, and turn it to asphalt. As a side question, are you using mapped shape parameters? If so did you change the object attribute value AND the street width parameter value? When I try to replicate, I don't get those issues with the parking and center turn lanes. On my end, the best fit setting is functioning as expected. This is however a non-mapped network and being just drawn. As an experiment can you draw me a street from scratch and try the same configuration? David ... View more

Hey Daniel, Interesting. I am not sure if I lock it on Parallel, but if not that should work. It won't have the lines you would typically expect on 90 degree parking, but it might look ok. Good luck. David ... View more

Hey Daniel, Complete Street Rule Update In the updated rule above, I think that angle parameter is hidden at line 316. Older versions of the rule have that too. Something I should say though is that the texturing assumes SOME TYPE of angle. You can make the cars 90 degrees, but I am not sure the texturing underneath will change. If I have sometime I can investigate adding this to the parking options. I never thought to do it though because 90 degrees is...very rare on a street environment because of the visibility issue on pull out. It would require different splits, but if you use the ApshaltPainted and the Asphalt Rules it can't be that hard to replicate. Relevant angled parking parameter code here: @Order(8)@Hidden @Range(0,360) @Description("When parking is angled, this determines the angle of the vehicles placed in each right side angled parking spot.") attr Right_Parked_Car_Angle = _Right_Car_Angle @Order(9)@Hidden @Range(0,360)@Description("When parking is angled, this determines the angle of the vehicles placed in each left side angled parking spot.") attr Left_Parked_Car_Angle = _Left_Car_Angle David ... View more

Hey Ronen, The Complete Street Rule supports two-way left turn lanes and median planting strips, but at the moment does not support driveway cuts. This is something I have seen done before though by Micah Taylor​, he might have some thought to share on the subject. David ... View more

Hey Nina, I might have missed this, but I am interested in ROW mapping. Do you think you could post some information about the follow up meeting from this? Are there any handouts you can share with people who missed this meeting? What level of detail does ROW Mapping go into? Is it asset mapping by record or is it lidar information? Also please feel free to email me at d.wasserman@fehrandpeers.com​. Thanks, David ... View more

I will give this a try and come back. I got sidetracked by other projects, but this might be what I am looking for. ... View more

Hi Rickey, I have been marking responses as helpful, including some of your comments. 😃 I usually reserve the correct answer to when the issue is fully resolved. I will mark some of the new ones though, so thanks for the reminder. David ... View more

I think focusing on proposals is a the key aspect that people pay attention to. I think if you have good foot prints like you do, the other stuff can fill itself in. So this is an interesting question. The building shell rule is great if you are ok with a random texture as opposed to the one that the model might have came with. I have used the building shell rule to make zoning breakdowns of the building, but also to have higher resolution textures than some planimetric models come with because they look better at street level. I will say that once you apply a rule like building shell to a 3D models the number of options you have increase. Generally there are 3 options that I know for most applying rules to most building/land use models: 1. Lot rules that make a building from a simple property lot, includes setbacks. 2. Footprint rules make buildings from the building outline and extrude it up, texture it, and manipulate it for certain purposes. 3. Shell Rules that essentially allow you change how the imported building looks like by splitting it into floors, texturing it, and even color coding it by land use function. What is interesting about this hierarchy of rules, is that the closer you get to a shell rule, the less flexibility the rule has about changing the geometry of the original initial shape. This is largely because the ability to both orient yourself spatially in CGA (the programming language for CityEngine) and make decisions about what information you can get from the shape becomes increasingly complex with more edge cases. So a lot rule has a lot of flexibility to fill in setbacks, orient to the street, and do a lot of interesting things from a basic starting geometry. Foot print rules have a lot of flexibility vertically, but because there can be so many different edges on the geometry it can sometimes be a pain to reliably orient the foot print to other assets (it is possible though, there are many geometry functions that can help). And finally shell rules rarely if ever change the original geometry of the building because a planimetric building is already pretty close to reality. So to answer the question, what you are doing with CityEngine and which model choices are better depends on what you are trying to do. Maybe you want the flexibility of lots to make custom proposals, or you have work flow that achieves a similar goal with footprints (see Bergmann Associates for examples in Rochester NY). And on the flip side maybe you want the realism that comes with planimetric models (and have money to buy them), and you just want something that you can put into a City Model. It depends on the end goal. 😃 ... View more