How to get an "importer"'s attention

There’s a user whose bulk landuse import blew away edits I had made over a year prior in this area as a new subdivision was being built out. I had carefully added features like new retention ponds and the revised woodland boundary and some other details, and this bulk blast not only overlaid old data that is now wrong, it blew away my objects completely. The changeset comment doesn’t make sense. I have tried to contact the user twice via OSM, and it refuses to answer.

I have my old changeset XML, but no tool ready at hand to upload a correction to put the present real on-the-ground features back. The import probably screwed up a lot of other things too, but I haven’t really sought it out. How do I get the user in question to actually acknowledge the mistake, if not perhaps actually fix it?


It looks like you haven’t yet commented on the changeset, so I might start there. Also, on the import account’s description, it says

This is the import account for SherbetS | OpenStreetMap

Please message me on my main account! I don’t check this account’s inbox.

Have you tried messaging their main account? @SherbetS is also on here I think.


I would also ask on changeset comments where this import was discussed, as it fails to link either documentation page or directly link discussion.

See Import/Guidelines - OpenStreetMap Wiki

Yes if the mandatory community discussion did not take place we should
revert the whole import outright.


The import is linked on the user’s profile: Florida Landuse Import - OpenStreetMap Wiki. According to the page, discussion occurred on OSMUS Slack and the imports mailing list.


Yep, and he also gave a talk about the import at State of the Map US in Richmond. It was a well known import within the US community. I’m sure @SherbetS would be happy to work with you to get the data right.


So far, he’s been ignoring me. I did chase down all the relevant links and the Florida project, but it doesn’t feel like due attention was paid when pre “validating” the data to not trash previous good-faith changes.

There seem to be far too many avenues for these “discussions”, it’s impossible to keep track of all that between old forums, new forums, wikis, mailing lists, slacks, or whatever. Some effort to try and bring all that more uniform might be a large but worthwhile undertaking??

Is it possible to “un-delete” the old objects? My old changesets ( example ) still seem to have all the node and way references, they just aren’t visible. Likely not possible to mess with in iD. But a whole lot of other stuff, pages and pages worth, got deleted over a large area too. What was the point of the import in the first place, anyways? There’s little or no explanation at that wiki entry.


Apologies. I’m on spring break and very far from a computer, but I’ll take a look as soon as I can. (Hopefully Sunday)



I figure it should be possible to restore your edits, I’ve done this kind of thing before. But I will need my computer to get it done.



I am glad we’re on a path forward that will work for everyone. I am confidant we can get to a place where everyone is happy.

I would caution earlier posters to, perhaps, search “osm florida landuse import” before suggesting that the largest and most discussed import in the US in 5 years was some sort of stealth effort that should be reverted en masse.


Thanks… The ones I’m most annoyed about, I believe, are

Changeset: 130299796 | OpenStreetMap
Changeset: 130299207 | OpenStreetMap
Changeset: 130298137 | OpenStreetMap
Changeset: 130224244 | OpenStreetMap
Changeset: 130224138 | OpenStreetMap

and removal of the old pond referenced, I think, by

Changeset: 130222827 | OpenStreetMap

some new version of which is now present in the data but definitely gone in real life.

But really, so many deletions all over a huge area, what else got nuked? Oh, and I *did* search around and read what references I could find, but it didn’t tell me much.



note that comment that I see about doing revert was entirely conditional and reaching out to author of edits first

1 Like

And it’s very easy to see that this does not fall into that condition. I don’t think it’s improper to remind folks to do some light homework before posting.

1 Like

with info on Changeset: 145544675 | OpenStreetMap with source=OpenStreetMap Carto (Standard) and no info about any discussion asking on changeset would be a reasonable next step

such info like wiki documentation page really should be linked from relevant changesets (the same for bot edits which are not imports)

from looking at later edits such as Changeset: 145905950 | OpenStreetMap it seems that it was fixed at some point, so thanks for it!

Though for earlier edits without such info I would recommend adding changeset comments linking relevant documentation to prevent future confusion

And yes - doing revert requires far far far more research! “is not clearly described in changeset as a valid import” is good enough to ask in changeset comments (or advise doing this) but not too jump into reverting things!

Before reverting I would at least search wiki, forum and US Slack for relevant user or any documentation, try to ping them, create thread asking for details… Would probably spot docs at user page in meantime.


And it’s very easy to see that this does not fall into that condition. I don’t think it’s improper to remind folks to do some light homework before posting.

imports should never overwrite (remove) what was added by local contributors, they must conflate the data. Regardless of import documentation, something has gone wrong if a contributor finds their work removed to make space for an import.


By reading the wiki entry for this import (Florida Landuse Import - OpenStreetMap Wiki) and reviewing some of the results, I think what this import did was to download existing landuse-like data from OSM, delete that data from OSM, perform conflation offline, and then upload the results. Thus the history of any existing OSM landuse-like objects was lost. Further, in some cases the data was either lost altogether or made worse by the import. The information on the wiki entry does not make it clear that the history of existing OSM objects would be lost. Here are a few examples.

28.9646273, -82.6419872

