[OSM-dev] Very long ways have been split (was: Status of Database Server after 0.4 Upgrade: Fragile)

[Frederik Ramm]

Hi,

(me:)
> I also found the ideas detailed in your Plan B and C quite good. Feel 
> free to submit patches for the rails server, JOSM, and tiles at home as 
> soon as you have them implemented ;-)

Apologies for the tone. That doesn't get us anywhere.

Maybe I overreacted a bit to Steve's post. I said that the system is 
still fragile. To someone working primarily from the planet file, this 
is probably hardly noticeable - but I am very unhappy with the 
performance of the API at present, and I wanted to help getting it 
fixed, preferably within a timeframe of a few days, not a few weeks.

I saw the items that Steve listed in hist post as all contributing to 
the problem, and picked one that I thought was easy to fix. Frankly, at 
that moment I thought that even if my actions would break the rendering 
of those 250 (of 600,000) ways in the database, that would be a small 
price to pay for more stability, and one could still work out the 
details later.

You are right in saying that some sort of "proper" dealing with complex 
objects would be good (personally, I am still thinking "superways" which 
would combine parts of a boundary into one area).

The solution - or let us say, the quick fix - that I implemented will 
probably break the rendering of 19 lakes in the tiles at home layer, but I 
thought that (a) I can fix this in a reasonable timeframe and (b) it 
doesn't really matter all that much because most of those lakes were 
actually never properly rendered pre-0.4 because it is only since then 
that the ways are returned in its entirety. My fix also breaks those 19 
lakes in the Mapnik layer unless work is done to osm2pgsql.c.

Your proposed solution, in turn, requires no changes to osm2pgsql.c, but 
changes to the API and potentially all its clients.

Frankly, I cannot see how your solutions - either Plan B or Plan C - 
could be implemented short-term.

It wasn't ok for me to change things without thinking about Mapnik. But 
neither is it ok for you to lay back and say "I work from the planet 
file, I can handle long ways, I don't care if the API chokes on those, 
you sort that out among yourselves somehow."

May I suggest the following:

1. Leave my split in place for all linear features and coastlines, 
assuming that Mapnik has some way to deal with split coastlines. (If 
that assumption is wrong, then I would have to hand-pick those coastline 
ways that represented whole islands.)

2. Revert my split for the 19 "natural=water" features, assuming that 
they represent lakes.

3. Manually inspect those lakes with the highest number of segments, and 
try to simplify them manually on a case-by-case basis (some will 
probably have more detail than necessary, e.g. many nodes in one line, 
and if not, they can be split up in several adjacent, closed areas).

And, of course,

4. Further discuss how large areas can and should be handled in the future.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'