Aligning Rectangles to Curves

Replies to This Discussion

Permalink Reply by Hyungsoo Kim on January 4, 2016 at 12:34am

Not sure this is the best way, you can check. Best.

Attachments:

• AlighRectangleswithCurves_re.gh, 15 KB

Permalink Reply by peter fotiadis on January 4, 2016 at 12:46am

Hi Andrew (long time to talk, drop a word about your adventures in town planning).

Get the other thing as well in case that you are following Plan Z (towards the Dark Side, he he : BUT Python is NOT the right thing for your specific engineering domain).

best, Lord of Darkness

Attachments:

• Rectangles_on_polylines_V1.gh, 116 KB

Permalink Reply by Andrew M on January 4, 2016 at 3:39am

Thanks both of you for your solutions, which work for the sample I provided. I've encountered a small issue though, I'm actually forming my curve network using the 'polyline offset' component from Clipper. I need to offset different 'blocks' at different sizes, thus the setup you see in the image. Problem is, the plane coordinates are not the same between blocks. The result is that some rectangles are aligning along one plane, and some along the other. Any idea what's going on here? 

Attachments:

• Aligh Rectangles with Curves-plane issue.gh, 20 KB

Permalink Reply by peter fotiadis on January 4, 2016 at 4:09am

You are a  luck guy:

Kim would undoubtedly provide MK2 to deal with the situation ... whilst ... well ... you know what to expect (soon) from my part don't you?

Q1: are you going to translate Kim's way (and/or my stuff) to P for some integration in some project of yours? If so what is the expected average amount of data? (I do hope not some billions of parcels, he he).

Q2:what actually are the restrictions related with the "rectangles" ? (buildings in plain English): I mean if this is closer to that ... than a min D > modify this or that or both OR REJECT the parcel or ... blah blah.

Q3: what are actually the restrictions with regard the orientation? buildings // to what portion of a given parcel? Or maybe deploy along a side that yields the max building length? (if this makes any sense).

more soon.

Permalink Reply by Hyungsoo Kim on January 4, 2016 at 5:41am

You should adjust polyline directions and seam position first and go for next move.

As Peter said, I think my solution is not suited to the case when you dealing with huge amount of data.
The point is that what is the benefit of using GH in this sort of situation, so I also looking forward to Peter's C# code.

Attachments:

• AlighRectangleswithCurvesplaneissue_re.gh, 24 KB

Permalink Reply by Andrew M on January 4, 2016 at 5:50am

Hi Peter and Hyungsoo, thanks for your responses. Hyungsoo, so that's what it was, I figured the best approach would be to tackle the polylines before sending them to your script, and you just provided that answer.

Peter, to answer your questions:

1) Yes, I would like to eventually translate one or both ways to P, as it's a great learning opportunity (and perhaps way to start to understand C as well) and the future potential integration possibilities are there as well. On average I'd expect not more than 200-300 of these initial 'plots'. 

2) For the 'buildings', I plan to keep them as a simple footprint with modifiable dimensions as in the example, most likely not changing far away from the 40x12 range, though some variability will be planned for. At least at this stage. 

3) For the orientations, I plan for them to be oriented in one way (e.g. north-south, or bldg length along the x axis). These initial four footprints will be expanded on more, I'm just trying to get the framework in place now and will try to work with it more/expand on it afterwards. For me understanding how this planar orientation works/solving this strange issue (strange to me anyways) will be a milestone. I'll look forward to your response. 

Thanks again both, I appreciate your guidance!

Permalink Reply by peter fotiadis on January 4, 2016 at 6:38am

Andrew, Kim

OK, I've got what I need for the (trad) V2 update (it can make fine espresso as well - a user option, as always).

What is our main issue here? (Forget any "alignment policy" imaginable)