The above two natural=water areas were deleted by account SherbetS_Import on 1/4/2024 by changeset Changeset: 145904370 | OpenStreetMap with the changeset comment of “Landuse preconflation” These are no longer present in the OSM data. Perhaps because in both the preexisting data and the present, post-import, data they are inside a landuse=quarry area. Quarries, particularly gravel pits as this appears to have once been, often have bodies of water within them, and the Bing aerial imagery from 1/2022 clearly shows water here. These bodies of water should not have been deleted.

29.0173867, -82.4562949

Above is an area tagged natural=wood that was deleted by account SherbetS_Import on 1/4/2024 via changeset Changeset: 145904370 | OpenStreetMap with the changeset comment of “Landuse preconflation” It was not replaced with anything and that specific area of the map is now blank The Bing aerial imagery from 1/2024 clearly shows trees at this location.

28.9602959, -82.6794662

The above eight wastewater ponds (natural=water, water=wastewater) were deleted by account SherbetS_Import on 1/4/2024 via changeset Changeset: 145904370 | OpenStreetMap with the changeset comment “Landuse preconflation.” They were replaced by a single area tagged natural=water, water=reservoir by account SherbetS_Import via changeset Changeset: 145905916 | OpenStreetMap (a different changeset from the one that deleted the original eight objects):

29.0479947, -82.4683465

The above area, tagged natural=water, water=river, was deleted by SherbetS_Import on 1/4/2024 via changeset 145904370 (Changeset: 145904370 | OpenStreetMap) with the changeset comment of “Landuse preconflation”

It was replaced by the two ways listed below by account SherbetS_Import via changeset Changeset: 145905916 | OpenStreetMap on 1/4/2024

However, only the part of it southwest of the river’s flow line was replaced, resulting in the situation where the river’s flowline is actually outside of the river’s area. Presumably this was because the river flowline (thalweg) is also the county boundary, and the import was done by county. However, landuse northeast of the river was imported even though the river area on that side of the flowline was not.

Also, even though it was, and is, tagged as a river, and thus one can assume it flows under bridges, the import left a gap in the area river of about 7 meters on either side of Florida Avenue/US 41 (which has tags of bridge=yes, layer=1):


Sounds like proper care was not taken in some aspects of this import and @SherbetS has some restoration work to do. I was under the impression that the data quality for this import was generally quite good, so I hope these issues are limited to certain areas of Florida.

1 Like

around here it would not have been acceptable to delete landuse objects as „preconflation“, conflate offline and upload the result, because we try to keep the history

1 Like

Thank you for your thoroughness as always, Mike.

Before importing data for any county, I always did my best to delete any data already existing on OSM that I felt:

  1. would very likely be replaced by the data in the import
  2. the replacement would have comparable or better geometry
  3. deleting the object would not lose any valuable metadata (ex. name)

The more data that existed on OSM, the more awkward geometry would be created from the conflation process. The more data I choose not to delete, the more hours I have to comb through the conflated import data to fix any minor mistakes. I always tried my best to achieve what I considered an acceptable balance between objects deleted and objects preserved.

This is an example object, which I chose not to delete before importing the landuse data in the area.

as you can see, the geometry gets a little strange due to the preservation of the object. I chose to preserve this one because I had issues in the area with the import failing to preserve certain retention basins in residential developments.

All the examples you listed were the measured risk that I chose using my method of conflation. The first two examples of the water areas and wood were deleted with the incorrect assumption that the import would have a replacement object in the area. The eight wastewater ponds were deleted with the assumption that the import would have a correct replacement with less awkward geometry. This was the risk that I chose in these deletions, knowing that in some cases like these it was possible that there would be an inadequate replacement.

The river issue was one of the hardest things to address in the import. all the data files are split on county lines, which becomes problematic when a river splits 2 counties as you showed. The solution I normally tried was preserving any existing river geometry, so that all the county and bridge splitting issues didn’t occur. In some cases, little or no geometry exists, and I choose to include the water area, just split on the county line.

In this particular case, it appears that I made 2 mistakes, deleting the existing water object, (likely due to its size) as well as not importing the water body on the other half of the county line.

The deletion of this water body was accidental, I delete water bodies by searching in an overpass download of the county for natural=water name= and combing through the results to remove any water bodies from the selection I don’t wish to delete. I failed to remove this valid water object from the selection, and ended up accidentally deleting it.

The second error resulted from the way that I review objects in my conflated file. I go through and delete any small river areas that were not cut out when I cut out the water body from OSM, due to the OSM data not being entirely accurate to the area of the water part of the river. It prevents the creation of any tiny isolated water body pockets (see image)
I deleted the other half of the linked river because I incorrectly identified it as one of these isolated water pockets.
27.69652 -82.34274

I couldn’t come up with an acceptable solution to the bridge problem, and I was not able to address it.

These choices, while resulting in small errors in certain areas, saved hundreds of hours of labor over the entire import. This is the reason these errors exist.

Update: I’m working on restoring the data now. I’ve run into an issue with the way JOSM works, and have reached out to the program maintainers for help.