[OSM-dev] Very long ways have been split (was: Status of Database Server after 0.4 Upgrade: Fragile)
frederik at remote.org
Mon May 14 00:37:16 BST 2007
> 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
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.
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev