Latest Contributions by DavidWasserman

Hi Bastien,  1. So do you need any input on number 1 then? It looks good in terms of set up splits.  2. It might be because you are using tileUV with setUpProjection. It might be texturing itself twice. The docs for example never show setUpProjection being used with tileUV. You usually pick one or the other. However you are not using projectUV, so I am not sure that is the issue (might be you were just testing the different projections to see what the problem was). If I was to guess, comment out BridgeSide (see image), it would go away. IF you don't want to comment it out, translate or (extrude if you want closed shapes) your texture literally 1 CM (t(0,.01,0)) up. No one will know the difference.  Just hope you don't need bridges with sidewalks. I would have to take a look at the BrideSide rules. EDIT: Scratch this, I am not sure BridgeSide does this.  PS: What I think is going on is just a problem I never had to deal with because the sidewalks were always extruded above the actual start shape.EDIT: were have determined the X. is the source of the shape conflict. I will see if there is another way to achieve the same result without creating a visible shape.  David ... View more

Hi Bastien,  Something I just realized is that if you put drainage in the street rule it depends on the street allocation settings too much, and it might make the rule very buggy.  My suggestion, is add drainage to the sidewalk rules because it will look better (connected to sidewalk), and not interfere with any other rule settings.  Sidewalk--> #Original      BridgeSide      set(sidewalkWidth,scope.sz)      set(sidewalkLength,scope.sx)      color( _ModeClassifier ("Pedestrian"))#If Display Thematics==Usage, goes to usage, if not, Thematic.      report("Cut/Fill.Total Sidewalk Cut/Fill Volume (m^3)", geometry.area()*Sidewalk_Height)      report("Mode Area (m^2).Pedestrian", geometry.area())      split(v,unitSpace,0){Curb_Depth: Curbs_Mass(false)                               | ~1: Sidewalk_Setup }      X. #Enclose Shapes for Printing Sidewalk--> #Revised      BridgeSide      set(sidewalkWidth,scope.sz)      set(sidewalkLength,scope.sx)      color( _ModeClassifier ("Pedestrian"))#If Display Thematics==Usage, goes to usage, if not, Thematic.      report("Cut/Fill.Total Sidewalk Cut/Fill Volume (m^3)", geometry.area()*Sidewalk_Height)      report("Mode Area (m^2).Pedestrian", geometry.area())      split(v,unitSpace,0){Drainage_Depth: Drainage|Curb_Depth: Curbs_Mass(false)                               | ~1: Sidewalk_Setup }      X. #Enclose Shapes for Printing‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Hi Bastien,  Wow I really like those dirt maps for the crosswalks...Can you share those? Or are the textures just modified in PS? I have been wanting something like this for a while as  a high detailed setting. Not sure if you can share those though.  1. This is getting to the point where I need to see the texture and code in question. If you are not using a texture, then I think you are right, the actual texture dimensions need to change from what they were. Is there any reason you are not using the actual asphalt rules? You could do something similar to the center line/ dashed line splits.  2. That code is not located anywhere near the lanes, and it is not super intuitive. These elements are defined at the very beginning of the rule. If you notice, it starts with u direction (along the street not across it) separating these features from EVERYTHING ELSE in the street rule (most of the code is actually dedicated to space outside of this section). You will have to add some split(v,uvSpace/unitSpace,1) splits to get something like this to work earlier in the rule (like in the sections below). I have not tried this in a while honestly, the 3D team ultimately did not want to try to add it as a feature (neither did I). @StartRule # split away the crosswalks at the beginning (if any) using the special UVSET 1 Street -->     #DeleteUV if texturing is off      case _uScale==1: #IF the Street is long enough continue normally.           report("Modal Preference (0 to 1).Bicycle", _BikeRank)           report("Modal Preference (0 to 1).Pedestrian", _PedRank)           report("Modal Preference (0 to 1).Transit", _TransitRank)           report("Modal Preference (0 to 1).Auto", _AutoRank)           report("Speed.Braking Distance (ft)",Braking_Dist)#Assumes Level elevation           report("Speed.Braking Reaction Distance (ft)",Brake_Reaction_Dist)#Assumes Level elevation           report("Speed.Stopping Sight Distance (ft)",Stopping_Sight_Dist)#Design Value is rounded to nearest 5 feet,Assumes Level elevation           BridgeMain           split(u,uvSpace,1){_crosswalkBeginWidth/10: Asphalt(true,1,"Auto")                            | _crosswalkBeginWidth  : Crosswalk( Crosswalk_Begin ,1)                            | ~1                             : StreetWithCrosswalkEnd }      else: #If the street is too short no stop lines, no bike boxes.           report("Modal Preference (0 to 1).Bicycle", _BikeRank)           report("Modal Preference (0 to 1).Pedestrian", _PedRank)           report("Modal Preference (0 to 1).Transit", _TransitRank)           report("Modal Preference (0 to 1).Auto", _AutoRank)           report("Speed.Braking Distance (ft)",Braking_Dist)           report("Speed.Braking Reaction Distance (ft)",Brake_Reaction_Dist)           report("Speed.Stopping Sight Distance (ft)",Stopping_Sight_Dist)           BridgeMain           set( Right_Bike_Box ,"false")           set( Left_Bike_Box ,"false")           set( Stop_Begin ,"none")           set( Stop_End ,"none")           StreetWithEntries # split away the crosswalks at the end (if any) using the special UVSET 2 StreetWithCrosswalkEnd -->           #print("DirLane "+str(DirLaneTotal))      split(u,uvSpace,2){ _crosswalkEndWidth/10: Asphalt(true,1,"Auto")                            | _crosswalkEndWidth    : Crosswalk( Crosswalk_End ,2)                            | ~1                             : CrossWalkGap}                            CrossWalkGap--> #This solution while imperfect and vulnerable to distortion prevents UVspace/UnitSpace conflicts from cutting geometry. User can adjust relative gaps to compensate.      split(u,unitSpace,0) {( Begin_Crosswalk_To_Stop_Bar ):Asphalt(true,1,"Auto")                                |~1:StreetWithEntries                                |( End_Crosswalk_To_Stop_Bar ):Asphalt(true,1,"Auto")} ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Hi Curtis,  This is something I just realized, but I am working in ArcMap 10.4. I just saw that this thread is ArcGIS Pro. That said, the error I got matches the one discussed here. Also if relevant this is over a network drive on a Windows 7 PC. I will try to do the same tool run on a local drive to check if that is an issue later. For now, I have resolved this problem for this project and will report back when I get another opportunity.  I will get a dialogue copy pasted when I get access, but generally I used the conventions for names that are outlined as standard practice as you suggested. I used the same paths for both Weighted Sum and Raster Calculator. The only difference was Raster Calculator worked. The paths for both tools were: N:\Projects\....\GIS\Working_Data.gdb\Fin_ActP_Ped David ... View more

