Here's a key list for the Generic OSM component.

key_list.gh

Thanks it is a good list, but unfortunately it seems that it needs the value passed in lowercase - but there is a tool for that, so it's working good.

oops. Lower case it is.

key_list.gh

thanks for this nice plugin ! and for the list file as well

to get the countours (width) of the streets, as displayed  at the openstreets site i assume to use offset crv or is there an automatice way to achieve this ?

ty !

I just wanted to let everyone know, I posted a getting started with Elk tutorial here.  Enjoy... 

Hi guys, is it possible to add multiple files for topo surface component?

No, it only handles one HGT file at a time.  You can check this out to see an example of stitching together a single topo that uses two tiles.

A new version of Elk is available.  There was a lot of duplicated code in the earlier versions since once I had one working component I would just copy/paste to start the next one.  The new version (0.6.1) has been completely rewritten and should make changes and updates in the future easier to handle.  It works similar to previous versions, but there are some changes/omissions this time around.

First, I've removed the streaming option from the Location component.  I don't think it's been working in a while and I haven't been able to reliably get it to complete the download via the component, so it's gone.  I also always found it to be a hassle to download the same information each time the solution was refreshed.  You can still use Overpass (here or here) to download the data and feed that into Elk.  If the community finds it beneficial, I can add a component that generates the overpass query to get the download, but there would be a second action to link it to the location.  Because Overpass content does not contain the Bounds (latitude and longitude domains) it determines the bounds from the dataset, so specifying the longitude and latitude won't be necessary.

Also missing from the Location and SRTMTopo components is the scale function.  Elk was originally created for a specific project where I wanted to maintain a specific size and not necessarily a scale, so I included the scale function to manage that.  Releasing Elk for a wider, more generic use has convinced me that the standard Grasshopper scaling is more adequate for most applications.

Other than those exceptions, the components should work more or less as they have before.  If you notice anything out of the ordinary let me know.

Thanks,

-Tim

Just wondering how to input 2 or more values in to GenericOSM. Much like your pre made components. Eg highway = "footway" + "cycleway".

Dying to see some more advanced tutorials!!!!!!

Generating 3d buildings would be amazing

(my novice attempt, based on no. building levels assuming level height is 3.5m)ELK_OSM_3DBuildings.gh

AdelaideCBD.osm

any tips on how to cap building massing?  i've used patrick scott's definition posted below on oct 11, 2013, but for some reason the cap component doesn't work.  any suggestions?  

this plug in is amazing.  thank you so much for sharing it.

Patrick,

Currently the GenericOSM only accepts one item for the value so you'll either have to use multiple components to get the value's you need, or you'll have to us the '*' variable to get all of it, and then evaluate the feature key's output to cull the items you don't want.  I'll look into multi-input for the component.

pwdarden,

as long as you have a closed surface you should be able to extrude it and cap it.  An alternative is to use the Boundary Surfaces component to create a planar surface from the closed polylines and then extrude them.  If the boundary surface component isn't work then it's probably because your polylines are either not closed or not planar.

       This seems to be a very powerful plugin, with allot of potential so thanks for sharing it. I have been using it on several projects so far and after playing around with the GenericOsm component a fair bit I was unable to extract building:levels map feature. I have tried several Osm files and the files seem to be ok. I've opened them and checked that building:levels information is present and all of them had at least some information. Even the definition Patrick Scott posted earlier using the same Adelaide osm he attached yields no results for me.

        The "building:levels"  or "building:colour"  keys when imputed into the Generic OSM seem to return the same result as the "building" key. I get no result for K = "building:levels" V = "1" but i get plenty for " building:levels" = "apartments". Is it impossible to retrieve building:levels or similar formatted keys with the current GenericOSM component, or am I missing something? Any ideas or tips highly appreciated.

I have been using elk for generating topos etc.., however I really wish to trace google maps or use the OMA data to create building silhouettes along with the roads. Once these silhouettes are created is there a tracing option to bring vectors in?

You can use the GenericOSM component to get building footprints, but it doesn't do anything about height information so it would be up to you to determine heights and extrude them manually.  It doesn't do anything with Google Maps so anything you want to try and use that for and integrate what you're doing with Elk will be entirely manual or up to you for automation.

Are the Elk compatible with new version of grasshopper (0.90075) ?

