X-Git-Url: https://git.openstreetmap.org./nominatim.git/blobdiff_plain/a90ace7fa111bcff511eafc7457ac3aca310f96d..b9b6b075cc3cc12daa5ba48742e010b3e5e9550e:/docs/develop/Import.md?ds=inline diff --git a/docs/develop/Import.md b/docs/develop/Import.md index ddddb1a8..c9612bb3 100644 --- a/docs/develop/Import.md +++ b/docs/develop/Import.md @@ -1,8 +1,8 @@ # OSM Data Import -OSM data is initially imported using osm2pgsql. Nominatim uses its own data -output style 'gazetteer', which differs from the output style created for -map rendering. +OSM data is initially imported using [osm2pgsql](https://osm2pgsql.org). +Nominatim uses its own data output style 'gazetteer', which differs from the +output style created for map rendering. ## Database Layout @@ -22,14 +22,14 @@ The gazetteer style produces a single table `place` with the following rows: A single OSM object may appear multiple times in this table when it is tagged with multiple tags that may constitute a principal tag. Take for example a motorway bridge. In OSM, this would be a way which is tagged with -`highway=motoway` and `bridge=yes`. This way would appear in the `place` table +`highway=motorway` and `bridge=yes`. This way would appear in the `place` table once with `class` of `highway` and once with a `class` of `bridge`. Thus the -*uique key* for `place` is (`osm_type`, `osm_id`, `class`). +*unique key* for `place` is (`osm_type`, `osm_id`, `class`). ## Configuring the Import How tags are interpreted and assigned to the different `place` columns can be -configured via the import style configuration file (`CONST_Import_style`). This +configured via the import style configuration file (`NOMINATIM_IMPORT_STYLE`). This is a JSON file which contains a list of rules which are matched against every tag of every object and then assign the tag its specific role. @@ -55,8 +55,8 @@ suffix match can be defined similarly with a string that starts with a `*`. Any other string constitutes an exact match. The second part of the rules defines a list of values and the properties that -apply to a successful match. Value strings may be either empty, which again -means that thy match against any value, or describe an exact match. Prefix +apply to a successful match. Value strings may be either empty, which +means that they match any value, or describe an exact match. Prefix or suffix matching of values is not possible. For a rule to match, it has to find a valid combination of keys and values. The @@ -66,7 +66,7 @@ The rules in a configuration file are processed sequentially and the first match for each tag wins. A rule where key and value are the empty string is special. This defines the -fallback when none of the rules matches. The fallback is always used as a last +fallback when none of the rules match. The fallback is always used as a last resort when nothing else matches, no matter where the rule appears in the file. Defining multiple fallback rules is not allowed. What happens in this case, is undefined. @@ -121,17 +121,17 @@ One or more of the following properties may be given for each tag: * `address` - At tag to the list of address tags. If the tag starts with `addr:` or + Add tag to the list of address tags. If the tag starts with `addr:` or `is_in:`, then this prefix is cut off before adding it to the list. * `postcode` - At the value as a postcode to the address tags. If multiple tags are + Add the value as a postcode to the address tags. If multiple tags are candidate for postcodes, one wins out and the others are dropped. * `country` - At the value as a country code to the address tags. The value must be a + Add the value as a country code to the address tags. The value must be a two letter country code, otherwise it is ignored. If there are multiple tags that match, then one wins out and the others are dropped.