Hi Curtis,  To follow back to this, it seems weighted sum does not have the same raster name validation as raster calculator. This is one thing I found. Raster Calc requires 13 character names.  Another thing I found is even when the name is less than 13 characters, this tool does not work. I have not tried reprojecting, but I have tried using raster calculator and it is working on the same data. I am thinking I will just elect to do this the old fashion way in raster calculator. It feels like a bug, but I could be mistaken.  David ... View more

Hi Bastien,  I am at working looking at CE.  1. It seems you have the centerline figured out for the most part. You could replace the texture with another rule that does a split(v,unitSpace,0) {PaintLineWidth: AsphaltPainted("yellow"....| PaintLineWidth: Asphalt(...| PaintLineWidth: AsphaltPainted("yellow...} 2. For this rule you need to alter the "ELSE" in this rule: ConventionalLane(dir,lanestotal,lanenumber,stopType)--> My Implementation looks like this:  Text Below:  ConventionalLane(dir,lanestotal,lanenumber,stopType)--> case stopType=="none" && lanenumber==lanestotal-1:# Makes sure with no stop type last lane has no lane with contiguous stripes Asphalt(true,1,"Auto") VehiclesOnLane(dir,lanenumber) Sharrow(dir,lanestotal,lanenumber) case stopType!="none" && (lanenumber==lanestotal-1):# Makes sure with no stop type last lane has no lane with contiguous stripes split(u,unitSpace,0){ ~1: Asphalt(true,1,"Auto") | 14: LaneMarkings(dir,lanenumber,_stopTex(stopType,lanenumber,lanestotal)) } VehiclesOnLane(dir,lanenumber) Sharrow(dir,lanestotal,lanenumber) else: # Makes basic lanes that that are not next to the last lane or a bus/hov lane (if they are on). split(u,unitSpace,0){ ~1: NewLaneLine("Auto") | _hasStopSideSwitch(dir)*14: LaneMarkings(dir,lanenumber,_stopTex(stopType,lanenumber,lanestotal))} VehiclesOnLane(dir,lanenumber) Sharrow(dir,lanestotal,lanenumber) NewLaneLine(mode)--> split(v,unitSpace,0) {~1:Asphalt(true,1,mode)|PaintLineWidth:Repeated_Lane_Dash(mode)} Repeated_Lane_Dash(mode)--> split(u,unitSpace,0) {~4:AsphaltPainted("white",true,1,mode)|~4:Asphalt(true,1,mode)}* Thanks,  David  PS: Bastien: I might make this a  feature of the rule down the line, but for now you might have to work with what is here. I would likely make it appear when set to anything by adding a "Very High" LOD setting and using splits like this on High or Very High, and only add vehicles on Very High. My first rendering with this really made it clear this could make outputs just a little bit more crisp, thus worth the effort. Thanks for bringing this to my attention.  ... View more

Hi Bastien,  Understood. Thanks.  1) Ah, I thought you wanted to just resize it. You could make a separate rule that copies the same code and at the beginning of it just make it smaller by splitting it first.  MakeShorter-->      split(v,unitSpace,0) {.05:NIL |~1:CenterlineRule|.05:NIL} #Example idea.  To make it larger than the center line is now you need start testing things like the offset function or re-scopeing the center line (but I am not sure how re-scoping would work on curves). See here for details.  2. Ok.  3. Sorry about that. A simple example would be a flat polygon. Lets say I want to have two extrusions inhabit the same space.  Lot-->     GeometryRule(0)    GeometryRule(10) GeometryRule(translation)-->     t(0,translation,0)    extrude(2)    color(rand(0,1),rand(0,1),rand(0,1)) Because you call the Geometry Rule twice, you have two different branches in the shape hierarchy that are both working on the same origin shape. In this case you should see one 2 M extrusion at lot level and another one 10 m above the lot shape. They are both operating from the same shape.  Disclaimer: Again, I don't have CityEngine, I might have to check this code later.  4. This is definitely a question I want CE to test...I can say I have moved options based on the geometry of the street. Generally, I believe the answer is yes, but I am not sure how curved streets would look if you are not using the original street shapes as a base (inserted disks vs. extruded or translated splits).  ... View more

Thank you Wendell. Any other thoughts on the feature are welcome.  ... View more

Hi Bastien,  Let me know if I can provide more help. I might be of more use when I have access to CityEngine again.  This makes a lot of sense...Actually it is an issue I have noticed generally in my renderings. My concern is introducing even more geometry splits into the rule. I will consider implementing this for a high definition setting for this use case.  Why do they need to be raised? That was something I am not sure I understand.  David ... View more

Hi Bastien,  Questions in order: 1. Yes. For other parameters it is adjusted based on the Center_Width parameter, but for the center line you need to adjust the constant set by the 'else:PaintLineWidth*4': const _centerWidth                   = case oneWay: 0                                           case Center_Type=="Barrier":.98                                           case Center_Type=="Barrier & Shoulder":Center_Width                                           case Center_Type != "None": Center_Width                                           else:PaintLineWidth*4‍‍‍‍‍ 2. Yes, but this is more difficult, and I can really only give you psuedo-code rather than specifics (I don't have access on CE right now-long story). The rules you are interested in is the "ConventionalLane" rule: LaneReporting(dir,lanestotal,lanenumber,stopType,laneType)-->      report("Lane Width.Actual Lane Width (ft)",geometry.dv(0,unitSpace)*Feet) #Used to provide lane widths in feet      ConventionalLane(dir,lanestotal,lanenumber,stopType) <---This rule‍‍‍ But more importantly, the rule that it calls to create those striping cases: MainLaneMarkings(dir,lanenumber,"_stripes_white") - for the lane paint not near the intersection and LaneMarkings(dir,lanenumber,_stopTex(stopType,lanenumber,lanestotal)) -  for the approaches specifically You will need to inspect these rules and replace them with Asphalt() and AsphaltPainted() rules.  For example for MainLaneMarkings- the code might look like this:    MainLaneMarkings(dir,lanenumber,markings)-->           split(v,unitSpace,0){         ~(Lane_Width-PaintLineWidth):Asphalt(true,1,"Auto")| #Might need to flip this         Paint_Line_width:AsphaltPainted("white",1,"Auto") # In the case of those with dashed lines see below.         } # For Dashed lines another rule like: #  Rule--> split(u,unitSpace,0) {~3:Asphalt(true,1,"Auto")|~3 AsphaltPainted("white",1,"Auto")}* #NOTE: I HAVE NO Access to CityEngine at this time, this code is not tested and is from memory. ‍‍‍‍‍‍‍‍‍‍ 3(ps): Yes. You have to call a rule twice on the shape where it called.  It would look this this:  CenterSpace --> case Center_Type =="Median":           Raised_Curb("Median",1)# IF a median, and this will be use dto make a different rule      ...         ...      else:                         CenterLineMarkings("double_"+ Centerline_Color )              CenterLineMarkingsModified("double_"+ Centerline_Color )# This one moves it up. ‍‍‍‍‍‍‍‍‍ Question for you:  What is the use case for it? Why is it important? I am trying to understand this, and I have some ideas why it might useful, but I don't entirely understand.  Disclaimer:  I have not access to CityEngine, I don't know how much of this code will work and I am going entirely from memory. Just treat it as a sketch.   ... View more

HI Wendell Dimaculan,  Since we spoke, I have been thinking about making it so the approaches could use string lists to control every turn arrow. This comes up with Synchro all the time, where people want precise control over the turn arrows. The format I was thinking about was having all following start from the center line: parameter value: "right;through;through;left;left" or even "right;through" (with the last recorded item being what is used for all following lanes).  Would this be useful based on your experience?  David ... View more

Hi Bastien,  I think I understand. This is possible, but I think it would require some extensive edits to how lanes/centerlines are represented. Essentially you would either abandon the current textures and use only the AsphaltPainted() (which would be modified to either translate or extrude  the texture in the air 2-3 cm) to create these features. An example is actually the rule below I use for testing different features of the rule (IE testing splits). It creates a new shape, and translates it up in the air 1 meter, colors it red. You could also use the rotation functions to make it so they follow a specified slope as well I believe.  Red-->          alignScopeToAxes(y)      t(0,1,0)      color(1,0,0)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ I will have to take a look at this if you need a more detailed code example. The rule makes a lot of design decisions around the assumption that these components are represented as textures, but that is no reason why they could not be further broken up in the rule to meet this use case.  ... View more

Hi Bastien,    Thanks! Let me know if you have any ideas for improvements! Good question. I actually provide an example of how to do this with the "Sharrow" rules. If you check this Rule:    ConventionalLane(dir,lanestotal,lanenumber,stopType)--> You will see a Sharrow() rule. This rule essentially calls this sharrow rule based on the bike lane settings, and does what I think you are asking (it extrudes a square a small amount to have the sharrow symbol show up as a separate shape). It is adding on top of the existing shapes, not changing them. You could do something similar with an edited version of the CS rule.   Can you give me some picture examples so I can provide some sample code?    Thanks,  David ... View more

Hi Thomas,  Thanks for confirming that this is a bug. It sounds like a SQL fish net is the only alternative. The only other alternatives is can think of is using OSGEO command line to potentially process the data before hand or transform it into a shapefile for editing in Global Mapper (which also is an imperfect process).  Marek if you can't do a GIS fix, your alternative might be the best approach. Thanks for reporting this.  David ... View more

Hi Marek,  On the GIS Side, would it be too much to perhaps just depend on the SQL functionality? I mean if you want to define zones for import, you could just have features within a grid boundary (or census block), be specified by a SQL query? Sometimes I just make the edits on the GIS side to get a smooth pipeline into CE.  Can you share the exact projection of the data you are importing?  Also on the python side, I might be missing something, but does the result change if you specify the specific file path/name of the FC you are trying to import using the setFile setting? (I don't use this function a lot, so it might be a silly question).  setFile(self, stringValue) Sets File field.  @param stringValue: the new value. [str] David ... View more