Because component is working but no output ! 

I haven't seen any problems with it working in 0.9.0075.

Very useful plugin!

I am wondering is that possible to extract "building level" information from the osm file.

For example. In the osm file I downloaded, there are information like "<tag k="building:levels" v="3"/>". Seems ELK can only input the "k" and "v" value by myself. However, it will be great if I can just extract the "building level" information and assign it to corresponding buildings. Is there any way I can do it?

Thanks

Heath

I think I had a similar issue, where Elk was unable to retrieve the geometry in a k tag that included a :

I will try to find the example.

Currently building height cannot be extracted.  You'd have to parse the XML file and match the heights up yourself.

Scaling issues - testing this out in Seattle, the SRTM topo seems scaled to nearly double the width of the imported street data. Is there a way to correct this?

Working on a new version of the topo tool that can use 1/3 arc second data from the National Map.

1/3 arc second data with a sampling frequency of about 33' on the left, 1 arc second data with a sampling size of about 100' on the right.  Using this data also clears up problems with the voids you frequently see in the raw SRTM data.

Hello, I cannot figure out to calculate the correct domains. Thank you for the update and any information would be greatly appreciated! 

Thank you. 

Hey Erik,

The problem is that you're looking at a domain that spans across two 1°x1° tiles, but you're trying to do it with one.  GeoTiff's are a little different than HGT files as their domain tends to be a little more than 1°x1°, but generally you can't have a domain that spans across an integer.  So your latitude domain of 21.9437 To 22.2109 won't work.  You'd have to do one that's 21.9437 To 22.0 and another from 22.0 To 22.2109.  And you would need a second GeoTiff file that covers the desired area.

Thank you for your reply Timothy, 

So I understand what you mean by keep the domain within one integer; however, I wonder how to figure out the exact domain? Is it an average from the four latitude points on earth explorer? Or is there a specific lat + long domain for each individual tile somewhere? That would be the best since I cannot figure out how to have my domain relate to the correct tile. 

Thank you, 

Erik

Typically the coordinates defined in a file mark the lower left corner of the tile.  So your n21_w081_1arc_v3.tiff should span from n21-n22 in latitude and w81-w80 in longitude.  I've just pushed an update to Food4Rhino which has some changes to the Topography component. Most notable is that it now has an Info output whenever you plug in a file.  GeoTiffs and IMG files should give you the exact domains of the file.  HGT files don't store it, so it tries to give it to you based on the file name.  For GeoTiffs and IMG files the domain should extend a little before and after either side of the domain.  See if that helps.

-Tim

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

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

Thank you for your reply Tim. 

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

Best, 

Erik

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 

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. 

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.

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?

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.

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

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

Sorry the OSM file was too big to send - but it's the tip of lower Manhattan http://www.openstreetmap.org/export#map=16/40.7058/-74.0110

I tried the file listed in this thread and I am still unable to convert a location to a corresponding position on the data output from Elk osm with total accurracy. I was able to get close when the scale factor of the equation was reduced to .00001. Is it important to be in meters or should another unit be used. Even when I take the osm positions straight from elk and run them through that file they don't exactly overlap. I know I am asking a lot but what would be great is to have an additional input on the OSM DATA component for a lat/long point and then have an output for that same point that is now positioned using the same math used to position the info in osm file. This point serves as a datum. That way I am hoping to be able to move to and from or scale to and from that point as needed to match up with other GIS data. It seems several of the other GIS add-ons for GH each use different ways to map geo data and none of them correspond with each other so this would enable a way to quickly reposition and merge the various maps from all of these great tools as needed. 

Timothy,

 I have one other question in addition to the ones I mentioned in the post below and that is could you provide the projection method you are using in Elk. thanks

Erik,

It looks like one problem may be that you're using an older version of the plugin.  Try downloading the current one and see if it helps.  Note that the Latitude and Longitude inputs are reversed in the newer one and is longitude then latitude.  I felt maintaining an X,Y relationship was beneficial while I was thinking about it, hence Longitude (X) is now before Latitude (Y).

Secondly, you may still get an error because I think your longitude domain is incorrect.  The name of a file typically indicates the lower left corner of the file, so your N35 W112 should go from -112 To -111.  If you want the data from -112.88 To -112.55 you'll need tile N35 W113.

machinehistories,

