The Evolution of Locations
This is just a quick post to describe our current view of how Origins will handle locations so that we can continue to collect some feedback. While much of this is built already, none of it is set in stone, so we welcome your feedback.
We’ve previously written about our approach to Locations here and here. This post is an evolution of that thinking as we continue to build Origins.
First of all, it is important to know that Origins treats Locations as first-class citizens. This means that you can edit and manage Locations just like People, Facts, Sources, etc. We’ll provide more details on this later, but for now it means that Locations are as important as anything else Origins does.
The following screenshot shows what we currently have built for Locations. This is specifically from the process of adding a Fact, but it will be similar for all instances where you are working with Locations.
See the details below for information on each of the numbered sections.
- Select which type of data you want to include with this Fact. The “Location” section shows up below because we have it selected here
- When specifying a Location for a Fact, you can choose to pick from a Location you’ve entered previously by selecting it here. If you select a Location from this dropdown, the fields below will be automatically filled in
- Or choose to enter a new Location by filling in the fields manually. Note that by default, only the Country field is shown. I’ll cover how to add additional fields when we get to #6.
- In this screenshot, I’ve added three additional fields: State, County, and Municipality. For most of the fields here, as you type a value, the field will automatically suggest possible locations. We’re still working on exactly how we’ll populate the list of locations we use to make these suggestions, but it will certainly include values you’ve entered into each field previously.
- Clicking on this icon will remove a field that you have added
- Clicking on this icon will present a pop-up list of available fields. I’ve included a screenshot of this pop-up as it currently stands below, but we’re still tweaking the fields and labels for the fields that will be included. Also, see the information below about renaming fields.
- This is how Origins will display the location information on screen and in reports. The value shown here (“Drexel Hill, Delaware County, Pennsylvania, United States”) is generated based on the values you enter. Specifically, Origins will ship with a formula for each country (as well as a “catch-all” as a fallback for countries we can’t determine a specific formula for) that will determine which fields will be included in this value and which order they will be included. One thing to note about the values here is that each one has a border around it. You’ll be able to click and drag/drop these values if you want to rearrange the order they are displayed in, or remove them entirely. You’ll also be able to drag any field from section 4 down to include it in the Display Value. If you do change the Display Value from the default, you’ll be able to specify if you want to make this change just for this Location, or if you want to change the formula for all Locations in the specified Country.
- If you choose, you can specify a “short name” for a Location. By default the short name will only be used in the dropdown list of existing Locations shown at #2 above. You can choose, however, if you’d like to use it as the Display Value for the Location everywhere it is shown (with the option of using the full display value in reports). Our thinking here is that for some Locations, the full value is overkill. I don’t need to see “Drexel Hill, Delaware County, Pennsylvania, United States” all the time, simply “Drexel Hill, PA” is sufficient but I want to be able to capture all of the information and easily switch over to using it if I’m printing a report for others, for example. Short names are optional.
Available Fields
Here is the list of fields we are currently supporting. As I said above, this list is not final. We are still going back and forth on the fields in Orgins and know that we need to spend some time on this – especially to get rid of the very definite US-only bias that the list currently reflects.
Selecting a name from this list will add a field (or two fields in the case of GPS Coordinates – one for Latitude and one for Longitude) to the UI and allow you to specify a value for that field. In the screenshot here, Country is already in the UI, so it is not available in this list to add again.
Renaming Fields
We’ve given the fields certain names, but they may not be the names you want or need to use. So we let you rename them. Right-clicking on any Location field will show the following menu:
Here you have two options:
- Edit label for this field: This will allow you to change the label for a field just this one Location. For example, if you need “Province” instead of “State” for this Location, you can do that here
- Change default label for this field type: This is a global option – it will allow you to change the label for every instance of this Location field, or alternately, all that have not been specifically changed individually.
There are still some details and problems we need to work out for renaming fields, but nothing too significant. Also, we’re going to allow you to select a “default” set of labels when you start Origins (or at any point after you’ve started). If, for example, most of your Locations were going to be in Canada, it would be nice to be able to default to “Province” instead of “State” rather than having to change each one individually, or use the global rename shown in the above screenshot.
Master Locations
Every Location you enter is automatically saved for reuse. This capability is sometimes called “Master Locations”. You can choose to not add a new Location to the Master List, at the time you create it, or later through a maintenance page.
You can also choose, when reusing a Location (by selecting it in the dropdown shown at #2 above) to “clone” it rather than simply reuse it. This means that you can save some typing if most of the information for a location is the same, and will create a new Master Location (if you choose) with whatever edited information you provide.
Other things you can do with Master Locations, include:
- Report on all Facts or People who are associated with the Location
- Edit the Master Location and choose to apply those edits to all, none, or some of the Facts/People associated with the Location
Alternates
Locations change, either because of political boundary changes, natural disasters, or any number of other reasons. We don’t have all of the details worked out yet, but we want to allow you to specify alternates for a Location. At a basic level, a Location is a specific place on Earth. But the name by which it is known might change. Sometimes, the Location itself might actually move from one place to another. We want to support that but are still working out the specifics. Initially, we’re thinking this will include the ability to specify the dates for which an alternate is applicable for a Location. Beyond that, we’re still kicking around ideas.
Miscellaneous
- If you provide GPS Coordinates (Latitude/Longitude) Origins can calculate the approximate distance between Locations, show Locations on a map, etc.
- Alternates will include the ability to simply specify an alternate name or alternate spelling for a Location
- Like People, Facts, Sources and all other “things” Origins manages, you can include Notes about a Location.
We’re still figuring out what we can include in version 1, so some of this may fall back to a later version, but we’re trying to fit as much into v1 as we can.
I’m sure I’ve missed something in this post, but it should give you an idea of where we’re going with Locations. As always, comments are welcome.
— Dave
This is looking good Dave, can you give us an updated sense of timing as to when V1 will be available?
Sorry, Joanne. Somehow I missed the notification about your comment. 🙁
I’m really hesitant to take a guess. Every other date I’ve put forth has long since some and gone. Like most developers, I am *horrible* at estimating. For now suffice it to say that we’ve made huge strides and hope to have a beta out “soon”. Sorry I can’t be more specific.
Dave
Agree with your approach. Adding that I want more than the typical 4 levels (tuple) often provided. Currently, I add a fifth (most refined) level that represents a specific structure / building / etc. Often, this is just a street address for a home or similar. But it may be an institution. In which case I may need a 6th level as well. I have hospitals that physically move over time (location of birth) — same institution but new building / street address.. I have streets renamed and renumbered that change the street address it is known by. So physically stays the same GOS coordinate; just labeled on maps differently. Or I want to use the 5th as the Cemetery name but add a 6th to the tuple that is the actual grave location (section, plot, etc). It really comes down to how much of world history do you have to capture to maintain a database of your relatives in a convenient, process-able form that can be captured and sent to others? And should that history in the location capture the history of the geographic world (political boundaries, land masses, etc)?
Do you deal with when the city decides development overrides and then moves a cemetery and the graves? What if only some of the graves? Or I have a place nearby where they allowed a high-end housing development to be built without moving a cemetery of the area founders from the early 1800’s. They defined a house plot that cuts through the middle of the cemetery — one marked with historical head stones. 1/2 the stones are inside this homeowners now fenced yard and half outside in what was left as common area. They did not even attempt to move the cemetery plots that were inside the new yard! (Why anyone would buy such a house setup that way, I will never understand.) So 1/2 the plots are now inaccessible as they are inside a fenced, private home-owners yard.
I fully agree that locations need to be 1st level objects. And I treat cemeteries and similar items as such. Include letting them have source citations and media attached.
(FYI, first comment. The grey used for text in your fields and the check mark boxes is so light to barely appears visible on my monitors and tablet screen. Extremely difficult to edit the text and find the check boxes to click.)
Thanks for the feedback, Randy. Great stuff in your comment(s). To try and answer some of your points:
Not everything you mentioned, but some. We’re still working on the details for some edge cases and other possibilities so the feedback is great.
Thanks,
Dave
As there are no dates on the Comments, I am wondering if you are still working on this project? I ask this due to the fact that the form to be kept informed of your progress does not appear anywhere as well. As this is my first time to your site, I just ran across your DNA Manager while looking for a Descendant Chart template (still haven’t found a simple version),.
Respectfully,
Bobb
Hi Bobb,
Yes, we are still actively working on Origins, and will be updating Match Manager in the future as well. Things are going slower than we had anticipated, though, due to…life.
We’ve had intermittent problems with the sign up form not working for certain browsers, but haven’t been able to reproduce it to fix. You can access the form directly here: http://eepurl.com/ctHu3X.
Thanks,
Dave
One of my frustrations with existing genealogy software applications is that they do not accommodate the fact that borders change with time. For example, many of my ancestors are from early Virginia, part of which later became West Virginia. The counties that are currently in West Virginia were Virginia counties pre-Civil War. My genealogy software does not provide assistance in this regard by coupling the date of an event with the location. Instead, it provides a question mark and a comment “Resolve unrecognized place name”. In order to resolve the “error”, I must tell the software that an ancestor who was born in 1840 in Nicholas County, Virginia, was born in 1840 in Nicholas County, West Virginia, which of course did not exist. In as much as is practical, it would be nice to build in a geography helper that couples event date with event location (like AniMap).
Hi John,
Thanks for the comment. I completely agree on the frustration of fixed locations and enforcing them. We’ve gone around and around on how to handle shifting boundaries and have come to the conclusion that for version 1, we will simply not restrict you to choosing from one of our fixed locations – you can essentially put in anything you want and add it as a new “fixed location”. In the future, we’re going to tackle “location x used to be a part of location y, but is now part of location z”. We have some ideas on how to do this, but it is incredibly complex to program in the rules correctly, which is why it will come later. AniMap is one of the programs we’re looking at for getting this correct. Hope that helps to clarify things for now.