Elk

Comment

Comment by Brian Ringley on February 6, 2016 at 3:28pm

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?

Comment by Timothy Logan on February 1, 2016 at 8:13am

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.

Comment by machinehistories on January 29, 2016 at 3:04pm

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

Comment by johnnyUtah05 on January 29, 2016 at 12:16pm

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?

Comment by Timothy Logan on January 29, 2016 at 11:03am

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.

Comment by Timothy Logan on January 29, 2016 at 9:20am

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

Comment by Timothy Logan on January 29, 2016 at 8:14am

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.

Comment by machinehistories on January 28, 2016 at 6:44pm

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

Comment by machinehistories on January 26, 2016 at 12:07pm

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. 

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

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

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