Using meters isn't absolutely necessary, but if you want to use feet or any other unit system you'll need to convert the numbers before you start trying to calculate.  The thread you link to has a scaling to convert meters to feet.  I'm attaching a GH file that pulls out just the relevant part for converting latitude/longitude to a point based on that conversation, and updated it for the latest version of Elk.

cityMap.osm

CoordinateToPoint.gh

I can see how a coordinate to point could be useful, I'll add one the next time I make changes to Elk. The file has some comments to describe what's happening, but you can also see the source code for Elk and see how it works if you're interested.  The general processing of coordinate data into a XYZ is done from the NodePreProcess method in the processors file.

https://github.com/logant/Elk/blob/master/ElkLib/Processors.cs

Brian,

First off, pretty clever use of the old Elk to get the building masses, at least some of them.

The problem basically comes down to me not being sure how to resolve potentially two sets of data that occupy the same space.  One of these days I'll have to sit down and work out a solution, just haven't had time.

But what's happening is there's a 'building' feature type which is what I'm pulling from, but there's also stuff like 'building:part' which describes a part of building.  The unfortunate thing is that there's not always a direct correlation between a building and a building:part.  Elk is only pulling the 'building' elements for now, but building:part is definitely on my radar to accomplish.  I thought just extruding the building footprints would buy me enough time to figure out how to resolve the building:part stuff since find a way to create 3d buildings was always left to the user, but I guess not.  I'll look into resolving it when I make the coordinate to point component that machinehistories asked about.  Maybe it will be easier than I'm thinking.

Thank you Timothy, 

I have upgraded and now the output gives the correct domain of the tiff. However, I am confused. I have chosen a very simple site, a meteor crater, and I cannot get the crater. I use the outputted lat and long and it is not there. I would think that it could be easily found. 

Any thoughts?

Thanks very much for all your help I look forward to giving this a try and putting it to use. - jason

Erik et al,

I apparently introduced a bug in 2.2.1 that caused the Y axis to invert.  I think it was something that I had started tinkering with a month or so ago and had forgotten about.  Should be resolved, but if you've downloaded 2.2.1 I strongly suggest you get 2.2.2 to correct this mistake.  Once that's downloaded the crater should show up correctly.

Hey Tim - appreciate you taking a look at this. I think it would be great to continue improving a user-friendly way of getting 3D buildings, but at the end of the day you're always going to have users who want to dig up their own custom data. To that end, would you consider bringing back your Generic OSM component to allow the user to specify any feature keys or values from the XML?

Hi Timothy,

Thank you for your great work on Elk!

I'm having some problems, that you might have the answers to.

I have tried to download a GeoTIFF file from another webpage than earthexplorer.usgs.gov (because I needed more detail of Aarhus, Denmark than they could offer) but I just can't make Elk come up with any result, other than using GeoTIFFs from earthexplorer.usgs.gov

Result with GeoTIFF from earthexplorer.usgs.gov

Result with GeoTIFF from kortforsyningen.dk

Do you maybe know what the issue might be?

Thank you!

- Mathias

Hey Mathias,

First off, not sure what's up with it not working.  The second image you show using the GeoTiff from kortforsyningen.dk looks fine per what you're specifying and what the GeoTiff file is showing (info output).  The only other place I've downloaded GeoTiff data is OpenTopography.org, and that worked with no issues from what I can remember.

I did manage to work my way through the kortforsyningen.dk website with the help of google translate and some guesswork, and downloaded what looks like the same tile in ASCII Grid (ASC) file format with data corresponding  to the EUREF89 geodetic system.  I used gdal_translate to successfully convert the ASC file to a GeoTiff, but it's still in EUREF89 which I'm not very familiar with.  I'll need to do a little reading on translating between that and WGS84, or see if there's a different way of getting the data out in a way that Elk can understand it.

I'll report back if/when I'm able to get anywhere with it.

-Tim

Hey Tim,

Thank you and I apologize for having you go through a Danish webpage!

The GeoTiff I downloaded from kortforsyningen.dk was also an ASC file which I then converted with the software QGIS. This allowed me to translate the geodetic system from EUREF89 to WGS84 - but maybe it is actually in this translation that something went wrong.

Appreciate your help!

- Mathias

Anybody knows how to generate a shape file from Grasshopper?

THX