The wiki database is currently being backed up. Please check back in a couple of hours.
GEPS 006: Better Place handling
- 1 Changes already implemented
- 2 Proposed changes
- 3 Motivation
- 4 Some ideas
- 5 References
Changes already implemented
- New place tree view for Gramps version 3.2.
A new place tree view was introduced in Gramps version 3.2.
The place object was left unchanged, but the existing location fields were interpreted as a hierarchy. The location fields are as follows:
The new view displays Country, State and County as a tree.
- New Locality Field for Gramps version 3.3
A Locality field has been added to the location for Gramps version 3.3. The new hierarchy is as follows:
- New hierarchical place structure for Gramps version 4.1
Place objects have been arranged into a hierarchy in Gramps version 4.1
See Hierarchical Place Structure for details.
Integration with online map tools
Which online map tools? - NH
- Openstreetmap, we need free data in a free application. GeoView already allows a view based on places, also to set lat/lon
Good definition of place and address/residence event in Gramps
- For UK data, an extra Locality field between City and Street would be useful.
- For Dutch data, an extra Municipality field between County and City would be useful. (Feature Request 4231)
- Japanese use block names, instead of street names: 
We could re-define each field for each country, or we could try to keep each field maintaining similar data. I think that I prefer adding a couple of extra fields. This is less complex than a list structure with definable number of tiers (less complex to program, but also less complex to use by the user)
|Existing||New structure||General Name||USA||England||France||Netherlands||Germany||China||Italy|
|State||Tier 1||Region||State||Not Used||Region||Not Used||Province||Province||Regione|
- Tier 1 & 2: Between a country and the smallest administrative section, we allow for two levels.
- Tier 3 : A settlement consisting of a number of dwellings varying in size from a hamlet to a city. In some countries this will be a division of the country with a mayor.
- Tier 4 : The locality people identify themselves with. This further classifies tier 3. Examples would include a neighbourhood within a town or city, or a village or hamlet on the outskirts of a town or city.
- Tier 5 : Street or block, so the lowest division needed for postal information.
Tiers 3, 4, and 5 look quite consistent between countries so far. - NH
- UK: the Church Parish field we have at present may be redundant for current places but it's often the only information given in early historical records. This may also be true outside the UK.
We would need a country table. This would hold the field definitions for each country including the field names, 'not used' flags, and which fields should be used in the place tree view.
This data could then be used to dynamically create fields in the place editor, place filter and place tree view.
- we should not work with 'not used' flags. Eg, some people in Wales might want to enter it. A not used flag would make it impossible. In the USA, people from Clairemont  might like to indicate that, however it is a neighbourhood. Instead I would suggest perhaps a address format default. For UK this would be I suppose:
Street Locality City County Post Code Country
- for Belgium this format would be
Country ZIP Locality (City) street
- with a format field and people seeing this format, they will understand how they are supposed to enter the place information (note that if Locality equals city it obviously must not be repeated.
Your example of Clairemont is exactly what I intended the Locality field for. Its use is not limited to the UK. - NH
Questions and Design Decisions
- Do we need 2 or 3 tiers between the level with a mayor and the country? We only take 2 tiers. Most countries have more than 2 tiers, but they have little importance for the inhabitants or genealogy. What about Feature Request 4231?
- Many countries have different sub-levels depending on the country. Yes, but Gramps is not a place storing application. In Countries like China you have province or autonomous region or .. as Tier 1. We can only provide one label, the users must himself understand that a locality in an autonomous region should put the name of the region in the Tier 1 (Labeled province) field. Or we could make the label read "Province/Region" if appropriate.
Issues specific to the UK
- When entering data into the country field there are a few possibilities. "UK" could be used as the country, or one of the constituent countries may be used (England, Wales, Scotland, Northern Ireland). Other terms such as GB, Britain or British Isles may also be used. A thread on the mailing list discussed this  and three different methods are used at the moment (UK, GB and constituent countries).
- If constituent countries are used in the country field then the state field will not be used.
- If "UK" or "GB" is used in the country field then the state field may optionally be used to qualify the constituent country.
- Questions are often raised about how to record London addresses. At the moment the county field could be used to store "Greater London", "London", or a historic county for the London borough. The city field could be used to store "London" or the name of the London borough. The new Locality field may be useful to record the London borough.
- When we upgrade the database we need to take into account the different possible values in the country field.
Define one ideal way of working with alternative place
Physical places can have more than one name and can move between administrative regions over time. The following list gives examples of why places need alternate names:
- Places can change their name over time.
- In countries where more than one language is spoken the place may have different names in different languages.
- Multiple names for a place may exist where there are variant spellings for the place name.
- Different names may be used for political reasons.
For genealogical purposes it is important to record the place name as it appears in the source material. We could define alternative places with a date span. There may be one or more alternative places within a given date span.
Improve the place tree view
At present the place tree uses a three level hierarchy of Country, State and County.
For some countries the State field is not relevant - for example in the UK. In this case it is more useful to display a Country and County or Country, County and City hierarchy.
Countries also use different descriptions for the their administrative regions. We could change the column headings according to the country displayed. This would require a countries table in the database. We could also restrict the view to displaying only one country at a time.
Improve data entry in the Place editor
We could use drop-down lists in the place editor to allow the user to select values for each of the hierarchical fields. The data could come from data already in the database or we could consider building up a gazetteer for Gramps.
- Country is a GrampsType field, with known countries predefined. This gives us translated countries.
- based on country, the normal divisions are set bold. All divisions can be entered however
- Translation of labels is based on country, with fallback to the general. A Tier will have different translations depending on the country it is in. However, we must be carefull not to translate everything before Gramps can start up. Eg, we define, COUNTY= _('County), USA = (STATE, None, COUNTY, ...), where None is used to indicate to use the general name of the field, and this long list of countries is not kept in memory but constructed when a county is needed.
The place editor could be made clearer if the hierarchical fields were placed together in the editor window.
Time and again users pose questions on improving the place structure of Gramps. This GEPS is about defining a new improved way of handling place, keeping backward compatibility with GEDCOM/present Gramps.
Many things are also not well designed, in that Gramps allows the user to do as he likes, without guiding the user to a good way of storing place data. (this statement is disputed, see discussion)
Some relevant bug tracker entries:
- 1862 Place Guessing Feature Request
- 2196 Some changes to the Places viewer would be helpful
- 2311 Implement a place database ...
- 4230 Places tree view gives confusing place names
- 4231 Add Municipality to places data
- 4510 Additional Suggestion
- 4712 Eliminate case-sensitivy when searching city names in place completion tool
- 4714 Superwide resize after adding lat/lon