Latest Contributions by CherylLau

Actually, I'm not exactly sure what your shape setup is, so it is hard to know exactly what the problem is, but maybe the following information will help you find the problem. One guess is that the shape that you start with when HospitalYard is called is a different size when the parcel is a different size.  When the columns are translated, they are both translated relative to the scope origin, which is the same as the scope origin that you have for HospitalYard.  If the hospital building size is varied or it is placed on the lot, say by centering it on the lot, then the columns will not have been placed relative to the building.  I'm actually not sure this is what's happening though.  Basically, I would suggest placing the columns relative to the building. You can use relative translations by putting an apostrophe in front of a value in the range [0,1].  Then, you can translate the columns relative to the building size.  For example, this is useful if you know that you want one column to be at 20% of the building width and the other column to be at 80% of the building width. t Operation  You can also access the scope widths to calculate relative positions, which is necessary if you want to center the columns exactly at 20% and 80% of the building width.  Here is an example which creates a building that is 5x5m with columns that are always at 20% and 80% of the building width.  This doesn't change when you change the lot or parcel size that you start with.  The columns are still at 20% and 80% even if you change the building width. const building_width = 5 const building_height = 0.2 const column_diameter = 1 const column_height = 7 Lot -->      primitiveCube      s(building_width, building_height, building_width)      center(xz)      Building       Building -->      Mass.      t(0, building_height, 0)      Column1      Column2       Column1 -->      t(0.2*scope.sx - 0.5*column_diameter, 0, 0)      Column       Column2 -->      t(0.8*scope.sx - 0.5*column_diameter, 0, 0)      Column       Column -->      s(column_diameter, column_height, column_diameter)      primitiveCylinder ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Also, note that the following commands are equivalent. t(1, 2, 3) translate(rel, scope, 1, 2, 3) ‍‍ Therefore, you can combine your translation amounts into a single command using t(). I noticed that you're translating in the y direction, but I'm not sure this makes sense to me since you probably want to position the columns using x and z.  But, then, I don't know your shape set up and how the scopes of the shapes in your shape tree are created.  You can try to debug and understand the scopes of the shapes you create with your rules using the Model Hierarchy (Window -> Show Model Hierarchy -> Inspect model -> Select object in viewport).  Then, you can select a shape node in the shape tree and see what the scope of it is in the viewport. ... View more

No, I can't think of a way to do this in Python either, unfortunately.  Sorry.  (But, that's not to say that a workaround absolutely doesn't exist.) ... View more

This video is about created an elevated rail guideway: Rule of the Week 9: Elevated Guideway - YouTube  ... View more

That seems strange.  I just tried to align some terrain to a street shape in 2017.0, and it worked for me. Does this also happen when trying to align the terrain to polygonal shapes (for example, a rectangle or polygon drawn with the polygon draw tool) instead of street shapes? Would you mind posting your CityEngine project? ... View more

Actually, now that you mention it, you could just change the coordinate system.  Edit -> Preferences -> Scene -> Scene coordinate system. But, if you want to put the contents of your scene into another existing scene that may already have stuff in it, then you'll want to do the export/import approach. ... View more

Sorry, sadly, no, it is not possible to access sidewalkWidthLeft and sidewalkWidthRight similar to how you would access the street width (as above).  The sidewalk widths are stored in the street segments and the street shapes, and the sidewalk attributes do not get transferred to the dynamic lot shapes like the street width does. Yes, the street width is only for the street part and does not include the sidewalk.  I do understand your use case and that it would be nice to know how wide the street is including the sidewalks, but unfortunately, I don't know how to get that info. ... View more

Note that to access the streetWidth object attribute, you can create a rule attribute with a parameter for the index like this: attr streetWidth(i) = 0‍ Then, you can access the street width values by specifying the index as the parameter: print(streetWidth(0))     // print first street width in list‍ ... View more

Yes, you can get the street width values by creating a rule attribute that takes a parameter like this: attr streetWidth(i) = 0‍‍‍ Then, you can access the values by giving the index as the parameter like this: print(streetWidth(0))     // print first street width in list‍ ... View more

