mirror of
https://github.com/osm-search/Nominatim.git
synced 2026-02-16 15:47:58 +00:00
Correct some typos
This commit is contained in:
@@ -44,7 +44,7 @@ Next you need to set up the service that runs the Nominatim frontend. This is
|
||||
easiest done with a systemd job.
|
||||
|
||||
First you need to tell systemd to create a socket file to be used by
|
||||
hunicorn. Crate the following file `/etc/systemd/system/nominatim.socket`:
|
||||
hunicorn. Create the following file `/etc/systemd/system/nominatim.socket`:
|
||||
|
||||
``` systemd
|
||||
[Unit]
|
||||
|
||||
@@ -165,7 +165,7 @@ The `railway` layer includes railway infrastructure like tracks.
|
||||
Note that in Nominatim's standard configuration, only very few railway
|
||||
features are imported into the database.
|
||||
|
||||
The `natural` layer collects feautures like rivers, lakes and mountains while
|
||||
The `natural` layer collects features like rivers, lakes and mountains while
|
||||
the `manmade` layer functions as a catch-all for features not covered by the
|
||||
other layers.
|
||||
|
||||
|
||||
@@ -179,7 +179,7 @@ also excluded when the filter is set.
|
||||
This parameter should not be confused with the 'country' parameter of
|
||||
the structured query. The 'country' parameter contains a search term
|
||||
and will be handled with some fuzziness. The `countrycodes` parameter
|
||||
is a hard filter and as such should be prefered. Having both parameters
|
||||
is a hard filter and as such should be preferred. Having both parameters
|
||||
in the same query will work. If the parameters contradict each other,
|
||||
the search will come up empty.
|
||||
|
||||
@@ -203,7 +203,7 @@ The `railway` layer includes railway infrastructure like tracks.
|
||||
Note that in Nominatim's standard configuration, only very few railway
|
||||
features are imported into the database.
|
||||
|
||||
The `natural` layer collects feautures like rivers, lakes and mountains while
|
||||
The `natural` layer collects features like rivers, lakes and mountains while
|
||||
the `manmade` layer functions as a catch-all for features not covered by the
|
||||
other layers.
|
||||
|
||||
@@ -217,7 +217,7 @@ the 'state', 'country' or 'city' part of an address. A featureType of
|
||||
settlement selects any human inhabited feature from 'state' down to
|
||||
'neighbourhood'.
|
||||
|
||||
When featureType ist set, then results are automatically restricted
|
||||
When featureType is set, then results are automatically restricted
|
||||
to the address layer (see above).
|
||||
|
||||
!!! tip
|
||||
@@ -227,7 +227,7 @@ to the address layer (see above).
|
||||
|
||||
| Parameter | Value | Default |
|
||||
|-----------| ----- | ------- |
|
||||
| exclude_place_ids | comma-separeted list of place ids |
|
||||
| exclude_place_ids | comma-separated list of place ids |
|
||||
|
||||
If you do not want certain OSM objects to appear in the search
|
||||
result, give a comma separated list of the `place_id`s you want to skip.
|
||||
@@ -248,7 +248,7 @@ box. `x` is longitude, `y` is latitude.
|
||||
| bounded | 0 or 1 | 0 |
|
||||
|
||||
When set to 1, then it turns the 'viewbox' parameter (see above) into
|
||||
a filter paramter, excluding any results outside the viewbox.
|
||||
a filter parameter, excluding any results outside the viewbox.
|
||||
|
||||
When `bounded=1` is given and the viewbox is small enough, then an amenity-only
|
||||
search is allowed. Give the special keyword for the amenity in square
|
||||
|
||||
@@ -280,7 +280,7 @@ kinds of geometries can be used:
|
||||
* __relation_as_multipolygon__ creates a (Multi)Polygon from the ways in
|
||||
the relation. If the ways do not form a valid area, then the object is
|
||||
silently discarded.
|
||||
* __relation_as_multiline__ creates a (Mutli)LineString from the ways in
|
||||
* __relation_as_multiline__ creates a (Multi)LineString from the ways in
|
||||
the relations. Ways are combined as much as possible without any regards
|
||||
to their order in the relation.
|
||||
|
||||
|
||||
@@ -394,7 +394,7 @@ The analyzer cannot be customized.
|
||||
##### Postcode token analyzer
|
||||
|
||||
The analyzer `postcodes` is pupose-made to analyze postcodes. It supports
|
||||
a 'lookup' varaint of the token, which produces variants with optional
|
||||
a 'lookup' variant of the token, which produces variants with optional
|
||||
spaces. Use together with the clean-postcodes sanitizer.
|
||||
|
||||
The analyzer cannot be customized.
|
||||
|
||||
@@ -129,7 +129,7 @@ sanitizers:
|
||||
!!! warning
|
||||
This example is just a simplified show case on how to create a sanitizer.
|
||||
It is not really read for real-world use: while the sanitizer would
|
||||
correcly transform `West 5th Street` into `5th Street`. it would also
|
||||
correctly transform `West 5th Street` into `5th Street`. it would also
|
||||
shorten a simple `North Street` to `Street`.
|
||||
|
||||
For more sanitizer examples, have a look at the sanitizers provided by Nominatim.
|
||||
|
||||
@@ -10,7 +10,7 @@ There are two kind of tests in this test suite. There are functional tests
|
||||
which test the API interface using a BDD test framework and there are unit
|
||||
tests for specific PHP functions.
|
||||
|
||||
This test directory is sturctured as follows:
|
||||
This test directory is structured as follows:
|
||||
|
||||
```
|
||||
-+- bdd Functional API tests
|
||||
|
||||
@@ -18,7 +18,7 @@ elseif (has 'addr:place'?) then (yes)
|
||||
**with same name**;
|
||||
kill
|
||||
else (no)
|
||||
:add addr:place to adress;
|
||||
:add addr:place to address;
|
||||
:**Use closest place**\n**rank 16 to 25**;
|
||||
kill
|
||||
endif
|
||||
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 9.8 KiB After Width: | Height: | Size: 9.8 KiB |
Reference in New Issue
Block a user