I am a long time and happy user of the Hierarchy model of places. I’ve even done a few time-dependent names and enclosures.
But I have never managed to come up with a clean way to include Post Code (Zip Code in the US) data.
It seems to want to exist outside the Hierarchy, with its own granularity.
Ideas welcomed.
I’ve become a fan of the Place Cleanup Gramplet 3rd party add-on.
It inserts the list of postal codes in a (with a space delimited list) as it cleans up the entry.
Yeah, it has so funky bits. It can be somewhat undependable with the Type. And I always have to change the Primary name to my preferred format.
It also might benefit from a Google option when it cannot find a Place title. Google has a fuzzy search on the spelling of the leftmost civil division while Place Cleanup cannot find a slightly misspelt place.
Are you trying to have the Zip/Postal Code display as part of the Automate Place option?
1600 Pennsylvania Avenue NW, Washington, DC 20500
Cannot be done. And this field goes away in 5.2 and becomes an Attribute.
Ooooh. Becomes an attribute in 5.2?!?
That hurts! Right now Gramps can find a record in the Place Selector via postal code. So I can just 10-key the ZIP and it pulls up the civil revision that post office designated. In the US. that means typing no more than 5 numbers.
and it will also be a problem with the dates, since it is put/written in the same text field as the value of the Attribute (Postal Code) itself…
When I read that, I just went…-> ???
That means it will not be possible to automatically sort any list of postal codes as a chronological list…
Another reason for having dates in addition to citations for attributes…
Ref: https://gramps.discourse.group/t/add-date-field-to-attributes
Yes, and it can change over time. With the latest version (11-digit) individual structures have their own code. Here are some GIS resources: Understanding and mapping ZIP Codes
OK - it looks like this my intuition that post codes don’t want to play nice with a spatial hierarchy was correct.
My only motivation was a slightly OCD drive to record all place information from a record (which might include a post code) into the place heirarchy.
It’s not important genealogically speaking, since the post code remains in the citation/source (I download all records as either images or ASCII).
Thanks for answering my question
H’m, I don’t read it that way. The text says that it’s a recommendation which includes adding citations to attributes, and I really doubt whether that’s on the roadmap already.
Or is it?
It could be indicated in a place event (i.e zip code change), no need to add the date to the code attribute. It will simply reflect what the event says
Yes of course, everything can be indicated in an event, but there is a lot of information that is to “small” to be an event in a genealogy database, and if we should make an event for every time a postal code or similar attribute got changed, wouldn’t that clutter the Event view to the extreme?
In Norway we have changed Postal Codes multiple times, same with the prefix of our “fylker”, it could be thousands of events for something that is nice information to have, but isn’t a “genealogy event”.
There are a lot of other attributes that can be nice to have a date on also.
Just as an example, if I should create a “Zip Code Changed” Event for all the places I use in my family research, I would have something like 8-12000 Events (maybe more) of that type alone… and in my “place database”, that is approx. 3 million events, each address’ postal code has changed 3 times in the time period I am working in, and a few as much as 5-6 times because the addresses have been moved between postal areas individually.
This is why I never register zip codes.
I just have relatively few postal codes in Gramps. (VERY few have been entered manually but the Place Cleanup tool inserted significantly more.) But since they are at the deepest level of the hierarchy, I can use them as drill-down accelerators for the Place Selector.
I don’t see how a list of 5 space-delimited postal codes under a city could ever be useful for a report… Such a list is inherently ambiguous. So they only have a use during data-entry.
Yes, to be able to e.g. get the right place easier when you have a lot of places with the same name in your database in a deep hierarchy, or when you are doing different type of place/event research… It’s okay to have a known and easy to read unique identifier…
Only reason I add them is because of the historical aspect of them in regard of Norwegian administrative hierarchies and the changes in them over time.
Some of my relatives experienced multiple changes both in regard of changes in the changes from “amt” to “fylke”, and how our “herreds” become “kommuner”, and “kommuner” that moved from one “fylke” to another, and multiple changes in the Postal Services and different areas, then later, other relatives experienced the start of using the first Postal Codes, later the changes again when “kommuner” switched to other “fylker”, that of course change the Postal Code, and some of them experienced yet another change in the structure… Then it starts to be interesting to see if it is possible to actually trace these changes and if they had any real impact on their businesses, day-to-day life etc.
But if I should create a report on it, I would have used Excel or more likely a network graph to show all the different changes and connections with dates on the Edges (Connections).
Thats the reason why I just would like to add them as attributes with a date and not an Event… Well, if there was Place Events in Gramps, I would maybe add them as Place Events.
All this is really easy to do in Foam or Obsidian, using Markdown with a YAML header, in at least two different ways… so, I started to do it as part of my research notes instead… it’s easy to create markdown notes in a structured folder hierarchy from a CSV or Excel worksheet, or even with a PostgreSQL query and save the result to individual files… (Just a normal SQL query with a few joins)
In France we have postal codes like any other countries and we have also INSEE codes. INSEE is for National Institute of Statistics. It have numbered each place of the country uniquely (postal code are not uniques in a city) since its creation in 1945 and it maintains its numbering when place changes over times.
Some researchers some years ago have proposed an extension to that numbering to enumerate places created or disappeared before 1945, even for parish who existed before the Revolution.
It gave something like this:
I try to record these codes in Code field. With it i can follow where a place was from time to time adnd easily filter place with some codes (i.e all -1000-.places)
I’ve discovered this numbering few time ago. I don’t know yet if it can be useful but I think it could.
For some places it give me something like that:
Quartier moving from a city to another:
All old parts of a parish which exists before Revolution moving from a city to another:
I’ll see if it’s usefull…
US Postal codes seem to be in decline. The Zone Improvement Plan (ZIP) Codes are only as old as I am. Then the ZIP+4 refinement (do the side of a Street) was added in 1983. But in 2011, the US Postal Service stopped shipping their ‘TIGER/zip + 4’ product. (TIGER is the US Census Bureau’s system.)
The lifespan of Postal Codes (American or European) is likely to be less than a century. So an Attribute makes sense rather than than compromising the database structure of Place Hierarchies with a temporary complexity.
What3Words codes are like GPS coordinates to the 3 square meter resolution. But it seems to be losing traction rather than gaining it. But it make more sense as an Attribute too.
