A clearer example: is https://www.openhistoricalmap.org/node/2104063830 from 1799 to 1809 or from 756 to 1870?

In this case, I was linking the chronology relation to https://www.wikidata.org/wiki/Q120752286, which is about the territorial evolution of San Marino. That item has no associated Wikipedia article, so the inspector wouldn’t show a snippet anyways.

More generally, I think we should limit the wiki tags to the highest-order element when it exactly matches the Wikidata item. One practical reason is that the snippet won’t be tailored to the individual member.

For example, the inspector lists a date range of 1860–1870 for https://www.openhistoricalmap.org/node/2104063828 based on its start_date and end_date tags, but the snippet immediately below it says “between 1859 and 1870”, referring to the entire chronology.

I realize this is unsatisfying, but maybe what we need is a more convenient way to navigate a chronology relation, starting with https://github.com/OpenHistoricalMap/issues/issues/601

Hi, do you have any information about when the boundaries of these counties were extended into Lake Michigan? So far, all I’ve found in the territorial laws and session laws for the Lake Michigan counties are boundary descriptions based on PLSS townships and ranges, or specifically stating that the boundary runs along the shoreline. [1] Were the lakeward boundaries perhaps a later introduction, from after Michigan and neighboring states settled on the state line through the lake?

[1] https://books.google.com/books?id=uECSGi3Qlu4C&pg=PA196

Changeset 109553 undoes the change to relation 109512. Relation 2796088 covers the period from 1822 to 1855, when the border with Canada was defined.

If you know which language(s) the Canaanite name would apply to, we can probably come up with a reasonable name:* subkey to apply. I think it’s OK to add, say, Aramaic to the main name tag even if the MapLibre GL renderer doesn’t support it yet. There are efforts underway to better support complex text in that renderer, which will benefit right-to-left languages as well.

Thanks as always for all the detail you’re adding! From the osm_id tags you’re adding, it looks like you’re copying features from OpenStreetMap and adding dates to them. If you didn’t author these features in OSM to begin with, please make sure to also add license=ODbL to each way in order to acknowledge OSM’s license.

OHM prefers public domain content where possible, and most mappers go through the trouble of remapping things from scratch just to accomplish that. But if you prefer to start with OSM data, properly attributing OSM will keep us on good terms with that project. Thank you for understanding.

Bah, chronology destroyers!

Source is survey, not hashtag.

That’s a good plan. The older data appears to be from OSM back when it was under CC BY-SA but isn’t credited. The newer data is clearly in the public domain and well-sourced.

At a glance, the imported SCC waterways appear to be of high quality, but we should double-check the tagging. I think you’ve already noted some of the issues with it, like tiny segments of streams being “underground” just because a bridge passes over them.

Conflict resolution will be annoying but not as bad as it will be if we wait. So far, I’ve modified the Guadalupe River to reflect a change to its course around SJC, and you’ve also split some streams to add them to boundary relations. (I’ve been avoiding that so far, because I haven’t researched which changes are due to avulsion and erosion and which would keep the boundary where it is.)

Never mind, I took care of it in changeset 100857.

Thanks, looks good except that https://www.openhistoricalmap.org/node/2108487030/history was not a duplicate and was already retagged to use more correct tags. Can you restore that one node. I did a spot-check and it looks like all the other ones I worked on are still intact.

Thanks!

All the tags in this import need to be translated from the source to conventional OHM/OSM tags. For example, surface=PAV is causing editors (and potentially future renderers) to misinterpret the roads as *un*paved.

Ways representing rivers and streams should only have waterway=*, not natural=* water. This is causing a lot of validator warnings and could lead to rendering glitches wherever waterways self-intersect.

Looks like much of this data already got imported 54 years ago in changeset 1: https://www.openhistoricalmap.org/way/49639254

Most of this changeset needs to be reverted. Many of the places duplicate existing place nodes, and these place:wikidata tags make a mockery of Wikidata.

Congratulations on adding the one millionth element with a start or end date! By my calculations, the millionth dated element is Hoctor Close:

https://www.openhistoricalmap.org/way/199786540

https://forum.openhistoricalmap.org/t/historical-database-statistics/53/3

I love reading about buildings getting moved. Did you know we have a way to handle that in OHM? You can map the house in both locations, adding start and end dates that correspond to its time at each location. Now when you scrub the time slider on the homepage back and forth, you’ll see it move back and forth.

You can optionally add both copies to a chronology relation to more easily keep track of them: https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags/Relation/chronology Here’s an example: https://www.openhistoricalmap.org/relation/2735032

Hope this helps!

Hi, it looks like this import made the licence=* key much more popular than the license=* key. Perhaps you would like to weigh in on this proposal and poll to unify the two keys: https://github.com/OpenHistoricalMap/issues/discussions/549

Thanks, we’ll want to put some (rough) start_date tags on these places so they don’t show up all the way back to the beginning of time. Do you know a good source for Kentucky place histories? The Kentucky Land Office has some incredible detail about some cities (lilke Florence: https://web.sos.ky.gov/land/Cities.aspx/?ctr=277 ) but nothing about others, and unfortunately it seems that the site is copyrighted.