[Potlatch-dev] [OSM-talk] Way with only one single node

[Steve Bennett]

On Wed, Mar 21, 2012 at 10:14 PM, Richard Fairhurst
<richard at systemed.net> wrote:
> 1. In the UI (i.e. don't let the user create them in the first place)
> 2. In the entity model and actions (i.e. don't let them get into P2's
> internal data)
> 3. In the upload code (i.e. don't let them be transmitted to the server)
>
> Historically P2 has tried to tackle it at 1 - don't let the user create
> them. Clearly something's falling through the gaps and I'm in
> communication with Thomas B to see if we can find out where there is.
>
> 2 is also a reasonable place to address it. I recently did this with empty
> relations which, like 1-length ways, aren't actually forbidden by the data
> model but are discouraged by the community:
> https://github.com/systemed/potlatch2/commit/f762b5c7b33c0ff4ecbd37bc1db37634cedb3d8a
>
> You'll see that, when you remove a member from a relation, this code now
> deletes the relation instead if it would result in it having 0 members. We
> may be able to do something similar here, though I suspect it would be
> less easy.

One downside to this approach is that although zero-member relations
and one-node ways are useless to save to the database, they may be
useful within a session. There's nothing especially wrong with
removing every way from a relation, creating some new ways, then
adding the relation to those ways.

> I'm less keen on 3. Conceptually, uploading should just be a matter of
> "send the changes in P2's internal dataset to the server". Adding a check
> here is a bit of a sticking plaster - it works but it doesn't fix the
> underlying problem. I'd rather see if, with the help of some steps to
> reproduce, we can fix 1 and/or 2 first before resorting to 3.

I'd say:
1) We can fix this, but it's hard to prevent it coming back when new
features are built. I've probably written such bugs.
2) Yeah, reasonable. Strengthen the model interaction to avoid these issues.
3) I still think we should do this. We have a responsibility to not
mess up the database. Saying "well, we should avoid writing bugs"
isn't addressing that: we should both implement this failsafe
mechanism, *and* avoid writing such bugs. (And also, as noted above, I
don't fully agree with your concept that uploading is a perfect
replication of in-memory data.)

Steve