Elk

Comment

Comment by Brian Ringley on January 26, 2016 at 9:32am

Hi Tim thanks for the quick response. 

The buildings are from an older version of Elk, though I'm not certain which version. I filtered for all elements with a height key and then extruded them by the height value. The key/value parsing is pretty hacky but it worked in this instance. I'm attaching the *.gha, *.osm, and *.gh file so you can review for yourself. I'd be curious to know why Elk 2.0 is not bringing in this data, or if this is a result of me not using Elk 2.0 properly.

I really appreciate your time - thanks again.

OSMBakeSampleMap.osm

elk.gha

OldElkOSMBake.gh

Comment by johnnyUtah05 on January 25, 2016 at 8:55pm

Sorry to post again, but I'm having a difficult time figuring out why my domains aren't yielding a result. I am getting the out of range error; yet, it seems to be 'in range'. Probably a simple mistake. 

Thanks in advance, 

Erik

Comment by Timothy Logan on January 25, 2016 at 8:00pm

I'm a little hesitant to believe the red geometry came from any version of Elk.  The first versions (pre 2.0) neither created 3d geometry nor provided enough information to create 3d geometry.  The current version will create fairly simple extrusions of the footprint, but isn't quite to the level to produce 3d geometry with the variation your red buildings show.

To create 3d geometry with the old versions was tedious and probably unpredictable.  You would have had to parse through the OSM file yourself and extract the relevant information and try ot map it up with the data coming form Elk.  Not a very straight forward way of doing it and would probably be easier to completely leave Elk out of the equation if you're already going through the trouble to read the OSM file.

If anything, i'd expect the newer versions of Elk to get more information, since the old version couldn't get any multipolygon elements. I don't think I've run across a building that Elk 2 couldn't get that earlier versions could, but Elk 2 can definitely get information that earlier versions can't.  In the attached image the white surfaces are from Elk 2.2.1, and the black outlines are from Elk 0.6.1.  THere are no black boundaries with no white, but alll the multipolygon elements are only white with no black boundaries.

Better 3d buildings is definitely on my radar, but while the capabilities are built into the OSM spec, it doesn't seem to be as prevalent in the actual database.  New York is probably a good case study though, as it tends to have some of the more advanced data.

One final comment is that the 3d buildings Elk creates are from the 'Height' parameter in the OSM spec which isn't always present.  Another similar parameter is 'Levels', but there's not usually any indication of how high a level is so I've ignored it.  Elk 2.0 and later does include all tag data that it could find for any building (or road, etc.) so if the data is there you should be able to parse it out and use it pretty easily.  I know I've gone through it at some point with someone on how to use the 'Levels' parameter to extrude building footprints, but I don't recall if it was here on the forums or through email.  I looked quickly but didn't see it, so I'm guessing email.  I'll try to put together an example soon.

Comment by Brian Ringley on January 25, 2016 at 1:27pm

I am updating some of my workflows that used the older Elk version to Elk2, but I seem to be getting a lot less building information. In the image below, the red, baked geometry represents what I was pulling from the old Elk using this particular OSM file, and the blue represents the geometry I'm pulling using the Elk 2 "Create 3D Buildings" feature. Has anyone else noticed this behavior?

Comment by Timothy Logan on January 25, 2016 at 7:43am

There's no geocoding capabilities within Elk, but you can use OSM or Google Maps geocoding API's to get a latitude/longitude for a given address.  There was also a thread on the forums here where adding CSV based lat/lon coordinates was talked about, so you can follow the logic of how that was done to create a point within the OSM space from the example in that thread.  Once you have that it should be pretty straight forward to translate between the two data sets.

Comment by machinehistories on January 24, 2016 at 10:03pm

I was trying to get the OSM data from elk to overlay onto the data from Heron. It appears everything shares the same scale but they are in different locations within the rhino viewport. Heron sets the input address location to the origin. What I was hoping is if there was a way to plot a single address as a point using Elk and that way there is a means to translate from point to point. Can Elk generate a a single point at a particular address. 

Comment by Alaa Haddad on November 23, 2015 at 9:12am

Hello guys , does anyone knows how to import a small area of a city with 3d buildings using this plug in ? i know how to import 2d maps  through elke ,i am trying to get 3d buildings 

Comment by johnnyUtah05 on November 8, 2015 at 12:58am

Thank you for your reply Tim. 

Your response makes sense. I appreciate your insight as well as the great plugin!

Best, 

Erik

Comment by Timothy Logan on November 7, 2015 at 4:06pm

If you're talking about aligning the topography to the OSM data, then you should be able to get close.  I've found it's a little easier when you have body of water to align to because you start getting a perfectly flat area that should align with a coastline, lake boundary, or river.  Then it's just a matter of moving the topo around until it lines up with that boundary.

If you don't have that luxury, then it's a matter of just looking for something that looks like it aligns with the topo.  I don't know that I have an answer that works all the time though.

If you're trying to align the different parts of a topography, then I typically just get the bounding box of one of them and use that to determine the distance the other part needs to move in the X or Y direction.  I've found that even if I use the same start value for one topography as end value of the previous one, that the edges will not line up as perfectly as they should.  In that case you may need to add or remove some items or branches (dependent on the orientation of your topos and the orientation of the lines) to make sure they line up better.

-Tim

Comment by johnnyUtah05 on November 7, 2015 at 3:33pm

This is great! The new output is extremely helpful. I have made the domains work based on your comments. I do have one final question: Do you have a method of aligning the topography to the generated map? 

Once again, Thank you. Such a a useful plugin and wonderful update. 

- Erik

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• …
• 7
• Next ›
• Page