|
POST
|
Hi Heather, Thanks for your thoughtful reply. I will give your suggestion a try. I think that metric for orders makes sense. Is the thought there that, if it is more optimal, it will use the same bus to grab more passengers if it makes sense (locations are clustered close to where they are delivered for example)? A lot of the trouble is I am doing this all programatically with Python and Pandas (so 40 VRP runs in total for 2 destinations), which makes it hard to QAQC the 160 output files. I think the next thing we want to investigate is determining the average wait time from the passenger's perspective. This could theoretically be done by using the timestamps in the output visited stops correct? Does it make sense to use the default times it allocates or should I determine when orders are put in myself? Are there explicit settings that need to be changed to simulate this? At this point I might owe you a beer at the next UC. Thanks, David
... View more
07-21-2017
12:15 PM
|
0
|
3
|
3580
|
|
POST
|
Hi Heather, This solved my immediate problem but created more questions. Below is a data table of resulting average travel times from the VRP solver. We are trying to create a tool that can help with different scenarios of paratransit ridership coupled with bus allocations (number of routes). The numbers derived here are the averages of the "TotalTime" values for each route. Something we noticed was that for lower ridership outputs we saw some type of solve instability whenever the number of seats surpassed the number of total riders. For example each bus has 14 seats, and as a result our results make sense when we get to 2 buses with 20 riders. When we get to 3 buses though, we essentially could have "1 extra" bus (as 2 buses could pick everyone up in one load). I am trying to understand conceptually why the average TotalTime could increase when 3 routes are assigned. I have tried a multitude of MaxOrderCount approaches including: 1. max(Orders/Bus_Count, BusCapacity) 2. max(Orders/BusCount, BusCapacity*.75) 3. Orders/BusCount Is this a result of how the solver workers? Am I missing a concept? Do you have any ideas on what to check for that causes this instability? These results are useful and give us a launching point for future analysis, but I am trying to understand this tools various parameters to determine what is relevant. Thanks for your help so far!
... View more
07-20-2017
05:10 PM
|
0
|
5
|
3580
|
|
POST
|
I don't like that this is the answer...I actually used a mask for my processing. It sounds like it might just make sense to use a processing extent and then mask after then?
... View more
07-20-2017
10:45 AM
|
0
|
1
|
1268
|
|
POST
|
Hi Jay, I am actually having a similar issue. Similar question, how do you force it to use all Routes? I am having a VRP layer with buses with a capacity of 14 and order pairs to particular destinations. I assign multiple routes but not all of them are utilized. Any thoughts on how to make sure they are all used? David
... View more
07-19-2017
07:55 PM
|
0
|
8
|
3580
|
|
POST
|
Hi Bastien, I am in a scramble to prep for the ESRI UC, so I can't give any code. I can tell you that const and attr are instantiated at the beginning of the shape generation process (and then not changed through out the rule). From Doc:const A new constant can be introduced by "const" and is evaluated the first time it is encountered in a rule or expression. As in "attr", constant expressions are evaluated only once per generation and rule file. The values of constants cannot be externally changed trough the inspector or by a map. Constant expressions do not appear in the inspector. My suggestion is remove the "attr" and make this a function that will change every time it is called (theoretically). Looking forward to nice textures! =D
... View more
07-08-2017
10:00 PM
|
1
|
0
|
7792
|
|
POST
|
Hi Geoff, Yeah... I felt it should be a permanent add, and we are just poking around rule hierarchy a little on a whim... "Street + Island" etc. That makes sense. I think generally the assets look like they can pull straight from the CS Rules assets. I will see you at the UC. Michael Flaxman and myself are interested in your recently flood work (Congrats! They look great!). I can update the github to accommodate different textures. I have already started assuming I can update the textures used by the rule or repairing the assets at the very least (you will see a few commits literally editing obj vertices). I try to add rather than take away assets.
... View more
07-07-2017
05:11 PM
|
0
|
1
|
7792
|
|
POST
|
Right! I remember that one now. I can check this out later. With the UC so close I am a little slammed, so I might be able to help more after next week. It seems you are at a stopping point for now though. Using it as a green island as a whole is not that unrealistic honestly. If you want an easy hack, you can reduce the height of the grass, and then add pavement textures on top too (that way the settings of the other island settings don't interfere). In anycase, I can take a look at this next week. geoffrt do you have any interest in updating the parking rule to accommodate this use case in the future? I feel like we are doing only a partial solution.
... View more
07-07-2017
04:30 PM
|
1
|
3
|
7310
|
|
POST
|
Hi Wendell, To test this I really think I need CE.. Can you send me the link to the project that gave you the assets folder for this? I did not see it in CS 2015. Generally, the structure of the original parking rule favored jus texturing the central islands green. Also teh fact that the streetCutsEnd can vary the design makes this a little more complicated. The end game is you would want to remove all texturing that is done before you split the trees. The structure should look like: 1. Split Shapes into the pattern [Pavement]:[Tree Greenspace]:[Pavement] 2. Texture Pavement spaces with appropriate texturing rules. 3. Texture the planting and insert trees through different rules. split(u,unitSpace,0){{~Median_Tree_Spacing/2: Pavement |1:Tree_Setup("Median", Median_Tree_1_Percentage , Median_Tree_1_Type, Median_Tree_2_Type) GrassRule |~Median_Tree_Spacing/2: Pavement}*} Again, I want to test this, but I would like the assets for reference. David
... View more
07-06-2017
06:51 PM
|
0
|
5
|
7310
|
|
POST
|
Hi Dulini, I found this older thread on accident. I typically find questions posted this forum pretty quickly: https://community.esri.com/thread/118424#450222 Generally roundabouts are a weakness in the rule. The issue usually comes with the UV space changes a roundabout creates near the intersection. In addition, the Complete Street Rule and to some extent CE roundabout shapes generally do not handle the following very well: 1. Non-uniform width/high curb radii shapes/approaches 2. Pedestrian islands (not a supported feature) If you still want to talk about this let me know. I realize it is a little late now. David
... View more
07-06-2017
06:46 PM
|
0
|
0
|
1400
|
|
POST
|
I might have expected the pavement to become white, but not there to be nothing. MedianTreeSplit rules are still present correct? If you just remove texture() does that also make the whole element blank? I will have take a look at this later. I can't access CE (server manager issues).
... View more
07-06-2017
12:09 PM
|
0
|
7
|
7310
|
|
POST
|
Hi Wendell, Due to IT issues I can't access a license, but I think I found the issue regardless. The IslandInnerSettings rule is setting up a projection and projecting it before you call the MedianTreeSplit Rules at the start split. My guess is you want to do the texturing lower down in the shape hierarchy where the MedianTreeSplit rule is operating. Again, I can't get CE right now, but this seems to be where the flow the rule points. What happens when you remove the bolded code? Same could be said for other parts of the rule. IslandInnerSettings --> case greenCenterIsland: setupProjection(0, scope.xy, hardscapeTextureScale, hardscapeTextureScale) projectUV(0) texture(sidewalkTextures + hardscapeType + ".jpg") Median_TreeSplit2 Median_TreeSplit else: setupProjection(0, scope.xy, hardscapeTextureScale, hardscapeTextureScale) projectUV(0) texture(sidewalkTextures + hardscapeType + ".jpg") PS: Based on the screen shots I see UV overlap flickering. You might want to make sure you only call a median split rule once. David
... View more
07-06-2017
11:15 AM
|
0
|
9
|
7310
|
|
POST
|
Hi Wendell, Is texturingOn here set to true? TreeInsert(Location,Percentage1,Tree_Type1,Tree_Type2) -->
case texturingOn: I will try other things later, but it does look like there is a texturing rule being applied in the wrong order somewhere. David
... View more
07-06-2017
07:31 AM
|
0
|
11
|
7310
|
|
POST
|
Hi Wendell, Sorry for my slow response! You did a good job of integrating key components of the rule. I have a feeling there might be a few things going on. 1. From what I can read you are calling Median Plant Base, but it only calls Median Planting and Tree_Setup. Tree Setup does not do the repeating splits for trees. If you want repeating trees you should call Median_TreeSplit, but it looks like you are debugging that. 2. Check that Median_Ground_Cover is not "None" (in fact here, it should not be an option as greenIslandSpace=True does this). 3. IF that does not work let me know if changing from a unit space split helps (split on z/x). but my guess is part of the issue is you are using UnitSpace splits rather than Spliting on the z/x axis of the current shape. I will have to take a deeper look later. David
... View more
07-05-2017
03:20 PM
|
0
|
13
|
6654
|
|
DOC
|
Hi Wendell, I did not, but I would be more than willing to discuss the issue on this forum. Can you post a comment with a copy of the CGA rule and it source? David
... View more
07-03-2017
02:55 PM
|
0
|
0
|
42677
|
|
POST
|
That makes sense too...That was added to make the rule watertight. Now I am curious if there is a way to make it water tight without creating a visible shape. Does the drainage work well across all the streets? I am curious how this work with edge cases. Might be a new parameter worth investigating. PS: I am working on making the split lane marking lines an actual feature of the rule. I am making a High and Very High LOD setting, with everything High or better having those split centerlines. I agree, in renderings it looks a lot better (no blur). If there are other features that might require this type of attention, let me know. PS PS: Are you comfortable sha ring your version of the rule when you are done? Just wanted to take a look. Some of it might be worth integrating into the core rule. Last PS: Enclose Shape Edits, High LOD modifications · Holisticnature/Complete_Street_Rule@8f0ad3e · GitHub - This is an update to the rule that follows our discussion. Let me know if you see any issues. David
... View more
06-27-2017
09:47 AM
|
0
|
0
|
6654
|
| 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 |