Closed liyinxiao closed 4 years ago
The problem is that osmcoastline can generate several different tables in that output file, so there must be a way to deal with that. And we store more than just the geo data in there, some meta data is also stored. There might be some problems with Shapefile limitations, but maybe not. That's something that need to be researched.
If we make this configurable it should not only support Shapefiles but all the formats supported by GDAL.
So this is not as simple as just changing the GDAL dataset type. How would you go about doing this?
Yeah, there are two meta_data tables, which will not be supported if we switch to a different driver such as ESRI Shapefile. But I believe these data are not as critical as the other outputs, such as land polygons, and omitting them might be acceptable.
CREATE TABLE options (overlap REAL, close_distance REAL, max_points_in_polygons INTEGER, split_large_polygons INTEGER)
CREATE TABLE meta ("
"timestamp TEXT, "
"runtime INTEGER, "
"memory_usage INTEGER, "
"num_ways INTEGER, "
"num_unconnected_nodes INTEGER, "
"num_rings INTEGER, "
"num_rings_from_single_way INTEGER, "
"num_rings_fixed INTEGER, "
"num_rings_turned_around INTEGER, "
"num_land_polygons_before_split INTEGER, "
"num_land_polygons_after_split INTEGER)
I plan to simply change SQLite into ESRI shapefile, and only create these two meta_data tables when driver="SQLite". I have tested it and it worked well for me (by investigating all the shapefiles, including error_lines, error_points, land_polygons, water_polygons, lines, rings).
If we want to support all the formats supported by GDAL, then we need to make code changes (some formats such as GEOJSON requires a significant amount of change) and test all of them (>100) , which might be too much work.
I want to avoid a situation where we implement Shapefile support and then the next person comes around and says they want Geopackage and then the next wants GeoJSON and so on. So if this is configurable it should allow whatever GDAL has support for. After all it is GDAL's job to make all formats accessible in a unified way. We don't need this to be perfect, if some format can't be supported because it needs too much extra effort, that's okay. And we don't need to test this with all formats, just a few important ones, to see whether it basically works. But at a minimum we should support a format switch that, in theory, allows all available GDAL formats and probably a switch to set GDAL options. There are some options hard coded for the spatialite format which will not apply everywhere. We'd also need a way to discover what formats are available. And the documentation must mention the options and that there is the special case of the Spatialite database with the extra tables.
If you want to give it a try, I'll consider the change.
Osmcoastline uses SQLite driver as GDAL driver, and outputs a spatialite database. This requires a proper install of GDAL with SQLite driver, which is non-trivial for many people (including myself, and another example), since SQLite is not a build-in driver in GDAL.
I would like to add a command line option to use "ESRI Shapefile" driver, and output a shapefile. ESRI Shapefile is a built-in driver in GDAL, and shapefile is a widely used geospatial data format. This will provide additional flexibility to users, while "SQLite" will stay as the default driver.
Will this add value to osmcoastline? I can help create a pull request. Thanks!