Try to keep the size of UpdateBuilding down, these search things are easy to extract.

Warn the user when the building way or one of its nodes is in a relation, because updating them might have unwanted side-effects.

It might be part of a Relation:building, in which case extra caution needs to be taken.

Check how these buildings are exposed on the BAG plugin layer, and see how those can be matched to the ways+nodes on the OSM layer properly.

Example: https://www.openstreetmap.org/relation/12759753 (thanks Vincentvd on Discord)

The current CTRL+ALT+A clashes with area selector

Collect interesting test cases in empty OSM+BAG layers, save a .joz file and commit that to the repository.
Makes it easy to test the tool after changes, and ideally it can later be converted to automated unit tests.

Currently it create a few separate entries because some actions depend on previous ones already being committed in the DataSet. This means pressing CTRL+Z after doing an update will rollback only partially, and you need to press it multiple times to undo it fully, which is really annoying.

Approaches to explore:

1. Try to run all actions at once, solving the dependency issues
   • Probably impossible for the DuplicateNode fixing pass
2. Somehow try to merge later command to an existing history entry

Would be good to first show a popup with the note in that tag and let the user confirm that they want to continue anyway.

List of note-related tags to probably warn about:

• note
• note:bag
• fixme

Create a logo to use on the github page and in JOSM.

Maybe also suitable or inspiration for the cursor icon the tool itself uses.

In build.gradle in the josm > manifest section add iconPath = "path/to/my/icon.svg"

• If building=construction in OSM:
  1. Ask if the building should be upgraded to 'not under construction'
  2. Use the value of the contruction tag as the new value of the building tag
  3. Is the building tag value from BAG more specific? Use that (after implementing #16 this should be automatic)
• If the BAG building is under construction:
  1. Ask the user if it should be updated anyway (I believe the rule is that construction should have started in real life)
  2. Check how under construction building are represented in the BAG layer

• Check how demolished buildings show up on the BAG layer, probably just absent
• When the user clicks a building for which there is not BAG building, ask if the building should be removed because it is demolished
  • Ideally do a HTTP request to the BAG api to check the building status, instead of relying on the knowledge of the user. Offering a link to the BAG viewer might be a good first step. Using https://bagviewer.kadaster.nl/lvbag/bag-viewer/#?searchQuery={ref:bag value} seems to work nicely.

To make sure master builds correctly, and always have a latest development version available on Github.

See the workflows of JOSM itself for the initial steps to setup a JOSM build environment: https://github.com/JOSM/josm/tree/master/.github/workflows

For example if there is a connected driveway, the target way will have an extra node where that driveway connects. This node won't be present in the BAG data, and therefore the current algorithm will try to remove it. That means the driveway gets disconnected though.

Options to solve this:

1. Leave it disconnected and warn the user that it needs to be fixed
   • Might be good enough as a first version, but ideally do something better later
2. Keep the node at the original location, and splice it into the new geometry
   • Might be hard to determine the correct location in the list of nodes
   • Might cause a weird bulge in the building
3. Snap the node to the closest edge of the new building geometry and connect it again
   • The driveway might still cross the building after this operation, in that case ask the user.

Example cases

Building with an entrance=* node

Will disconnect the entrance node, it should put it back into the way.

Driveway before:

Driveway after::

When updating a building, upgrade the building tag to be more specific if better specified in BAG. For example when OSM has building=yes and BAG has building=house, apply building=house. But when the other way around, preserve the value in OSM that is already more specific.

Probably best to:

• Create a node pairing interface
• Implement the interface for the AssignmentProblem usage (slow algorithm)
• Implement the interface for the quick algorithm
• Use the new classes in UpdateBuilding

This would move a bunch of code out of UpdateBuilding, and make the pairing algorithm selection nicer

The building:parts might need updates as well, so warning the user about their presence gives them a chance to check if everything is still working as expected.

This could be represented in the data in 2 ways:

1. building:part ways that are fully inside the outer building=* (often connected to nodes of the main building, but that is not a guarantee)
   • Example: building, main house part, back extension part
2. Connected by a building:relation
   • Example provided by Vincentvd: https://www.openstreetmap.org/way/297435750#map=19/51.98525/5.66406&layers=N

The AreaSelector JOSM plugin also has a custom dialog with instructions what to do with the output, helps to easily report bugs to this repository.

When using the tool on a building, it should update the address points as well.
Probably only add new points, and update tags of existing points. Don't move existing points, because probably they have a better location in OSM than BAG.

Double-check that all address points are inside the building.

Currently it will import the BAG way as a new building in this case, which is incorrect.

Just warn about this issue and fatally stop the update? Instruct the user to first solve the duplicate ref:bag (possibly by simply removing both buildings, remembering additional tags on them)

Not meant for tagging building (which it can indicate in the popup), but it can link to the BAG viewer, making it easy to view details about that building.

Somehow also add this to address nodes? Harder because those don't have ref:bag though.