Skip to main content

Opensteetmap Data Models

Opensteetmap is the crowdsourced mapping of the planet and can be accessed at https://opensteetmap.org

The map data is freely downloadable and can be hosted locally for any purpose whatsoever under GPL license. Map data is downloadable in multiple archive formats like pbf (Protocolbuffer Binary Format) and others.


OSM's internal data model is represented as shown in the ER diagram above, but when it's imported from the PBF, it has to be efficient, fast and easy to use. Primarily, OSM databases can either be,

  1. Snapshot or 
  2. Historical
Snapshot databases don't contain historical infromation (for instance, how a river changed it's course of the years or how landuse of a forested land changed over the year) whereas, Historical database contains this information. Naturally, historical databases are much more complex and requires more effort.

Various parameters on how to judge various data stores are,
  1. Updatability
  2. Transactibility
  3. Concurrent Read/Writability
  4. Snapshot/Historical ?
Few of the various data store usercases used by OSM community and developers are,
  1. API DB - This is the original PostgreSQL (not PostGIS) database running at the main OSM server.
    1. Updatable
    2. Full transaction support
    3. Full concurrent reads/writes
    4. Full historical data
  2. osm2pgsql - This is the primary datastore used by renderers like Mapnik.
    1. Updatable
    2. No transaction support
    3. Single writer/multiple reader
    4. Snapshot
  3. pgsnapshot - This is a popular schema generated by osmosis tool. It's mainly used for analysis.
    1. Updatable
    2. Snapshot
  4. Normatim -  This is a schema used primarily for geocoding and searching. Generated by osm2pgsql
    1. Updatable
    2. Snapshot
It's important to choose datastore that is appropriate to the usecase, because GIS queries can be damn expensive especially when the records can be in multiple gigabytes.

Labels:

Comments

Post a Comment

Popular posts from this blog

Multimaster replication with Symmetric DS

Symmetric DS is an awesome tool for trigger based replication whcih works for all major database vendors, including but not limited to PostgreSQL, MySQL, MSSQL, Oracle and many others. Symmetric-DS is a java application and can execute on any platform on whcih JRE is available including Windows and Linux. Trigger based replication, in constrast to disk based (eg. DRBD ) or transaction log file shipping based or statement based , works by registering triggers on DMLs and sending the data thus generated to remote machines. Another very popular trigger based DB replication tool is Slony . Symmetric-DS in addition to being database agnostic also supports multi-master replication (MMR). MMR usecase involves multiple database nodes, connected in a pool with DML updates coming from any of them. This is different from the normal master-slave replication, where slaves are not expected to generate any data events, and the sole authority of database is the master. MMR requirement causes d...
1 comment
Read more

Reset root password RHEL/Rocky/CentOS 9

Unlike the earlier versions of Rethat variants, version 9 doesn't allow single user mode to change password, as maintanance mode in 9 requires root password . Single user mode (runlevel 1) can easily be obtained by appending the word ' single ' at the end of the line starting with 'linux' by editing the entry in boot menu by pressing ' e ' at boot menu. To reset the root password on the other hand, one requires to follow a specific set of commands, At the boot menu, edit rescue mode to append 'rd.break ' at the end of the line starting with kernel. Boot with the edited line by pressing Ctrl+X or F10. At the new prompt starting with switch_root, type the following commands, mount -o remount, rw /sysroot chroot /sysroot touch /.autorelabel passwd <new root password> exit reboot       
Post a Comment
Read more

Devstack installation with cells in multiple machines

  Devstack is a testing and development package for OpenStack . The official devstack website has excellent but terse installation instructions, which could be daunting to a newbie. Normally, a traditional install is pretty straightforward but problems creep in when you have to go for some particular configuration or installation like cells or a simple code-test-debug setup, the information on the main site is insufficient. In this blog, I will enumerate the steps for setting up a cell-ular devstack installation with one parent and one child. Parent will not be instantiating any VMs s it's only a 'command centre'. 1. On both machines, install git and vim, clone the devstack repo using git. yum install git vim git clone https://git.openstack.org/openstack-dev/devstack 2. On both machines, open up the file 'local.conf' inside the cloned directory 'devstack' cd devstack; vim local.conf 3. Copy the parameters below to the file...
1 comment
Read more