Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linear Rivers (BH140) - Complete duplicates on Hootenanny export #5232

Open
tdvorakcaci opened this issue Jan 30, 2022 · 6 comments
Open

Linear Rivers (BH140) - Complete duplicates on Hootenanny export #5232

tdvorakcaci opened this issue Jan 30, 2022 · 6 comments

Comments

@tdvorakcaci
Copy link

Describe the bug
Single River line features imported resulted in complete duplicate River Line features at export using Hootenanny. These features appear as single features in JOSM.

To Reproduce
Steps to reproduce the behavior:

  1. See screenshot below
  2. Import MGCP TRD v4.5.1 data with Hootenanny
  3. Export data with MGCP schema switcher with Hootenanny

Expected behavior
Features not duplicated on Hootenanny export

Screenshots
Near 42.852270 12.092244, neon green rivers are complete duplicates. Top table shows selected original MGCP TRD 4.5.1 River line at import, and bottom table shows selected Hootenanny River lines exported. These exported River lines are complete duplicates with identical GUIDs as the imported feature.
image

Desktop (please complete the following information):
N/A

Smartphone (please complete the following information):
N/A

Additional context
N/A

@MikeTho16
Copy link

MikeTho16 commented Jan 30, 2022

Some observations:

  • There were 33,880 linear rivers (BH140) in the input dataset
  • This was the only feature class for which there were more than 32,767 features (upper limit for a 16 bit signed integer), did some counter or index overflow? If other feature classes had more than 32,767 features would they also see this problem?
  • Is the problem repeatable?
  • The way IDs for all pairs of rivers that were examined differ by exactly 371, I don't know what the significance of the number 371 is, but it is interesting that they all differ by the same amount.
  • The duplicate rivers also have duplicate nodes (each member of a pair of duplicate rivers has its own nodes), even though hoot was told to remove duplicate nodes.
  • Did this problem happen at the import, or the upload stage?

@MikeTho16
Copy link

I tried "importing" (not "uploading", just "importing") just the WatercourseL features and then immediately exporting, and the problem was not reproduced. Therefore, it is either caused during the "upload", it is dependent on "importing" all of the data (all of the feature types), or this was a random glitch (which would be bad). I do not want to try the "upload" until I have shifted the data to a different location so I do not overlay the data we already have in our instance.

@tdvorakcaci
Copy link
Author

I did check these features in JOSM, and they do appear to be single features when that data is loaded in JOSM.

@MikeTho16
Copy link

@tdvorakcaci if by "in JOSM" you mean downloaded from the server, then I am seeing something different.
image
The duplicates are on the server, and thus the issue was in the "import" or "upload", not the export.

@MikeTho16
Copy link

In Hoot I tried "Derive Changeset" on the rivers I uploaded and then exported the resulting .osc file. The duplicates are not present in the .osc (at least not the same ones that were present before).

@MikeTho16
Copy link

I uploaded the above "derived changeset", but the rivers that were previously duplicated were not duplicated in this shifted dataset of rivers. Perhaps the duplicates were a onetime glitch, or only happen when all of the other feature classes are uploaded as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants