Grasshopper

algorithmic modeling for Rhino

Hi all:

First.. thanks for sharing Elk... I´m trying it and it's really amazing the way data can be handled.

I have only a question/suggestion..

is there any way of using isolines contained or included in osm image data to get accurate topography?

my impression is that 3seconds arc resolution is very low against OSM data resolution.

having this lines drawn in OSM "cycle" layer

I was able to combine osm data with topographic data in southamerica at 3 seconds arc resolution but it's not enough for  architecture planning or urban development.

Many thanks in advance for comments and help on this

Best regards

Ale

Views: 1539

Replies to This Discussion

I looked into the topography that's displayed in the Cycle Map layer on OpenStreetMap and I don't think the OSM file that you export from their website contains the contour information.  Beyond that, the contours they show are all generated from 3 arc second SRTM files, even if in the United States where higher resolution data is available from 1 arc second.  Also the contours are likely 2D in their map since.  Granted, their contours may look nicer, but I think it's just because they're processing the HGT file with the GDAL Contour app to generate a Shapefile.

That being said, starting last year the USGS started releasing 1 arc second SRTM data for the rest of the world outside of the US.  It's not the friendliest website, but I've been accessing it from here (be warned it will probably take a few minutes to load).  You could download the appropriate tile and use the SRTM Topo component and get better looking resolution than you've seen with the 3 arc second data.

There's also the possibility you could do the same thing OSM is doing, but with the higher resolution data. Download the GDAL library and run the gdal_contour.exe file on the 1 arc second HGT file and you'll get a shapefile with all the contours.  Elk doesn't directly work with shape files, but you could use Meerkat GIS to import the shapefile.  I've only done a few quick tests, but I've had trouble with the scaling with this method, both using Meerkat and using Autodesk's Map3d to read the shapefile, so perhaps it's my inexperience with gdal_contour.  It also looks like it's making the 1°x1° tile's square instead of scaling the X values as it goes farther from the equator.  Nothing that's insurmountable, but still you should watch out for it.

Regards,

-Tim

Tim:

First of all I really appreciate your answer... it's very kind from you taking the time and effort to help me.. many many thanks.

I'll try all of your suggestion and report back here to complete the thread and make the feedbak available  for someone else.

I was traveling and working far from home and having some troubles with my internet connection so I couldn't answer before to thank you..

Best regards

Ale.

Hi Tim:

I'm here again... and I should say thank you again... really you gave me three ways of aproaching my work ...and  now I have the tools to begin working.

I have just a question . it seems that something is wrong with the two files used in elk modules.

something different from the file used to bring SRTM data and the file exported by OSM to crop the SRTM model to the boundaries needed. there is no relation between the SRTM model created and the topography expected in OSM sector.

I think it could be something related to lat long conversion .. but not sure...Any Ideas?

Many thanks in advance.

Regards

Ale

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service