I was thinking to use comp with the = operator to get the end faces in a single shape.  You could do this by assigning NIL to all the other sides, and then using all= to get the end faces.  And, you don't have to worry about normals.  Then, you can use inside() to test if both of the faces are inside a building.  Then, you can "recreate" the bridge by inserting a primitive cube into the scope, which replaces the two end faces with a cube. Of course, there are multiple ways which you could create the bridge, and I imagine, maybe, you found another way. ... View more

On second thought, when I read your other post, I realized that doing setbacks of different distances according to street width is not that easy, especially when you have lot shapes with rounded corners.  Here is the link to my reply to the other post: https://community.esri.com/message/717450-select-a-range-of-edge-index?et=watches.email.thread#comment-722294  ... View more

With regards to your larger goal, unfortunately, I don't know of a good way to do this.  It's not possible to make a single setback with different distances on different edges.  If you do one setback followed by another setback on the remainder, then you might accomplish what you want for somewhat rectangular lots.  However, as soon as you have the rounded corner with many edges that are all considered to be part of street.front, then you have to choose a single setback distance to get a nice result.  Otherwise, if you try to do multiple setbacks, then you'll probably get something ugly and unintended like this (so I'm not sure if recursive setbacks will solve your problem) (and, also, minor disclaimer: this screenshot has the second setback on street.front, so it repeats a setback on the first edge, but it serves the purpose to show that a result would be ugly): With regards to grouping indices, no, sorry, it is not possible to group indices for use as a selector in either setback or comp. Sorry to not have better news, but maybe someone else has an idea for a workaround. ... View more

I don't know about Pro or GeoPlanner, but you can certainly export object attributes when you export the shapes, for example, to a GDB file.  Make sure that "Export object attributes" is checked in the FileGDB dialog. Esri FileGeodatabase (FileGDB) Export  ... View more

Thank you, geoinformacao, for your information.  It looks like this is a bug, so thanks for helping us find it. ... View more

Generate Bridges tool Consider these two streets which seem to cross each other but don't actually intersect (there is no graph node at the intersection).  One street is the elevated bike path, and the other is the busy road underneath the bike path. If one street has a smaller street width than the other street, then the Generate Bridges tool will automatically decide to put the narrow street at a higher elevation, making it the bridge. Alternatively, you can specify which street is at which level through an object attribute.  This might already be specified if you've downloaded OSM data.  Select the graph segments you want to make into a bridge (the bike path), and create an object attribute called "layer" with the value 1.  You can optionally create the object attribute "layer" on the other graph segment and set it to 0.  If there are other graph segments, you can specify different layer numbers.  For example, if you have yet another road on top of the bike path, then you can set layer=2 for that road. Select the streets and run the Graph -> Generate Bridges tool.  The bike path will be elevated 5m above the road since Level height = 5.  The object attribute called layer is used to determine which street is on top of the other. In the Complete Streets example (Help -> Download Tutorials and Examples), the Complete_Street.cga and the Advanced_Street.cga rules both offer options to create bridges with pillars underneath.  The Bridge attributes can be found in the Inspector. Here is the result of applying the Complete_Street.cga rule to the bridge. For more information about the settings, please see the help docs: Generate Bridges  ------ When downloading streets from OSM, it is likely that you already have an object attribute that specifies which level each street is.  Look for this object attribute which says the ground street is 0, the first level bridge street is 1, the second level bridge street is 2, and so on.  You can set this attribute in the Generate Bridges dialog where it says "Object attribute for level".  There is another setting called "Object attribute for absolute height".  You have both of these set to "height", and the latter might be overriding the first.  If there is another object attribute which specifies the street level, then, I would change the first setting to be the name of this attribute.  If there is an object attribute called "height", which you don't want to use, then I would set the second setting to an empty string.  Also, you should make sure to select both the ground streets and the bike paths when running the Generate Bridges tool. ... View more