Use the Settings page to edit library-specific settings related to Location Service.
1. Drawing colour and opacity of maps
The drawing colour specifies the colour used to indicate the map location of a publication. Opacity, in turn, specifies the transparency of the drawing colour.
Drawing colours and opacity can be specified for the entire service or for individual maps. The default settings defined on the Settings page affect all maps, unless otherwise specified for an individual map. Define the default settings in the Drawing Settings section on the Settings page.
Figure 1. Default settings for the drawing colour and opacity of maps.
Define the drawing colour by entering its hexadecimal character in the Drawing color field. You can use the graphic colour selector, displayed by clicking the Drawing color field, to help you specify colours. The selector automatically enters a hexadecimal character equivalent to the selected colour in the Drawing color field.
The opacity of the drawing colour is defined in the Opacity field as an integer between 0 and 255, with 0 standing for full transparency and 255 for full opacity.
The drawing colour is indicated as a hexadecimal character and the opacity as an integer between 0 and 255, with 0 standing for full transparency and 255 for full opacity.
Location Service allows you to define filters, which are executed before the location is determined. Filters enable location information to be edited before the service searches for the specified location in its database. This function can be used, for example, when a location has several location codes or a location code has several spellings. Filters use the value of the callno parameter passed to Location Service.
Filters defined as active are executed in connection with each location search. They cannot be concatenated; if the location information matches a filter condition, no other filters are executed.
Example: Location identifiers X, Y and Z all refer to the same departmental library. You can enter the library in Location Service by defining only one of the three alternatives, e.g., X, as its location identifier. You then define filters for the other two, indicating to the service that identifiers Y and Z actually refer to X. The filters are executed every time the location is searched and they are defined using regular expressions.
Figure 2. Preprocessing redirects section on the Settings page.
Filters are defined in the Preprocessing redirects section on the Settings page. Enter each filter on its own row. The section always displays at least one row, even if no filter has been defined in the service. The meanings of the fields related to filters are described in Table 1.
Indicates whether the filter is active, i.e., whether it is executed every time a location is searched. Passive filters are stored in Location Service but are never executed.
If this condition is true, the system performs the action defined in the Operation field. The condition is defined using regular expressions.
This operation is carried out if the condition defined in the Condition field is true. The operation is defined using regular expressions.
Table 1. Fields related to filters.
Table 2 lists the filters described above, which indicate to Location Service that location identifiers Y and Z actually refer to X.
Table 2. Filters described in the example.
In practice, the filters listed in Table 2 mean that the letter ‘Y’ or ‘Z’ found at the beginning of the location identifier is replaced with the letter ‘X’. If the Condition column contains a ‘^’ character, the string in the column must be at the beginning of the location identifier. Should the location identifier contain other information in addition to the letter ‘Y’ or ‘Z’, it would not be affected, since the Condition field performs the operation only on the first character, provided it is a ‘Y’ or a ‘Z’. However, if the value in the field is ‘^Y.*’, the letter ‘Y’ and every character following it will be replaced with the letter ‘X’. The reason for this is that the condition ‘^Y.*’ indicates the letter ‘Y’ and any character after it. In regular expressions, a full stop (.) means any character, and an asterisk (*) means 0–n repetitions of the preceding symbol.
Figure 3. Filters described in the example.
Location Service also allows for the use of more complex filters, in which strings corresponding to the conditions defined in the Condition field are used in the Operation field. Strings corresponding to conditions defined within brackets in the Condition field are stored in variables $1–$9, which can be used in the Operation field.
Example: You want to use a filter to add the collection identifier Col in the middle of location information indicated as library ID + shelf ID (e.g., L 001) (the result being, e.g., L 001 -> L Col 001). The exact content of the library and shelf IDs is not important: each may contain letters and numbers. Enter '^(\w+) (\w+)' in the Condition field, and '$1 Col $2' in the Operation field.
Regular expressions are largely based on the use of special characters, which you need to know in order to operate with these expressions. Table 3 lists some of the most common special characters used in regular expressions.
any single character except line break characters \r and \n
the start of the string the regex pattern is applied to. Matches a position rather than a character.
the end of the string the regex pattern is applied to. Matches a position rather than a character.
repeats the previous item zero or more times
repeats the previous item once or more
makes the preceding item optional
word characters (letters, digits, and underscores)
negated version of the above
negated version of the above
whitespace (spaces, tabs, and line breaks)
negated version of the above
Table 3. Special characters commonly used in regular expressions.
Filters are defined using regular expressions. Since Location Service is implemented in the Java language, regular expressions must comply with the syntax used in Java. Further information about regular expressions in Java is available at http://docs.oracle.com/javase/tutorial/essential/regex/
Further information about regular expressions is available at http://www.regular-expressions.info/
2.1 Adding filters
The Preprocessing redirects section always displays at least one row, even if no filter has been defined in the service. If the system does not yet have any filters, you can enter the first one on the empty row. Otherwise, click Add under the Preprocessing redirects heading to display a new empty row. You can then enter the required information in the Condition and Operation fields and finish by clicking Save.
NB! Clicking Save will also save any changes you made to other filters or settings on the page when adding a new filter.
2.2 Deleting filters
To delete a filter, click the red cross on the same row. This erases the Condition and Operation fields and unchecks the Active box. You must still click Save to delete the filter from the service. As a rule, filters with empty Condition and Operation fields will be deleted from the service when filters are saved. In other words, you do not necessarily need to click the red cross to delete a filter, but can simply leave the fields related to it empty.
Location Service allows you to create redirects for editing and re-defining location information if the Location Service database does not return any matches to the location search. Redirects are executed only when the service does not find location information at the level of library, collection or shelf, while filters are executed every time a location is searched. Similar to filters, redirects use the value of the callno parameter passed to Location Service.
Figure 4. Location not found redirects section on the Settings page.
4. Filter or redirect?
The main difference between filters and redirects is that they are executed at different stages of the process. Filters are executed in connection with each location search before actually pinpointing the location, while redirects are executed only if the location searched cannot be found. In many cases, both methods lead to the same result. In such cases, redirects are a better choice than filters, because they are executed only if no location is found. Since filters are executed every time a location is searched, their unnecessary use should be avoided in order to maximise performance.
5. Settings for the Exporter interface
Use the Exporter interface section on the Settings page to edit the access settings for the Exporter interface, which allows for XML transfers and searches in Location Service. The interface can be defined to allow access to everyone or be available for specific IP addresses only. The meanings of the fields related to the interface are described in Table 4.
Figure 5. Settings for the Exporter interface.
If this box is checked, the interface is available to all users. If not, access is only granted to the IP addresses listed in the Allowed ip addresses field.
Allowed ip addresses
If the interface is not available to everyone, only the IP addresses listed in this field can access it. One IP address per row. When defining IP addresses, you can use ‘*’ to substitute for characters. For example, ‘123.456.7.*’ grants access to all addresses beginning with ‘123.456.7.’.
Table 4. Fields in the Exporter interface.
If you want to use the functions of the Exporter interface in page template scripts or plugins, it is best to make the interface available to all. Although scripts and plugins are located on the Location Service server, they are executed in the user’s web browser, meaning that the call to the Exporter interface is sent from the user’s IP address.