Are there more feature types that I am just not seeing? For example, if one would like to mark the approximate location of a historic Native American town or village, what feature type would you use? The available option that I can see seems to be all modern. Which I know makes sense since this is all based off of OSM. But…
Perhaps “Settlement”? More generic and non-offensive.
Is there any sort of “Event” feature? Something to cover things like meetings, treaties, skirmishes, conflicts, or battles? Or even major historical figure deaths or births?
Also, how do we recommend more languages for the Multilingual Name? There looks like there are a good many Native dialects listed in there, but missing many that would cover the early European colonization period.
The default city, town and village place= values have to be used to support OSM editors and map renderers.
When 50 map features or more have the same name:code= (e,g. name:es=) the language is rendered by the map, which you can see if you set your prefered language to that language code. So you can map all the villages with the native names. Generally a place is tagged with e.g. name=name_in_country_primary_language + name:es=spanish_name + name:de=name_in_german
Welcome to OHM @Lance! Glad to have you here and that you’re willing to jump right in on the forum.
Events are interesting & we haven’t fully fleshed out how to handle them, but if you’re willing, there are plenty of us who’d like to help figure it out. Right now, TagInfo shows a very limited number of event=* mapped.
Here’s a chronology relation of an invasion I put together: Mongol invasion of the Khwarazmian Empire, where I used a type:chronology relation to tie together a sequence of event=* nodes.
We could use a lot more thinking in this area around how fine-grained of events we’d like to model and if there’s a taxonomy of tagging we’d like to use, how we’d like to represent these activities visually (should big events have a lag time on the map? It’s easy to miss something that happened briefly, but important events often happen quickly. (see: Pompeii)).
Also - we’re trying to use start_event=* and end_event=* and [x]_event:wikidata=* to describe and link to specific events that caused an entity described to a relation to start or begin.
To elaborate on this, we’ve largely inherited OpenStreetMap’s tagging scheme, including their place classification system. Even in the present day, OSM’s place classifications can be unintuitive, as the goal is basically a universally harmonized set of categories that a renderer can rely on to prioritize or deprioritize map labels without factoring in any regional knowledge. To a first approximation, mappers in OSM have been choosing these values based on population and economic or cultural importance (so that sleepy suburbs aren’t necessarily as important as market towns).
Extending this model to all of history is obviously fraught, as population norms and settlement patterns have changed drastically over time. In my own mapping of present-day California, I’ve only gotten around to mapping a handful of indigenous settlements so far, such as So-co-is-u-ka. I tagged it as place=village, which happens to be consistent with how contemporary and modern sources refer to it, but I could see a more prominent settlement being tagged place=town or place=city despite the historical European tendency to refer to every pre-Columbian settlement as a village.
In principle, we could introduce a more generic place=settlement tag and preset, but we’d still need some machine-readable mechanism for classifying major and minor settlements, ideally without forcing the renderer to vary thresholds by region and time period.
You can enter any valid ISO 639 code into the language field, even if the iD editor doesn’t recognize a name for it. If no code has been assigned for the language yet, use a code representing the language family or mis if the language family also lacks a code.
The current list of suggested languages largely comes from Unicode’s CLDR project, but we’ve added to this list over time and can certainly accommodate more indigenous languages. Please open an issue in our issue tracker with any codes you’d like to get added.
Regardless, the primary Name field (name=*) can and should be in the native name, whatever language it was in.
We need to document this better, but if you open the account menu in the upper-right corner of the page and go to My Preferences, you can change your preferred language to any valid ISO 639 code. If you set it to mul, then every label will be based on the name=* tag. Otherwise, every label will be based on name:xyz=* (where xyz is the code you set), falling back to name=*.
Perhaps some of my questioning is going to be out of ignorance of how the system does work, so please excuse that.
Maybe I am misunderstanding the Multilingual Name purpose. For East Coast Native settlements, they often have 3 or more name. One in the local Native tongue, an English, and maybe a French or Spanish (depending on location). That was my train of thought, entering all the names a place was known as. But from what you’re saying, it sounds like it might be more for language translation?? Or am I off on that?
This can get especially confusing as the Native groups were pushed westward by the Europeans. Groups started mixing, so a place could have names is several different languages. Perhaps the best route is to look at what “common” name to use, then have a place to list the other names?
Thank you for the link for the Events on YT. I will check it out later.
I could see Event dates becoming a very slippery slope very quickly. Especially with the various levels of accuracy and detail we might have on it. How do you show events that happened in the “Spring of 1750”, compared to one that happened in “April 1750”, or the even more generic
“circa 340 AD”? I do not know the right answer to those question, but… lol
Creating a Chronological Precision might be a bit much. Like: Date, Month, Season, or Year. Then what about events we KNOW happened on March 15th (Et tu, Brute?), or ones that we think happened around a date (well, the circa).
I need to learn more about that [x]_event:wikidata= item!
Totally agree that a term of where people lived is going to greatly vary depending n the location and time period. Could also vary in importance depending on the type of narrative someone is trying to tell. Where a high level review might only need to show were people lived, but a more detail story might need to show Native Settlements, English Settlement, Forts, Block Houses, Trading Posts, or maybe Hunting Camps. Not that I am suggesting those, just throwing stuff out there.
Also see my other reply about languages. I may not be understanding the correct use of it?
I should also note that besides being a techy type, I am a long time desk top role player and strategic war gamer. Even helped design a few things. Only mentioning that because it sometimes helps you to think differently about organizing something.
The Name field is for whatever the place is known as in the local native language (more or less as of that time period, but that’s still up for debate). The Multilingual Name fields are for whatever a given language would call the place. It’s important to include any languages that are relevant to the place (including the local native language), but you can also include other languages.
For example, if we knew the name of Cahokia in the original language of its inhabitants, that’s what would be in the Name field (name=*) as well as the Multilingual Name field for that language. English speakers might not have had extensive contact with the Mississippian culture, but Cahokia is what English speakers call the site, so we’d make that the name in English (name:en=*). Same for any other modern language. But more importantly, we’d also make sure to add the name in Osage (name:osa=*) and Miami-Illinois (name:mia=*), since these peoples are more strongly associated with the site. Unfortunately it sounds like the original name isn’t known, so we have to fill in something else in one of these other languages. If name=* happens to match name:mia=*, then a data consumer will be able to infer that it’s an anachronism in Miami-Illinois.
To be clear, this field is not for translation in the sense of literal translations. For example, we could create a waterway relation for the Ohio River during the time it was primarily known by Seneca speakers, who called it ohiːyo’, but we wouldn’t set the English name to “Great River” as a result.
Absolutely. We don’t have the vocabulary for all of these things yet. Or we only have them to the extent that OSM knows of them as historical or archaeological sites. Calling a fort historic during its period of significance would be anachronistic, but that’s the ontology we’ve inherited and are using to some extent. In general, we’re trying to be deliberate about where to depart from OSM’s tagging scheme, because there’s a lot of overhead in terms of software support. We need to evolve the tagging scheme to better accommodate a historical and archaeological perspective. You’re quite right in focusing on notions of place. Improvements in this area will require coordination among mappers and the very few of us who are developing the software.
Forgot to mention: this is a section of the tagging guide that still needs to be fleshed out some more. You’re coming into the project at a neat time when we have a lot of outstanding questions that you can help us figure out a workable solution to.