reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

reverted in:
changeset/129622385
changeset/129622387
changeset/129622391
changeset/129622396

> why don't you just use the JOSM conflation plugin

Because I shouldn’t have to preserve your vandalism to to exclude valuable data from my import.

> Intresting. Where exactly?
I’m sure you’ve already seen it, given you’ve edited the page.
osm.wiki/HIFLD

>It is not worth my (or anyone else's) time to start big discussions because of this.

It doesn’t matter if you consider it worth your time. It is a REQUIREMENT to import the data.

>No one (and no quality issue) forces you to spend a single second with things I upload.

We do have to fix your imports. There are guidelines for a reason. Why would we have them if we just let you get away with these improperly conducted imports?

> Quickly mass-deleting perfectly valid data has absolutely nothing to do with "clean-up".
Again, we’re not reverting your edits because it’s not valid data, it’s because you refuse to follow the import process.

The entire reason that I found this undiscussed import was because I was preparing to import the HIFLD’s offshore platform dataset. The HIFLD has more information available that can be translated, as well as the fact that I have actually done the work required to document and get permission to perform that import.

You are using an external dataset with no documentation, and without discussing it on the mailing list as required by the Import guidelines.

You have already been told by the community at least 6 times to follow the import guidelines in the past, and have ignored that instruction every time. Not including the numerous low quality building imports that were also not discussed and clearly are not sufficiently manually reviewed as you claim.

This data is good, and I’ll probably consider importing it myself in the future, but ignoring the community and disregarding the import guidelines is completely unacceptable as we have told you before.

These problems such as the start_date issue you were running into could’ve been avoided if you contacted the mailing list as required and addressed feedback before uploading, but I have no reason to believe that is within your capabilities.

We do have to waste our time constantly fighting you over these continuous dumps of data that you refuse to import correctly.

Please leave us alone with these messy imports! We’re tired of having to clean up after you!

Where was this import discussed?

Where was this import documented?

Why are you using what I'm assuming to be OBJECTID as a ref value?

Why aren't you using an import account?

wrong account.

Internet cut out part way through. let me know if there are any issues.

zluuzki,

why do your landuse boundaries have blocky boundaries? in the files I've generated I don't have landuse objects split into cubes.

wrong account.

wrong account.

wrong account.

Hi Kirbert,

can you tell me what these objects are that you have added?

Thanks, SherbetS.

currently being repaired

fixed here:

changeset/126619620

hi,

I processed this part of the data in order to fix a coastline overlap issue, but when converting back from shp file in QGIS it converted all the non top-level tags into other_tags=*

I thought that I already processed these out before I resumed work, but it is apparent that it was not the case. I'll see if I can get it fixed.

This time, I remembered to upload the multipolygons as well