[OSM-dev] First beta release of new OSM data storage for tile servers

[Robert Buchholz]

On 03/17/2015 02:53 PM, Jukka Rahkonen wrote:
> Hi,
>
> Is is possible to use COORDS for all kind of geodata? Is it possible 
> to import data from PostGIS into COORDS
Not currently. A COORDs storage currently consists of two parts: raw OSM 
data, and geometry tiles.

The first part stores unprocessed OSM data (ways, nodes, relations) and 
array indices into these data files (mapping an OSM entity ID to that 
entity's position in the data file). This part is specific to OSM, and 
is necessary to allow for the (planned) application of OSM replication 
diffs (e.g. when a way from a diff references an already existing node, 
the position of that node has to be retrieved from these index files).

The second part of the COORDS storage stores the actual geometry tiles 
used for data retrieval. They currently store serialized OSM ways. But 
this storage format will likely change to store point, line and 
multipolygon features with arbitrary attributes. This second geometry 
tile storage is currently created from the first storage of unprocessed 
data. So there are some dependencies on OSM data structures.

However, if there is sufficient need, one could write an adapter that 
directly creates the geometry tiles directly from another data source 
(e.g. from a PostGIS database) and bypasses the creation of the first 
part. But that is not currently implemented or planned.
> could it be possible to write a GDAL/OGR driver for COORDS?
I am not familiar with the exact interface that a GDAL/OGR driver would 
need to implement, so I cannot give you a definite answer. The COORDS 
Mapnik plugin (currently the only consumer of COORDS data storages) get 
passed a query bounding box and optionally a list of geometry attribute 
names that should be included in the reply. It then returns the geometry 
features (currently only line strings or simple polygons) along with the 
list of attributes for each feature. As long as the GDAL/OGR interface 
is sufficiently similar to that of Mapnik (i.e. it also sends a query 
bounding box, and expects attributed features to be returned), writing 
such a driver should be possible.