[josm-dev] Jumbo Patch

[Dave Hansen]

On Sun, 2007-12-16 at 01:11 +0100, Petr Nejedly wrote:
> Dave Hansen napsal(a):
> > Privatize Way.nodes.  We need to do this to keep the cache consistent.
> > We also need a ton of new accessor functions.  These need some more
> > work.  This is the bulk of the "core" patch.
> 
> While I have already voiced in my opinion on encapsulation and how
> badly is it needed in JOSM, I must say that your approach is certainly
> far from what would I do.
> Why don't you simply export read-only view over the nodes list
> (Collections.unmodifiableList(nodes))? That would cover most of the
> use cases and you can get rid or many of the methods. And there are
> ways how to do even the modification accesses w/o so many methods.

I suck at Java.  I'm an idiot.  Could you elaborate on this a bit more?
Would we just have:

class Way {
	private List<Node> secret_nodes;
	public List<Node> nodes;

	Way() {
		...
		nodes = new List<Node>();
		secret_nodes = Collections.unmodifiableList(nodes);
	}

And that's it?

We just have to provide accessors for modification of Way.secret_nodes?

> And I have to oppose strongly (as a user) against Node.wayList.
> It would have huge impact on the memory requirements.
> Empty array list costs ~70B. Per Node, that means 35MB more memory
> needed for my use case (>500.000 nodes) (35% increase over current
> consumption of my, slightly patched JOSM version) Even if you did
> it right (limit the capacity of the list), it would still be ~40B/node
> increase. Only if you did it really well, you could get it to 4B/node
> benefiting from the fact that most nodes take part in only one way,
> but still, this doesn't belong into the data layer as it causes
> close data duplication and all the problems related to that.

I guess we could just generate it when we need it, such as during
validation.  If you use the validator plugin, you're going to get at
least a couple of checks doing exactly this operation, but duplicated
several times.

This is a classic space vs. time problem.  We can do without the cache,
but it's going to cost us some pretty nasty N^2 lookups.  I do agree
with you completely, though.  If you're not using the validator, you
shouldn't care about this node->ways crap.

At the same time, I seriously don't think OSM is going to keep scaling
if we don't start introducing a lot more automated checking into the
process.  I know for a fact that we don't have enough people to do the
TIGER checking (or even fixing obviously bad stuff).

-- Dave