Accidental "glueing" of points on import

[joto]

If we don't use nodes any more for the way geometry (chapter 4.1 in the study) a connection between ways (and POI nodes) will be done based on the location alone. An import could accidentally create connections where there shouldn't be any if it doesn't take existing locations into account.

Currently we sometimes have the opposite problem with imports creating too many nodes instead of reusing existing ones. So this doesn't look like a huge problem to me, but it is certainly something that has to be taken into account and we should document as one of the things to look out for and some best practice tips how to avoid it.

(This issue was originally raised by someone during the BoF at SotM 2022.)

[matkoniecz]

This can also happen with regular editing when someone maps outside downloaded area.

Possible solutions:

(1) make invalid to edit in area without downloading it (one more trap for importers and people doing reverts)

(2) edit should include info which points are intended to be glued to other nodes, treat mismatch with real data as edit conflict (may be too resource intensive)

(This issue was originally raised by someone during the BoF at SotM 2022.)

Me :)

[joto]

Yeah, (2) is definitely not an option, we'd have to check all data in the database for conflicts on update, possibly even using a transaction. I'd think (1) is used already in every sensible editor.

[matkoniecz]

I'd think (1) is used already in every sensible editor.

At least JOSM allows to edit in not downloaded area, and this is valid editing method for example for reverting vandalism. It would become invalid with such change, what at least in some cases would make things noticeably more annoying. Especially reverting suspicious edits deleting data.

I think that Vespucci is also allowing this.

[joto]

We can not force an editor to only edit in downloaded areas, only recommend it. And make sure editor authors and power mappers are aware of the issues involved when not following those recommendations. The real issue here is: Are we worse off with the new data model in this situation? I don't think we are. It will just mean some different types of breakages are possible. And we can deal with that like we always do, by being diligent and having checkers and validators and all that.

[flacombe]

To me, moving from topological to geographical connections will introduce more issues than accidental gluing on imports.
Despite it could have other advantages, we should look carefully to this potential flaws.

Current topological framework ensure of connections by design, with no possible doubt.
Geographical rules only assume it with various level of confidence, depending on who is making the assumption.

How can we enforce a common behavior on all editors/consumers?
API won't have any ability to check or validate anything from that perspective.

Practical example:
Editor A and B have different node/way snap thresholds.
On editor A, when I drag way W1, it comes with nodes along.
On editor B, when I drag way W1, nodes remain in place and it certainly constantly breaks the original connection that would have existed before.

Mappers may cause harm out of their own will.

Implementing such geographical rules would require to provide some certainty and consistency between different editors.
How can we achieve that ?

[turepalsson]

My gut feeling is that we should not have a "snap threshold", but require exact matching (in our internal storage format, whatever that is). As I mentioned in another discussion thread, this means the we need to make sure that values that are distinct in our database stay distinct, even when subjected to reasonable levels of abuse. More relevant to this thread, we also need a documented threshold for how close two points can be and still stay distinct when stored in our database.

(I am mildly sceptical of the colocation-implies-connection scheme. Anything that involves equality comparison of non-integer values gives me the heebie-jeebies... I may still be convinced, though. :-) )

[flacombe]

Thank you for feedback

Exact matching would partly solve this problem but we remain with uncertainty about stacked objects on different levels, particularly for indoor mapping.
Issue perfectly described here: #38

We could at least expect to acknowledge on these flaws if it's not possible to provide reliable solution for now.
Just like it was asked for the impact on editor authors/maintainers.
#15

[fititnt]

Question: could be possible to still explicitly create synthetic IDs for the new approach?

TL;DR of reasoning: simpler cases, like low populated areas, or ways not far for each other (something current tools might already auto detect on imports) are not the problem, but as soon as we get into medium to heavy dense regions, or average 3D building, it will be a nightmare to implement this thing at client side. Today's approach, while hard for import, after is done, we're very sure that IDs are connected to each other, but I suspect that if eventually appears people trying to import something like Indoor Mapping Data Format "IMDF" (like I comented on https://community.openstreetmap.org/t/overturemaps-org-big-businesses-osmf-alternative/6760/127), without some sort of persistent ID not granted to be reused, it will be hard to keep track.

---

Potential approach on synthetic IDs for nodes: while IMDF uses UUIDs which are granted to be unique, they would take too much space. So we could get something far shorter (but requires some server to be sure not to repeat them). This would need some calculations up ahead about tradeoffs of typical places that would handle these ids, but the way alternatives to UUIDs could be hashes like the slug on YouTube URL algorithm. Depending on the client, the difference between the current use would be simple: instead of nodes being always fully numeric (base 10), some of them would become hex (base 16). So at XML or textual dumps, it would almost feel like the same, but when importing, tools could handle them differently.

Again, in special cases for non trivial cases, it is better to make quality assurance at import than make it even harder at client side to detect what is connected to what. I do understand that loading something like in iD editor with some types of new nodes with non-integer IDs might take more memory, but it would be by far, less memory or CPU usage than recomputing from tags alone every time.