|
DOC
|
Hi Dalilia, The most recent upload to github has a back saved toolbox. Let me know if you have any further problems. When making updates I forgot to back save the toolbox after I uploaded it. Use the github DOWNLOAD link and you should be fine. If it gives you any further problems let me know. Your folder structure is fine, this was something I forgot to do. David
... View more
11-11-2016
09:50 AM
|
0
|
0
|
5855
|
|
DOC
|
Hey Dalilia, There is a help document in the folder, but past that the main steps are to download the scripting tool and open the toolbox in ArcMap. You will see a scripting tool that you can connect to data. You can then experiment with the parameters in the scripting tool. This tool does not require any coding on your part. If you encounter any bugs, I am open to trying to fix them. Make sure to keep the releative location of the scripts folder and the toolbox the same. IE the toolbox should be in the same folder as the scripts folder. To cut the road every 10 KM WITHOUT Best Fit, you could unclick Best Fit, and assuming your projection is in meters set the segmentation number to 10000. You can also calculate the number of segments it needs to be as a field and use a different split method. If not this, densify with split line at vertices is another option. David
... View more
11-10-2016
01:47 PM
|
0
|
0
|
5855
|
|
POST
|
Hi Dulini, This comes back to what I mentioned before about not being able to move back up the shape hierarchy. The information about the footprint area is not capable of being piped back up to the parcel level where footprints are being determined. I could be misunderstanding the exercise still though. It might be possible to modify one setback or all the setbacks by doing a setback a very small amount and look at the change in area between each setback. I am thinking you could get the information you need at basically the parcel level to make a guess on the setbacks... This won't be exact, but you could theoretically use some combination of the geometry functions (perimeter-area ratios, planar vs non planar polygons) to develop some type of heuristic for what the marginal setback area does to the footprint area you are trying to achieve. This could be fairly simple for rectangular polygons, but less compact shapes would become increasingly difficult to predict/extrapolate how changes in setback impact footprint area. Again this would not be exact, but could lead to limited yet workable CGA solution...This is just an idea for an approach not an actual implementation (I can take a look at it later, might be just an idea). Idea would be: attr frontsetback_area_change_per_increment=0 #Assumes change in area would be constant per increment attr function_track_change(params)= do_stuff Parcel--> SetbackFront(geometry.area()) SetbackFront(parcelarea)--> Setback(.1) {front:PreParcelCalc1(ParcelArea)} PreParcelCalc1--> frontsetback_area_change_per_increment=parcel_area-geometry.area()/.1 (change) Setback(.1) {right:....} This looking at it, is an interesting idea, but I could see some pretty ruthless criticism on the complex geometry side of this idea. Clearly reductions in area to a setback would not be linear in a lot of cases and doing this for multiple setbacks could bias the area calcs with previous changes in geometry. Also the smaller the number you use for the setback the more likely floating point arithmetic is going to be annoying to deal with. I am not even sure the idea works because the the interdependence between all the setback areas (a front setback done first would reduce the marginal area reduction caused by a side setback). There might be some way to account for that. Other solutions involve using loops/recursion in the python API to look at your reports for footprint area after a generation and adjust the setbacks accordingly. This would generalize across geometries.
... View more
11-10-2016
12:36 PM
|
1
|
1
|
3489
|
|
POST
|
Ah then my first suggestion might not be in that direction. I saw an earlier thread you participated in and that had some more context. There are rules that do something like this that might be a good model. I think in the Complete Streets 2015 Project there is a Target GFA rule that does something similar. One idea is to use the information about the footprint and you have a target far, it might be possible to round the height to the nearest resulting area. If you want to get fancy, you could even try to have the last floor deal with rounding error with additional setbacks based on the ratios of area loss from the first set of setbacks (maybe, it won't be exact, nor should it be, buildings don't have 10 square foot top floors). The rule below does not do exactly what you are asking for, but it creates a pattern to achieve a similar goal. I can work on a better example later if this does not get you where you want to go. So I understand, the goal is to determine the height of a building based on target FAR, with setbacks already understood. Essentially a rule to understand the tradeoffs between setbacks/ footprint area and a target FAR? /** * File: Simple_Massing_Model_by_GFA.cga * Created: 17 Feb 2014 08:54:32 GMT * Author: Esri */ version "2014.1" attr Floor_Height = 3.2 attr Gross_Floor_Area = 10000 @Hidden attr gfaLeft = 0 @Hidden attr volumeLeft = 0 gfaFromVolume(vol) = vol/ Floor_Height Init --> alignScopeToAxes(y) set(volumeLeft,geometry.volume()) set(gfaLeft, Gross_Floor_Area ) print("Current Volume: " + volumeLeft) print("Theoretical GFA: " + gfaFromVolume(volumeLeft)) print("Target GFA: " + Gross_Floor_Area ) Mass Mass --> case gfaLeft > geometry.area(bottom) && scope.sy < Floor_Height *1.1: s('1, Floor_Height ,'1) Floor set(gfaLeft,gfaLeft-geometry.area(bottom)) color(0,1,0) t(0, Floor_Height ,0) Mass case gfaLeft > 0: set(gfaLeft,gfaLeft-geometry.area(bottom)) # color(0,0,1) split(y){ Floor_Height : Floor | ~1: Mass } else: color(1,0,0) asdf.
... View more
11-09-2016
09:54 AM
|
0
|
3
|
3489
|
|
POST
|
Hi Duncan, This was similar to my problem. I will say when I back saved the same toolboxes in ArcGIS Pro, I don't recall having the same issue anymore. Additionally, changing the names of some of scripting tools did cause some of them to appear in the backed saved Toolbox. It might apply because I am not sure I had the same model structure or used the same tools (overlay etc) that are mentioned here. David
... View more
11-08-2016
09:10 AM
|
0
|
0
|
464
|
|
POST
|
Hi Dulini! If I understand the question you are trying to get the parcel area passed to the footprint rule you created? You could try passing the area as a parameter to the next rule. For example: Parcel--> setback (front_setback){street.front:NIL:remainder: FootprintRule(geometry.area)} FootprintRule(ParcelArea)--> do_stuff_with(ParcelArea) extrude(X) Etc. Or are you asking how do you determine the area of the footprint within the Parcel rule? That might be a little more difficult because the footprint rule cannot tell the parcel rule what its area is. Information cannot be sent back up the shape hierarchy. Usually we get around this with some math, python (reports API), or setting global variables in CGA. What is the goal generally? Just trying to understand the question. David
... View more
11-07-2016
06:04 PM
|
0
|
5
|
3489
|
|
POST
|
It is likely not the best approach for the problem at hand...
... View more
10-18-2016
08:29 PM
|
0
|
0
|
3609
|
|
POST
|
So as an Experiment...that I will willing to reinstall for...I did install the new version of numpy/sci-kit learn/ C++ compiler...and I got it to work. I also checked to see if some of my panda's based scripts worked (which involve some numpy) and they also work. Python and Arcpy tools still work. Is it just a matter of time before something breaks? I have trouble running sci-kit learn in process scripts more than once in the same map session (it also creates memory issues in Pycharm as well- something is leaking or something is not interacting well). That said, the numpy library did not show in the 10.4 install like I did for other installs that I have, so it might just be I am not directly calling it. I was curious if anyone here had any insight into why everything still seems to work and some ideas on how to break it?
... View more
10-17-2016
08:59 PM
|
0
|
1
|
1962
|
|
POST
|
Hey Cheryl, I think in the case of python, I was thinking there might be a few limited cases where you could use a combination of 1) getReports, 2) setAttributes, and 3) GenerateModels in the python API to iteratively retrieve report information to make decisions on particular aspects of of the models geometry. I was not entirely sure if it would actually work though. I want to test an example, but I was largely thinking along the lines of a block like (pseudoish code, not checking api explicitly): depth=startValue while model.getReports()['setback_area'] <100: depth+=1 i.setAttribute('depth', depth) model.GenerateModels() It is not getting information from the same branch like you mentioned, so it is not efficient, you are just telling the whole generation process to get close to 100 SQ Meters for a particular leaf based on its report. David
... View more
10-17-2016
09:22 AM
|
0
|
2
|
3609
|
|
POST
|
Hey Micah, If you want to keep reporter, I think you can just add NIL to the end of the rule to terminate the leaf. Along with creating gaps in a split, it helps with creating reporting rules that just need to get information then disappear. Lot--> extrude(Height) comp(f) {top:Roof|side:X.} Roof--> roofGable(20) Flicker comp(f) {all:Reporter} Reporter--> color(1,0,0) report("Area",geometry.area()) Flicker--> X. If you add: Reporter--> color(1,0,0) report("Area",geometry.area()) NIL The flicker in the images disappears, but the report information remains. May not help you right now, but thought I would mention it. David
... View more
10-16-2016
10:26 AM
|
1
|
0
|
1484
|
|
POST
|
I was kidding around. 😃 That makes sense. Fair enough. Pictures are fun though.
... View more
10-14-2016
06:49 AM
|
0
|
0
|
1666
|
|
POST
|
Adjusted my answer accordingly. I knew altering any paths would be a bad idea. I did a quick test of adding something to Esri.lib showed it could be used that way, and it worked for a simple rule. However it definitely sounds like a bad idea. Best practice sounds like creating your own library projects. I can talk to you more off the post about that idea, but the short answer is we are trying to find another distribution solution. There are currently multiple distributions of the complete street rule and it is very confusing...not all of them are current with bug fixes etc. The rule was released on an Esri Attribution license and my contributions are under an additional Apache license (I have both in the project I have). I'll email you about it. PS: Hey you have your business card in every post, let me use the CS rule as a shameless example all of the place. XD Besides, I party on the other GIS threads too... Thanks for the replies on this Matthias this has been helpful for me and the others on the thread. David
... View more
10-14-2016
06:04 AM
|
0
|
2
|
1666
|
|
POST
|
Hey Tim, Esri.lib does have all the default plant and some of the basic street rules that ESRI provides with it. The Esri.lib libraries likely have nothing stopping from having other rules and their assets added to their project folders for import and use in other projects. Edit*- Based on Matthias's answer below, while you might be able to use the libraries this way, these are low level libraries that get replaced on start up if they are not found. It would likely be best to make personal library like Tims_Library or something like that. Any change to the interface or folder structure of Esri.lib or ce.lib is not recommended as it could break the paths that a lot of rules depend on. While I agree with Matthias's approach for managing CityEngine projects generally, if you need to share projects or distribute them, it makes sense to keep the assets of the rules you are using in the current project folder (UNLESS they come with CityEngine on install such as those in Esri.lib, in which call Esri.lib as the library it is intended). For example, for the complete street rule to be properly distributed, it requires its assets in the project so others can use it, but it does not require the plant's assets and rules because it expects the Esri.lib interface not to change (until it does, then I have work to do). David
... View more
10-13-2016
06:22 PM
|
0
|
0
|
4821
|
|
POST
|
Hey Tim, The Complete Street Rule and some of the Rules in the Redland's Example reference Esri.lib assuming it will be available as a constant path in the CityEngine work space (chosen on installation). It is most common that the rule examples take the tree loader rule from Esri.lib for example. Line Example: import Tree : "/ESRI.lib/rules/Plants/Plant_Loader.cga" # Taken from ESRI.lib and uses its assets. Keep this in mind when using rule. David
... View more
10-12-2016
09:48 PM
|
0
|
6
|
4821
|
|
POST
|
Thanks for clarifying the definition. So absolute paths in CE are those relative to the CityEngine workspace, and relative being to the working project rule directory. For most programming languages, I guess the confusion is that the master root directory is starting from a higher level root (C/Drive Name). Thanks for correcting me Matthias.
... View more
10-10-2016
07:27 AM
|
0
|
0
|
4821
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-07-2024 02:16 PM | |
| 1 | 05-15-2022 12:21 PM | |
| 1 | 08-27-2016 11:03 AM | |
| 1 | 12-19-2021 01:10 PM | |
| 1 | 06-12-2020 03:29 PM |