Not really sure this belongs in the Gallery, but I just imported a bunch of Natural Earth ESRI shapefiles using the new importer I wrote for Grasshopper2. So far this just includes the geo-physical data, cultural data I may or may not do in the future. All data sets have been merged into categorised Rhino files with properly named layers and sublayers.
All data is purely 2D, elevation sets have not been included. I have not post-processed the data in any way, specifically I have not merged adjacent polylines that are clearly supposed to be a single region.
You can download the files I produced (Rhino 6 3dm and worksession files) from our servers my dropbox: Natural Earth 3DM.zip (70MB)
This data has been placed in the public domain, but feel free to read the original terms of use to satisfy you’re allowed to use these files in any way you want.
Off topic but David, where can I find your old CoffeeBreak script or plugin? I was just telling someone about it and I still get a good laugh from it. I did find your video for the ACADIA acceptance speech. I like the Chuck Norris comparison.
David, I know you expressed some contempt for the SHP format in the past. It sounds like you’ve reopened that can of worms for Grasshopper2…
I haven’t seen anything recent about this on the Grasshopper Forum. Am I missing something? Or is there anything you can share about what’s in store for Grasshopper2? I’ve been using some of the parsers others have written (Meerkat, Heron, @it) which each have their strengths and weaknesses, but lately I’ve been thinking that it may be worth it to write something of my own. I’d love to hear more about the work you’re currently doing!
I did, and I still cannot believe how badly the file format has been designed.
However in the past I’ve used an SHP file importer written by someone else which relied on a specific version of the MS access database tools. This time I’ve written an importer from scratch using the ESRI spec. I’m not parsing the dbf and prj files yet, I’m not sure when/if I’ll get around to that. I’ve also still to add support for Multi-patch geometry.
The main reason I did this particular job now is because I want to test the prowess of the Eto graphics library (the cross platform UI kit we’re using for cross platform Rhino plugins) and it always seems good to test with real world data. Having an SHP importer gives access to a lot of freely downloadable 2D real world data, so it seemed worth to sacrifice a day to write a better importer.
I’m thrilled to hear you’re working on this! If you need any testers, I’m working with SHP files and Grasshopper for real-world projects on a daily basis.
Baby steps… True, it’d probably be as much work to reassociate the attributes from DBFs as I’m going through to overcome the limitations of the GIS–>Grasshopper tools above. Maybe your importer would be useful to verify accuracy and completeness of the geometry as I’ve run into a few issues there, but it sounds like I’ll just have to make do for the time being.
In case it’s informative for the work you’re doing, here’s a brief list of the limitations I’ve run into with the above tools:
I think one issue involves only geometry and perhaps you’ve already tackled, ie, features with rings are mishandled in a variety of ways, either dropping inner rings completely or stringing all vertices together in a tangled, self-intersecting mess.
The PRJs are definitely another issue, as the the above tools bring geometry into the Rhino/Grasshopper coordinate space inconsistently at best, or are missing some projection formats and cannot parse the geometry at all.
Lastly, the ability to preview and crop the SHP files is incredibly useful. Meerkat makes an admirable attempt at providing the crop functionality but doesn’t seem to handle quite a few projection formats. If this were both more robust with regard to projections and perhaps combined with a lightweight preview, it would be very useful indeed.
Thanks again, David. I’m looking forward to see the fruits of your labor.
My current importer correctly handles disjoint segments/rings for both polylines and polygons. It’s a bit tricky to make sure this always converts correctly to Rhino surfaces with the holes where you expect them to be, but at least the separate parts of that make up individual ESRI polylines and polygons are stored separately. The only remaining problem is that winding order in ESRI polygons defines the inside/outside metric, which means it is theoretically possible to create a polygon in a shapefile which defines a hole in an infinite region. Rhino has no parallel for this kind of geometry.
PRJs, yeah… that’s an issue. The files seem easy enough to parse, but I’m not sure how much work it will be to actually cater to all possible projection schemes that shape files come in. Haven’t looked into this much yet.
Cropping is something I’m actually very interested in myself for the purposes of performance testing. I need to break up these 200MB files that contain high resolution data for the whole world into recursive tiles so only relevant data needs to be loaded/drawn. This will also involve a certain amount of downsampling, but RhinoCommon has good methods for reducing the complexity of polylines.
This is not about specific data, this is about a data format. However OSM has decent APIs for downloading their data so I may well end up writing an importer/downloader for that as well.
Sorry about that. What is the advantage of using the SHP format over the OSM format for storing real world data?
In the past I’ve played a bit with making custom maps; both in Rhino and Maperitive. It would be nice to be able to export curves from Rhino to the OSM format for rendering in Maperitive. I ended up doing it by hand in Notepad.
I’d say there are no benefits, OSM xml is superior in every way but SHP has been around forever and many government and academic institutions still use it.
Haven’t heard of maperitive before, and they’ve exceeded their bandwidth. Exporting map data to xml should be doable from GH, provided all the correct user data has been assigned to each piece of geometry.
