2. convert each ShpFeature (a python class I created to hold each feature in the shapefile) into Rhino Geometry
- for this step, I created a set of functions that I will post to GitHub in the next week (these functions could certainly be expanded, especially for multi-patch shape features which are sort of like meshes). When I do that, I can update the shapefile reader code as well
- The associated dbf table data for each feature should probably be stored in some attributes. So far I've used the UserString data in Rhino.DocObjects.ObjectAttributes, but something else might have to be figured out for Grasshopper, since it doesn't use DocObjects (I'm starting to feel like Grasshopper should just have ObjectAttributes as a basic data type or something similar).
And you should look for any .net compatible implementations of the proj4, gdal, ogr, and geos libraries, because they can do most anything you might want, as well as ton more.
These would allow you to read and write virtually any gis data (shapefiles, raster images, kml, geoJSON, etc.) as well as to perform geospatial processing and easily deal with different projections and geographic coordinate systems.
In other words, someone has already written open source code to do most of what you or I would want, and I'm starting to think that I should just learn to work with ogr instead of working on my shapefile reader.
Thanks for your message. I joined your circle last Friday; and that image was my first uploaded one executed with rhino + grasshopper. I have been using this fascinating software since last October; and I also like to enjoy the circle…
Benjamin Golder
2. convert each ShpFeature (a python class I created to hold each feature in the shapefile) into Rhino Geometry
- for this step, I created a set of functions that I will post to GitHub in the next week (these functions could certainly be expanded, especially for multi-patch shape features which are sort of like meshes). When I do that, I can update the shapefile reader code as well
- The associated dbf table data for each feature should probably be stored in some attributes. So far I've used the UserString data in Rhino.DocObjects.ObjectAttributes, but something else might have to be figured out for Grasshopper, since it doesn't use DocObjects (I'm starting to feel like Grasshopper should just have ObjectAttributes as a basic data type or something similar).
to help understand the code, you might want to check out theESRI shapefile specification.
Feb 14, 2011
Benjamin Golder
And you should look for any .net compatible implementations of the proj4, gdal, ogr, and geos libraries, because they can do most anything you might want, as well as ton more.
These would allow you to read and write virtually any gis data (shapefiles, raster images, kml, geoJSON, etc.) as well as to perform geospatial processing and easily deal with different projections and geographic coordinate systems.
In other words, someone has already written open source code to do most of what you or I would want, and I'm starting to think that I should just learn to work with ogr instead of working on my shapefile reader.
Feb 14, 2011
Hironori Ohtoshi
Feb 21, 2011