Well ... (remember out discussions of the past? I'm sure that you do)... imagine Beverly Hills (where my future fiancee lives: Charlize Theron [Goggle that name in case that you live in Planet Zorg]):

Here's some segment of Beverly Hills (spot the Z thingy in Front View):

Got it?

BTW: offset curve on surface IS OUT of question: slower than any Harley Davidson. But this is already addressed, he he (V2 is flying: 1000 random ultra hilly parcels are tested).

I'll try to deliver the "simplest" (*) C# possible for the C > P translation part.

(*) if you buy this you can buy anything, he he.

more soon

Permalink Reply by peter fotiadis on January 4, 2016 at 11:28am

Spend some time on that V2 (AUTO arrangement of parcel indices is done [remember the other case?], AUTO orientation of polylines is done).

BTW: this case is another gigantic pile or worms (as usual) IF Z comes into play (real-life) > constrains and what-ifs rise exponentially, your initial orientation desire DOES NOT guarantee "max" utilization (should we bother about that?), the validation of placing "buildings" in "plots" depends on the type of soil as well (excavations) - otherwise the Bogota effect would ruin any realistic planning "proposal" -  and ... hmm .. due to this, this and that ... I think that I need some Tequila more (purely in the Name of Science).

BTW: Forget all the above if you do stuff in Dubai > flat like Earth.

Moral: a pile of worms, what else?

more soon (and the V2).

Permalink Reply by peter fotiadis on January 5, 2016 at 3:36am

Update:

1. V2A - load R file first - does something (a variety of orientation options is NOT included - read below) but that something is the wrong way to do it.

2. Why? because that way (or via any way that applies a "general" type of orientation "algorithm" regardless of the parcel in question) leads us to Soviet type of urban planning: get people > make them numbers > put them in blocks > job done.

3. What to do: After aligning the rectangles with some "start"/guide/seed mode (like the "cyclic" one [my favorite] available in V2A) allow individual control on "rectangles" on a per parcel and rectangle basis - elementary my dear Watson.

How this is achievable? Easily via the Dark Side - what else?

Is it realistic? Yes since we are talking about 200-300 parcels (and not several millions): estimate about 15 seconds for "manually" vary the rectangle (dimensions, Z [topographic constrains], respect min dist regulations etc etc) in relation with the other 3 (or pick another one from a pool of "standard" rectangles or on the fly make a new variant and store it in the pool).

more soon

Attachments:

• Rectangles_on_polylines_V2A.gh, 137 KB
• Rectangles_on_polylines_V2.3dm, 451 KB

Permalink Reply by Andrew M on January 5, 2016 at 11:05pm

Hi Peter, looks really cool. I'm going to check it out now. I'm sure I'll have questions and approbations soon!

Permalink Reply by peter fotiadis on January 5, 2016 at 11:51pm

Well ... it's rather "cool" than cool: lot's of "conditions" with regard parcel topology are not addressed (because the whole approach [the "automated" one] is fundamentally wrong).

See V3B (lot's of changes in order to prepare the whole thingy to work interactively as described abode) VS a "Bogota" type of random and rather "unsuitable" parcel shapes.

  Of course I could easily address this by creating ... more rules ... but the more rules you create the further you diversify from the right way to do this type of stuff.

It's the classic mind trap when coding: you start from the wrong side of the pond and instead of trying another totally different angle of attack you eternally try to correct the wrong thing.

Exactly what Germans do with that ugly Porsche 911 (wrong concept from day one). Compare with what Ferrari does - even dropped the ultimate thing known to man: the F40 (the last real Ferrari).

Permalink Reply by peter fotiadis on January 7, 2016 at 2:31am

Haven't found the time to finish the V2B but in the mean time get this attached that is the core of the matter (you'll see why when the def is ready) with regard any parcel "shape" building contour polyline computation (the offset thingy, that is, that is computed via trigonometry and NOT by offsetting the given contour on some patched surface [VERY slow to the extend to be 10000% useless]).

BTW: All parcel polylines must been treated with the same "orientation" (say: clockwise) for obvious reasons (see what the cross vector does).

BTW: As always Z is the most important factor in urban planning.

BTW: This def acts as a basic vector tutorial as well.

best, The Lord of Darkness

Attachments:

• Polyline_measure_angles_V1.gh, 133 KB

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