I’ve made some additions to the map in my area in JOSM which involved drawing city boundaries. To do this, I’ve followed a river shoreline at points where it appears that the map showed the city boundary following the shoreline. This has apparently caused an issue, because I get this conflict
Uploading failed because the server has a newer version of one of your nodes, ways, or relations. The conflict is caused by the node with id 287 670 272, the server has version 2, your version is 3. Click Synchronize node 287 670 272 only to synchronize the conflicting primitive only. Click Synchronize entire dataset to synchronize the entire local dataset with the server. Click Cancel to abort and continue editing.
This is quite annoying, because it seems that whatever I do, this conflict comes up and prevents me from uploading my changes. I did initially make a mistake, and hit update modified while I was on the OSM server instead of OHM, but I realized that and switched it (speaking of which, is there a way for me to have two separate versions of JOSM so I don’t have to go to preferences and switch it every time I want to edit OSM or OHM?), and I hit update modified again. That seemed to fix the issues I had from updating from the wrong server (like ways ending up on the other side of the world), but I now have this issue with this node.
Because synchronizing wasn’t resolving the issue, I decided to pull it up on openhistoricalmap.org (node 287 670 272) and I found that the node “was last edited” 55 years ago on Thursday, 1970-1-1 01:00:01 +0000. I highly doubt this. I’m just wondering, what can I do to resolve this? Is the issue with the node itself? After all, 55 years ago is certainly NOT newer than 5 minutes ago, and version 2 is NOT greater than version 3, as JOSM seems to believe. Or is there some other issue, and this node just happens to be the one that comes up for it? I did not modify this node at all, the most I did was modify the riverbank way it is a part of.
Really frustrating issue.
Indeed, the timestamp is the Unix epoch because the date field wasn’t set properly on upload. I’ve always wondered about that osmosis_user_0 changeset. It seems like an import of a very old version of waterways from OSM. I’ve encountered some of my earliest edits from that changeset (and had to manually undo them because they don’t follow modern tagging standards). @jeffmeyer do you know more about the history of that?
For what it’s worth, I’ve tended to avoid connecting anything to these imported features, just in case I decide to blow them away in my area in favor of something better, like a local waterway dataset. Boundaries don’t necessarily follow OSM waterway centerlines anyways; something cruder might actually be more accurate in some cases.
(As far as I can tell, it predates OSM’s adoption of the ODbL. The Creative Commons Attribution license is flexible about attribution, but we should probably change that osmosis_user_0 account’s profile to explain how to determine the original authorship of a given element.)
I’ve also done this by mistake a few times and had to start over. Maybe you could try something like:
Duplicate the feature.
Move that duplicate to a temporary layer.
Delete the original way from the main layer.
Select all the nodes and use the Purge command to have JOSM forget about those nodes.
Merge the duplicate way back into the main layer.
Conflate the nodes with nearby nodes. (You might need the Conflation plugin.)
I’m not a regular JOSM user, so take these steps with a grain of salt and back up your changes before taking any advice from me.
I wonder if maybe a plugin could make it visually obvious which server you’re connected to, or whether that would have to be built into the core software.
Why should I conflate the nodes after duplicating and merging? Won’t that cause the issue with the node to reappear, since it would presumably conflate the nodes I merged with the riverbank nodes originally bank with those same riverbank nodes? I’ll try it though. I’m not incredibly worried about my work being lost, it would be annoying, but the only changes I’ve got unuploaded are a couple of city boundaries (one for Lansing from a map I found on Mapwarper [speaking of which, the map says copyright 1934. Does that mean I need to find a new source? I do want to of course find a better source since maps don’t provide start and end date {so in my edit I set them to arbitrarily be +/-10 years from date of publication, pending better sources, with edtf as […1934] or [1934…] respectively}, but would it be appropriate to use the shape of the boundary from that map nonetheless? Should I add a license tag? The document doesn’t specify a copyright version, so what license would it be?] and one for East Lansing that I’ve been working on from the legal description [though I’ve been struggling with that since I can’t locate “the Hendricks Acre”, and I’m not certain things are lining up correctly.]), so it wouldn’t be too much to recreate if it did get corrupted or something.
I was thinking that by purging the OSM riverbank and redownloading the OHM riverbank, you’d clear out any conflict, but I guess that wasn’t the case. Your changeset looks fine. The Lansing city limits only followed the riverbank for a relatively short distance anyways, so even if connecting it to the riverbank mattered, I don’t think anyone would’ve really nitpicked about that.
The only thing I’d change is to more clearly distinguish between the populated place and the administrative area: only the label node should be tagged place=city, while only the boundary relation should be tagged admin_level=8. You can use border_type=city on the relation to indicate Lansing’s legal status. (Michigan probably shouldn’t be using level 7 at all. Unlike in neighboring states, its townships are mutually exclusive of municipalities, so there’s no need for a half-step level of boundaries between counties and municipalities. But that might be a larger cleanup task.)
Since the map was published in the U.S. between 1930 and 1977 without a visible copyright notice, it’s in the public domain and you don’t need to worry about copyright provisions. However, you should still cite it in a source=* tag.
The Hirtle chart is a handy reference guide for the various conditions for determining the public domain status of works published in the U.S.:
The townships in Michigan are exclusive of cities, but they are not exclusive of villages. I’m not sure if that would change your thoughts on the admin level conversation, but there’s that. Anyway, I’m correcting those admin levels and the other tags you mentioned.
I did put a source tag with the map I used (I don’t regularly use source=*, I mostly just use source:name=* and source:url=* in combination) but it’s on the boundary relation. Should it be on the boundary line itself instead of the relation, or perhaps on both of them? And should it be in the geometry: namespace (e.g. geometry:source:name=*?).
What I meant when I asked about the copyright is that it says on the map
COPYRIGHT 1934
BY
GUY A. PEASE
I don’t know if the copyright was renewed, which according to the source you gave would make the difference between the copyright being still active or public domain.
My bad, I was confusing Michigan and Wisconsin, where towns are exclusive of everything else. In that case, townships should remain at level 7, and I guess the level for cities depends on whether they’re more like townships or more like villages. I’m more familiar with Ohio, where a city that withdraws from its surrounding township is more like a village, so we keep it at level 8.
If you used the same source for the entire relation, you can cite it on the relation, but you have the option of citing it on individual ways if parts from different sources, or if you later map an adjacent township that shares the same boundary way.
Think of source:*=* as an umbrella source for the feature as a whole. If you used some other source for most aspects of the feature but relied on this map for the geometry specifically, then use geometry:source:*=*.
Ah, sorry for the confusion. This University of Pennsylvania site has comprehensive coverage of renewals and links to some search tools that may be easier to use (if less comprehensive). This is a matter of due diligence, so if you don’t find the map through a reasonable effort, you should be good to go.
If it turns out that the copyright was renewed, I’m unclear on whether the second term was extended under the 1976 and 1998 copyright acts. If so, I’d recommend looking for an alternative source just in case. Fortunately, old USGS topographic maps tended to have good coverage of municipal boundaries. You can see if this was the case for Lansing by consulting the USGS Topographic Map Collection via USGS topoView. This issue tracks better integration of the historic topo maps into iD and offers a workaround in the meantime.
Why yes… unfortunately, I do. I was(am?) osmosis_user_0. Indeed, it was an import of very old (now), but current at the time, OSM data. It was an original, experimental planet-level import that was never repaired as it should have been. I believe I filtered it based on natural tags, etc., but I didn’t clean non-natural tags (among other shortfalls, i.e., epoch field), so any nodes on natural ways and natural ways with non-natural tags all came through.
I can definitely update the users profile to reflect that. Please DM with anything I shouldn’t forget - I definitely wouldn’t have caught the epoch issue.
@Minh_Nguyen is right, though - whereever possible, people should feel comfortable wiping out whatever osmosis_user_0 data looks funny or crude. This is especially true regarding waterways, as there is usually much better copyright-free data available now.
@Minh_Nguyen Shouldn’t this be source:geometry:*=*?
@Aenet - thank you for all of your mapping and for raising these issues!! You’re asking all the right questions & clearly in the flow of things.
I think we previously agreed on *:source=* as a subkey rather than a namespace in general, so geometry:source=* would make more sense, even though source:geometry=* is pretty well-established in OSM.
I’ve been looking through the two catalogs for 1934 and I have not had success yet. I’m not totally understanding how the catalogs are organized. The one for the second half of the year has an index which it says is for No.s 1-12 (months?) on PDF p. 336/p. 1037, which I could not find an entry for Lansing or a relevant entry for Pease (I found one for jams, jellies, and marmalades though). I’ll keep searching later, but I’m not sure I’m doing it correctly. I started by looking at each Class F (for maps) before noticing the volume index.
I wrote up a wiki page documenting this import. Please add any additional context or caveats that you can think of. Given the sketchiness around every aspect of this import, I think we should continue to explore opportunities to replace it with data with a clearer story behind it, even at the cost of some detail.
Aha, thanks for the background on the import, it explains a lot about where the incomplete waterways came from!
I thought it might also explain why the Irish coastline has both coastline ways and weird untagged nodes along it. But it looks like the ways came from this import, while untagged nodes came from somewhere else…
Yes, it looks like a failed import of Ireland (the island). Perhaps the upload got interrupted. Since the changeset cites OSM as the source of the geometry, I suspect there’s nothing really to be gained by trying to reconstruct the ways or relation from the anonymous nodes. We should probably delete them. Other than a loch or two, that would be every node contributed by this user.
