Individual Boundaries from Intersecting Offset Curves

Replies to This Discussion

Permalink Reply by peter fotiadis on April 30, 2015 at 1:19am

BTW: what is the ideal approach on that?

1. Create a object DataTree with main dimension branches = n of roads and m subbranches holding various stuff.

2. Subbranch 0 holds width data, Subbranch 1 holds pts (a List in fact) defining the axis Curve (or Line). Other Subbranches hold the usual urban paraphernalia (network info, traffic et all) related with roads. A capability to bi-communicate with some RDBMS is a must (obviously). 

3. Some mysterious DarkSide thingy gets these "axis" and makes the plots (therefor the indices are totally under our control).

4. Some other ultra mysterious DarkSide thingy allows INDIVIDUAL control on the content of subbranch 1 (don't even imagine to do that with GH components). This means: access on the fly  roads.Branch(i,1)[item] and modify (dealing with volatile data etc etc) the road's topology ("extend" curve until hits the next road axis is the most simple alteration imaginable).

5. Some also mysterious DarkSide thingy checks user alterations (4) and decides action - via 3 (or not) kinda like a fly-by-wire thing (or ride-by-wire in my Panigale [ when it works]).

Permalink Reply by Andrew M on April 30, 2015 at 9:49am

Haha, right, the simple answer is that topography is something to consider but as an optional component only. Pizza... you're making me hungry! haha. BTW your image looks pretty cool! 

Permalink Reply by peter fotiadis on April 30, 2015 at 12:12pm

Topography is optional? Well .. time for my ultra secret(C)(tm) C# that flattens roads (buildings suffer > but > no > pain > no > gain).

Other than that (a rather insignificant thingy, I confess) here's comes the pain (the actual reason about why we must handle this solely with code):

1. Imaging a collection of actions (i.e. do this, do that etc etc) that yield something. That something is some plots defined in the pizza space (plane in fact). OK big deal.

2. Why is not a big deal? Because we are talking about an instance among a vast combination of things that yield a collection of possible solutions (that ideally feed other stuff for validation of some sort).

3. So what sits above all? A decision my dear Watson: should all that (the design evolution "process" so to speak) being controlled by a scenario management thingy? Or we do business based on a fire-and-forget policy?

Permalink Reply by Andrew M on May 1, 2015 at 12:36am

Hi Peter, I'm not sure what you mean by the question, but I'll try my best and posit that it should probably be as simple as possible. Since the hoped-for result would just be the ability to rapidly prototype road networks without a breakdown (as much as is possible) of the already-assigned land uses of non-effected plots, I imagine the 'fire and forget' policy would be the way to go. But, haha, I could be misinterpreting your meaning. 

C# is the way to go in Grasshopper it seems, I need to begin a crash course... 

Permalink Reply by peter fotiadis on May 1, 2015 at 1:32am

Well ... here's a primitive example to get the gist of what I mean  : this oversimplified thingy stores in a datatree any change in a given "list" > replace "list" by a (rather big: real life) collection of datatrees and ... blah, blah + blah.

BTW: road network design is one of the most challenging things around since it affects and is affected by exactly 123.456,78 constrains (but we'll omit "some" in the forthcoming solution).

BTW: most people want to lean C# in order to draw geometry: but in fact if you want to properly ride a decent superbike (a Yamaha YZF-R1 for instance) you need years spend in a Yamaha YZF-R3.

BTW: stay away (from the C# and the R1, that is, he he).

Attachments:

• Store_List_changes_to_Tree_v1.gh, 25 KB

Permalink Reply by peter fotiadis on May 1, 2015 at 9:24am

Good news: Entirely new strategy on (thin) air: just the road axis (+ a proper object DataTree for the metadata) + an ability to modify on the fly metadata (width, location etc) on a per item (road) basis. Then > check for stupid/invalid plots (and mark them) then compute the "raw" regions > then > ... well ... subtracting road "ribbons" from these regions is rather elementary.

Bad news: at 11.59 am I had a terrific idea > do some spiritual ride with that thing:

Ugly news: Situation (spot the kaput ball bearing) at 6.00 pm:

Permalink Reply by Andrew M on May 3, 2015 at 4:03am

Your bike looks awesome! If I weren't so worried about it being stolen I'd buy one myself :P

Your ideas sound quite interesting and, honestly, enticing. So you mean all road widths could be adjusted and new roads could be added, etc., while the original plot index of existing plots would be protected. Wow! I tried for a very long time to accomplish this with components with no luck at all. 

Yes you're probably right, learning to program would basically require me to quit my job and become a student again, haha. But it's something that I feel has so many applications in life, I wish that I could steal a year or two and focus solely on that. One can dream!

Permalink Reply by peter fotiadis on May 3, 2015 at 7:15am

(Crap) Beemer for sale > one "careful" owner > extras > hurry.

Other that that, I confess that the solution (or the salvation? he he) would be delayed a "bit" since repairing the Crap would absorb pretty much all my free-time (blame 90% naive engineering [sealed bearings used in the primary axis !!!!!! mama mia ]  and 10% Greek (merciless) tempo in riding).

Whilst spanners (Plan B: sledgehammer) replace mouse:

1. By what criteria you draw/design your road axis?

2. Are they always lines? Are they intersect in the simple "cross" way or other modes are possible?  (roundabouts etc)

3. If (see yellow circles as above) invalid regions could be encountered what to do? (a) stop/RESTART, (b) include/fuse the small region into the road network, (c) plant trees?

4. What is the desired  enumeration of plots? (N>S>E>W or something else?).

Permalink Reply by Andrew M on May 3, 2015 at 7:35am

Hey Peter! Good luck with the repairs! I have as much knowledge about repairing such a bike as I do dealing with GH components, so... haha.

Well about your questions:
1) The roads go through various design processes and finally end up in Rhino as CAD centerlines (as in the other files I've attached). After they are connected with my GH file, associated with road typologies (the different widths like in my previous file) and land uses are added etc., new roads may be added, existing ones modified, widths changed, etc.

2) Yeah for the purposes of this kind of conceptual network they are all lines. They intersect in the simple 'cross' way, and some may terminate at other roads. No roundabouts or things like that though.

3) Any plot that is created is seen as 'valid' for the design, but depending on the design they may be open spaces, parks, or just a very odd commercial plot. So I'd have to go with (b).

4) I don't a great preference either way, but if I had to choose, probably W>E>N>S.

Hope this helps. And hope you find a buyer for your bike :P

Thanks a lot Peter.

Andrew

Permalink Reply by Andrew M on May 20, 2015 at 7:04am

Hi Peter! I'm wondering how the bike repair is going? I think that task must be much more difficult than what you're usually used to in GH :P

Best, 

Andrew

Permalink Reply by peter fotiadis on May 20, 2015 at 7:14am

Well ... it's 1M times simpler in fact (since you have no worries to divide by zero, he he). Took me some time more since I've changed (my design) some bits and nuts here and there.

Whoever ... it's the assembly (3rd time lucky?) that make me wonder: this (2nd attempt) looks to you kinda like the OEM thingy?

Good news: This w/e I'll(?) start(?) finishing(?) your case

Permalink Reply by Andrew M on May 20, 2015 at 8:14am

Whoa... that is a thing of beauty. Seriously. Must be a joy to ride... when it doesn't crash you. 

That's great to hear by the way :)

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page