Use of Chronology relations for populated places (USA)

I have finally embraced the chronology relation for place=* when mapping populated places in the United States (Midwest, specifically).

My current workflow is first setting a node with place=hamlet with start date being the plat date or post office date (generally whichever is earlier), then when incorporated as a village or city, setting another node (place=village or place=city) with the legal incorporation date (generally from state government sources). Each of those nodes includes the name=* tag.

Finally, I create a chronology relation for the place nodes that vary with value of place=, and only in that chronology relation add the Wikipedia= and Wikidata=* tags, along with the name=* and the start_date=* being the earliest effective date of that name.

What swayed me to adopt the chronology relation and my justification of the above approach is for linking - the one:many function of the Chronology relation, if added to Wikidata entry as a property, enables the linked-data methodology to map out the instances of the varying start/end times as a hamlet, village, city and the corresponding growth (or dissolution!) of the populated place through time.

Any thoughts, comments, improvements, etc?

Thanks and happy mapping!

Andy

1 Like

One question I do have is adding a place=* tag to the chronology relation for a populated place.

I have seen a couple chronology relation where the current value of place=* has been added to the relation; but I don’t think this is necessary or accurate? Especialy with a start_date=* tag added; this could be misconstrued since it has not been a place=city in fact until incorporated?

I am currently skipping adding a place=* value to the chronology relation for populated places, but I am considering instead using something like place=locality - which is true for all members of the chronology relation- its a named populated place (distinguishable from civil townships, counties, etc., etc.) but no “higher”, more populous values of place=hamlet, place=village, place=city, etc.

Thoughts, concerns, suggestions?

This seems to align with common practice in other parts of the world that have high coverage of populated places, such as Scandinavia and the Philippines. (In Europe, the initial place point’s start date usually tracks when the place was first attested in historical records, and the town or city point corresponds to the granting of town privileges or city rights in Medieval times.)

Unfortunately, the standard place=* values don’t adequately communicate the diversity of legal place designations and their definitions among U.S. states. After all, there are plenty of town-like unincorporated communities and some incorporated communities that don’t look at all like towns.

In the long run, as we build out coverage of local boundaries, we would be able to rely on the more flexible but weirdly named border_type=* key to indicate the official status while classifying the place point based on relative importance using other criteria. In the meantime, be sure to indicate the criteria you’re using via start_event=* and end_event=*.

This practice comes from OpenStreetMap, where at least the U.S. community now frowns upon it. I personally think we should ideally maintain a clear distinction between organically populated places and administrative structures, but the reality is that there’s some interplay between the two.

My suggestion would be to omit place=* from the boundary relation. But you can add the separate place=* point to the boundary relation with the (again weirdly named) role label, which says that the place point is located at the traditional or cultural “center” of town. Otherwise, the renderer will synthesize a point at the geometric centroid, which may be counterintuitive to someone looking at the map.

Yes, this is a big benefit of chronology relations. Linking to the chronology relation using Wikidata’s OpenHistoricalMap relation ID (P8424) property will bring more visibility to your contributions and, by extension, to OHM as a whole.

1 Like

Agreed. Mapping the boundaries of populated places is definitely the next step, and it becomes quite clear cut with incorporated places. However, I think it gets very difficult/confusing/inappropriate with unincorporated places, place=locality, place=hamlet - where there are not legally recognized boundaries and mappers resort to Census-designated places (CDPs), which are useful for the reported statistics on populations and so forth but are not a legal boundary and are subject to wanton administrative changes from decade to decade- so again something good to map in OHM I guess! :sweat_smile:

My current goal is bootstrapping OHM in the Midwestern US, until chasing down the rabbit-hole of annexations, mergers, etc., effectively micro-mapping the administrative boundaries down to the municipal/local level (below counties- civil towns/township, CDPs/incorporated villages/towns/cities) - I just want to get some initial places on the map so we can see just where one is geographically-speaking (and chronologically!) so we can continue to drill-down on historical detail.

1 Like

Love, love, love this. Annexations, mergers, and micromapping of the admin boundaries might feel like minutia, but they can be part of some fairly interesting stories.

Related q: ever hear of Northern Liberties, PA? It was one of the top 10 largest cities in the US through 1840 and was annexed by Philadelphia in 1854.

My heart lies within the rural regions. A four-corners where a post office once operated? Oh yeah I will map that. Logging railroads that operated for a year until they got the cut out? Hours of fun. Old river towns, long abandoned canals- can’t get enough. Lays the ground work for further mapping back into early America- trading posts, military forts, Native American villages and towns, stagecoach routes, Native Amercian trails, treaty boundaries- all need that framework of modern features to help georeference, geolocate and delve deeper into the more obscure.

2 Likes