How should chronology relations be organized in regards to place nodes and boundary relations? It seems clear that a place that is not organized with specific boundaries should exist within a chronology relation as a series of nodes representing each change to one of the appropriate tags (e.g. a place=isolated_dwelling followed by place=hamlet followed by place=village followed by place=town) and that a place that is organized from the outset should be represented within a chronology as a series of admin boundaries representing a change to the boundary relation (such as because the boundary changes over time or for the same reason as changes to a chronology relation for a place with only nodes, that is, a change affecting one of the tags; e.g. a small boundary on with a place=town label node followed by a slightly larger boundary, followed by a slightly larger boundary again with a place=city label node, etc.).
But where I am uncertain is when it comes to a transition from an unorganized place to an organized one, like a place=village node becoming a boundary relation with a place=town label. Should there be two chronology relations, one pre-organization (with all the individual nodes) and one post-organization (with all the boundary relations) nested within a super-chronology relation or should they all simply be placed within a single chronology and just switch from nodes to boundary relations upon organization?
I’ve been maintaining two different chronology relations: one for the populated place as it evolves, and one for the evolving boundaries of the administrative subdivision that was created around the populated place. For example, Indianapolis is both a chronology of boundaries and a chronology of places. For a more extreme and complete example, San José is both a chronology of boundaries and a chronology of places. Each member of the latter is a member of one or more members of the former – sometimes hundreds of them. In some cases, one chronology predates the other.
I set place=yes on the place of Lansing chronology to indicate that it represents a place, but I’m not sure if theres a more specific value I can use that doesn’t imply the entire relation is one thing (e.g. city, town).
I hope everything looks right, it’s really quite confusing trying to navigate between half a dozen relations that all have the same name. I might set the name key to something like “City of” and “Township of” even though in the acts of the legislature it seems like only “Lansing” is the name, as it’s typically written “city of ‘Lansing’” or “township of ‘Lansing’” but not “‘City of Lansing’” or “‘Township of Lansing’”, so it would be slightly ahistorical.
In my opinion, there’s no strong need to qualify the chronology further; the two can have similar tags and it would be obvious what they represent based on the members. However, there is some usage of chronology=* (a fun example), or you could use the name=* to disambiguate.
Should the township’s relation have “Lansing Charter Township” or at least “Lansing Township” in the name, similar to other townships in the state? wikipedia=* and wikidata=* tags would be nice for that relation too.
We really need the website and JOSM to automatically append the date range to each relation’s label, as in iD:
I think I’ll set name for the Lansing township relations to Lansing Township and set official_name=Lansing, pending me finding a legal name change that actually does name it as Lansing Township and/or Lansing Charter Township. So far (and I’ve only looked at the initial organization law so far, so not much) I’ve only seen it named as “Lansing” in quotes (usually with “township of” outside quotes) so I’m tempted to say that at least for the initial boundaries, the official name is simply “Lansing”. I’ll try to find the initial Code of the (Charter) Township of Lansing to see if that makes explicit mention.
I think following that logic, the boundary relations for the city of Lansing should also be name=City of Lansing (but not the place node), though I don’t know if that’s necessary. Could be helpful though.
As for the chronologies other tags, I’ll go ahead and remove place=yes and set chronology to place or administrative, as appropriate. Unless you (or someone else) has a better suggestion.
The admin level does show up next to the relation name within square brackets in JOSM, so I’ll just have to remember to check that for now, and
Thanks for the help so far.
Oh, and I’ll make sure to add the wikidata and wikidata for the township.
For sure, the place=* point should be named just “Lansing”, since it’s tangential to any government structure. Nominatim gets confused if the place point and boundary relation have different names. Fortunately, it can recover somewhat if the place point is a label of the boundary or if they two features have matching wikidata=* tags.
I think the usual practice in most of the U.S. is to append the generic to the name of a township or county but omit it from the name of most municipalities. Plenty of municipalities have a generic in the name, but as a suffix (“Traverse City”) rather than a prefix (“City of Traverse”). That said, the prefix form is extremely common and unavoidable in New York due to that state’s tendency to name adjacent towns and villages exactly the same as each other, so there’s precedent either way.