Marble/OSMNaturalEarth

From KDE TechBase

Natural Earth Dataset derived Zoom Levels

Introduction

While we use the actual data provided by OpenStreetMap for all higher levels (starting from level 9/11) we want to use the Natural Earth Dataset for all the lower zoom levels. The style is supposed to mimic the default styling of the OpenStreetMap dataset as close as possible (to guarantee a seemless user experience).

Data Import

Sources

Natural Earth provides data in three levels of detail.

Large Scale Data (1:10m)

Cultural [1] Physical [2]

Medium Scale Data (1:10m)

Cultural [3] Physical [4]

Small Scale Data (1:100m)

Cultural [5] Physical [6]

Conversion from SHP to OSM

The vector data provided by Natural Earth is in SHP format. In order to create vector tiles, this data needs to be converted into OSM format. Two mechanisms were being considered for converting files from SHP to OSM. The first mechanism involves usage of polyshp2osm[7] tool. The second mechanism involves building a custom converter on the lines of the existing shp2pn2 tool of marble.

polyshp2osm is built upon the GDAL/OGR python bindings. GDAL/OGR is a library for reading/writing raster and vector geospatial formats. It presents a single abstract data model, for all the formats, to the calling application. polyshp2osm reads the SHP file into this abstract data model and then loops over all the possible geometries to figure out the nodes, ways and relations of the corresponding OSM file. In this regard it is quite similar to the shp2pn2 tool which reads the SHP file into a GeoDataDocument. However, polyshp2osm is limited in the sense that it provides support only for polygons and not for linestrings and other geometries. In fact, it throws an error if we try to convert SHP files containing linestrings like ne_10m_roads and ne_10m_rivers_lake_centerlines. Hence in order to make the tool work, it had to extended so that it is able to process geometries other than polygons like linestrings, points etc. This makeshift extension although works well in most cases , lags in a few areas. Thus polyshp2osm lags in geometry conversion and effort must be put in order to perform this conversion properly.

The other area of polyshp2osm is its metadata extraction and tag-mapping. The GDAL/OGR library, on which the converter is built provides direct methods for extracting the metadata for a particular geometry present in SHP file. This metadata is available in the form of key-value pairs. These key-value pairs obtained from the SHP files can be directly mapped to corresponding OSM key-value pairs. However all such mapping from the Natural Earth metadata to the OSM key-value pair has to be put into the polyshp2osm program manually since the polyshp2osm was built keeping in mind the MassGIS OpenSpace dataset and has mappings corresponding to this dataset only. Though the tool(polyshp2osm) provides a framework for tag-mapping, still effort had to be put in analyzing the metadata provided by different datasets of Natural Earth and finding the corresponding OSM key-value mappings.



TBD

Combining datasets

TBD

Mapping different resolutions (1:10, 1:50, 1:110) to zoom levels

TBD