Using the IWkb interface does a nice job at converting between an IGeometry and WKB. From a WKB you can use the Microsoft.SqlServer.Types library to convert a WKB to SqlGeometry then back to WKT.
IWkb wkb = geometry as (IWkb); //(Where geometry is an instance of IGeometry)
byte[] wkb_bytes = new byte[wkb.WkbSize];
int byte_count = wkb.WkbSize;
wkb.ExportToWkb(ref byte_count, out wkb_bytes[0]);
At this point you have the WKB stored in wkb_bytes. If you want to go the next step to SqlGeometry then to WKT:
SqlGeometry sqlGeom = SqlGeometry.STGeomFromWKB(new SqlBytes(wkb_bytes), srid);
string wkt = sqlGeom.ToString();
The sqlite file from NE is in FDO-OGR format, not the native spatialite geometry.
If you're willing to do some manual labor, here's a way to convert to a spatialite db:
First make a new, empty spatialite database (I call it "nev.sqlite"), then in a separate terminal session open the original natural_earth_vector.sqlite with spatialite. (I used the newer version 4.1. Not sure if this will work with the older versions). Use the sqlite attach function to connect to your new nev.sqlite table, and create copies of the tables you want into the new database.
So:
micha@Wheezy:~$ spatialite natural_earth_vector.sqlite
SpatiaLite version ..: 3.0.0-beta Supported Extensions:
- 'VirtualShape' [direct Shapefile access]
- 'VirtualDbf' [direct DBF access]
- 'VirtualXL' [direct XLS access]
- 'VirtualText' [direct CSV/TXT access]
- 'VirtualNetwork' [Dijkstra shortest path]
- 'RTree' [Spatial Index - R*Tree]
- 'MbrCache' [Spatial Index - MBR cache]
- 'VirtualSpatialIndex' [R*Tree metahandler]
- 'VirtualFDO' [FDO-OGR interoperability]
- 'SpatiaLite' [Spatial SQL - OGC]
PROJ.4 version ......: Rel. 4.7.1, 23 September 2009
GEOS version ........: 3.3.3-CAPI-1.7.4
SQLite version ......: 3.7.13
================ FDO-OGR Spatial Metadata detected ===============
.....
created VirtualFDO table 'fdo_ne_110m_geography_regions_points'
created VirtualFDO table 'fdo_ne_110m_geography_regions_polys'
created VirtualFDO table 'fdo_ne_110m_glaciated_areas'
created VirtualFDO table 'fdo_ne_110m_lakes'
created VirtualFDO table 'fdo_ne_110m_land'
created VirtualFDO table 'fdo_ne_110m_ocean'
created VirtualFDO table 'fdo_ne_110m_rivers_lake_centerlines'
Accessing these fdo_XX tables you can take full advantage of
FDO-OGR auto-wrapping facility
This allows you to access any specific FDO-OGR Geometry as if it
where native SpatiaLite ones in a completely transparent way
==================================================================
Enter ".help" for instructions
spatialite> attach "nev.sqlite" AS nev;
spatialite>
spatialite> CREATE TABLE nev.countries AS SELECT * from fdo_ne_10m_admin_0_countries;
spatialite> CREATE TABLE nev.populated_places AS SELECT * FROM fdo_ne_10m_populated_places;
spatialite> CREATE TABLE nev.railroads AS SELECT * FROM fdo_ne_10m_railroads;
spatialite> .q
*** FDO-OGR auto-wrapping shutdown done ***
All the lines "created VirtualFDO..." indicate that Spatialite recognized the data as FDO formated, and created virtual tables for each with the GEOMETRY converted to spatialite format. I attach to my new "nev" database and create new tables for each layer I'm interested in with the CREATE TABLE ... AS SELECT * FROM ... statements.
Now I switch back over the the new spatialite database. And run RecoverGeometryColumn() on each table to get a proper spatialite database, with all metadata, etc. Note that the FDO format allows for mixed MULTI and SINGLE geometry types, so I first check which geometry types each table contains, and make sure that all features are the same. I use CastToMulti() wherever necessary, like so:
micha@Wheezy:~/GIS/World/naturalearthdata.com$ spatialite nev.sqlite
SpatiaLite version ..: 4.1.1 Supported Extensions:
- 'VirtualShape' [direct Shapefile access]
- 'VirtualDbf' [direct DBF access]
- 'VirtualXL' [direct XLS access]
- 'VirtualText' [direct CSV/TXT access]
- 'VirtualNetwork' [Dijkstra shortest path]
- 'RTree' [Spatial Index - R*Tree]
- 'MbrCache' [Spatial Index - MBR cache]
- 'VirtualSpatialIndex' [R*Tree metahandler]
- 'VirtualFDO' [FDO-OGR interoperability]
- 'SpatiaLite' [Spatial SQL - OGC]
PROJ.4 version ......: Rel. 4.7.1, 23 September 2009
GEOS version ........: 3.3.3-CAPI-1.7.4
SQLite version ......: 3.7.13
Enter ".help" for instructions
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
spatialite> .tables
SpatialIndex geometry_columns_auth spatialite_history
countries populated_places sql_statements_log
geom_cols_ref_sys railroads views_geometry_columns
geometry_columns spatial_ref_sys virts_geometry_columns
spatialite>
spatialite> SELECT GeometryType(GEOMETRY) FROM countries;
POLYGON
POLYGON
MULTIPOLYGON
MULTIPOLYGON
POLYGON
MULTIPOLYGON
POLYGON
MULTIPOLYGON
MULTIPOLYGON
.....
Geometries are mixed, so set everything MULTI, then do RecoverGeometryColumn():
spatialite> UPDATE countries SET GEOMETRY=CastToMulti(GEOMETRY);
spatialite> SELECT RecoverGeometryColumn('countries','GEOMETRY',4326,'MULTIPOLYGON',2);
1
spatialite>
And so on for each table you need. Now the tables are available in QGIS.
Best Answer
The comments cover this pretty well, but I'll summarize them in an answer.
WKT is text and human readable. So use this if you want a human to read them (eg. for quick verification that the data is reasonable), or if you might want to work the data using text tools (eg. regex).
WKB takes up less space - so good for bulk storage. Also it is in theory at least, a little quicker to read/process for two reasons. First there is less data to load/transfer/cache, and second there is no text to parse. In most applications the potential speed difference is probably immaterial unless you are processing large amounts of data.