Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

Primary mentor


Backup mentor


Assigned to





This project  creates full-fledged attributes for Location.

It is also proposed that the location table be modified to have fields for a hierarchical reference. See Design below.

Project Champions

Roger Friedman


  1. Add Location_Attribute and Location_Attribute_Type tables per new paradigm.
  2. Modify admin page to maintain Location_Attributes and Location_Attribute_Types
  3. Modify  web services to expose Location_Attribute and Location_Attribute_Type as resources.
  4. Add hierarchical reference fields to Location
  5. Add a graphical hierarchy editor for Location 

Note that, and .description should be of type LocalizedString if that is going to be implemented.




For the new paradigm for attributes, see Visit Attributes

The remainder of this section will address the design of the hierarchical reference fields. Note that the data model includes a parent link, which is fairly standard but not the easiest way to load a tree diagram or otherwise edit a hierarchy. The typical hierarchy number is made of a fixed number of digits (usually 2) for each level, so that the 4th child node on level 3 of the 3rd child node on level 2 of the 2nd node on level 1 (assuming a tree with a hidden root on level 0) would be 020304. The information available from this number is that node 020304 is on level 3 (because the number is 6 digits long); there is no way to navigate the tree from this number.

The tree-walk hierarchy consists of two numbers: a left node (L) and a right node (R), which is shown in the diagram below as L:R. Starting at the root, a canonical tree walk is performed; as each node is passed, it is given a sequential number. Each node is passed and numbered twice – once coming down the left side (the L number), and once going up the right side (the R number). The information available from these two numbers is much richer: a node has (R-L-1)/2 children; its left sibling (or parent if it is a leftmost sibling) has its L'=L-1; its right sibling (or parent if it is a rightmost sibling) has its R'=R+1; the node is a leaf node if R=L+1; its leftmost child has L'=L+1; its rightmost child has R'=R-1. About the only useful detail missing is the level number.


The tree editing process requires updates of both Ls and Rs. When inserting a new node as a leftmost child or right sibling of node L:R, the new node will be L+1:L+2; all L's and R's in the tree >R must be increased by 2. When deleting a node L:R, all L's and R's in the tree >R must be decreased by 2. This can be extended to moves of entire subtrees.


  • No labels


  1. Roger,

    I'm a bit confused by this project.  Tags are strings attached to an entity (like tagging of blog entries) to form a folksonomy and/or to categorize data.  It sounds like you're asking for location attributes (i.e., allow for local extensions of location definitions).  Is that correct?  What's the goal of this project?  Is it to allow for locations to be categorized?  Or is it to allow for implementation-specific attributes for locations?


  2. A large piece of this project is/will be done in OpenMRS 1.9. Roger, can you rewrite the description after that has solidified?

    1. Darius –
      If the last two objectives are dropped or futured, doesn't that give what we want for 1.9? Or do you want me to ticketize this like provider attributes?
      Is there anything else that needs to be added to the management page, like maybe address format management? Do we want to do anything to integrate the address hierarchy module, such as have the address hierarchy page be an option of Manage Locations or copy the location list import from address hierarchy?