[OSM-dev] Very long ways have been split (was: Status of Database Server after 0.4 Upgrade: Fragile)
jburgess777 at googlemail.com
Mon May 14 23:13:19 BST 2007
On Mon, 2007-05-14 at 01:08 +0200, Frederik Ramm wrote:
> >> The coastline display in tiles at home is solved; I don't know how Mapnik
> >> deals with it but Mapnik cannot reasonably expect us to have one way for
> >> the whole coastline of a continent.
> > Mapnik does not expect t at h to do anything. It only worries about how it
> > renders data.
> So how does Mapnik render coastlines (and the water that is on one side
> of the coastline) currently, given that the coastline of anything but
> the tiniest islands is not closed?
For zoom 0..9 mapnik uses the VMAP0 shapefiles to define the countries
and sea. At zoom 10+ the VMAP0 data is too inaccurate to be used so
it renders the coast line as just a thin blue line with no concept of
which side is land/sea.
For a small area of the globe (principally around the UK I believe)
Artem has manually imported the OSM coastline data into a shapefile
which is used at higher zooms. This needed some time and effort since
the data in the shapefile had to be fixed up so that the coastline was a
single continuous polygon.
for an example of where the blue coast is used instead of vmap0 if you
> I was under the impression that this was somehow working. If it is:
> Could the same mechanism not be used for other things (such as lakes) as
> well? And if it isn't: Then why make a fuss about 19 lakes?
Yes, provided people step up to help Artem generate the appropriate
shapefiles from raw OSM data. He requested people to help do this some
months ago, see
> You are not seriously requesting that coastlines should be closed, are you?
No, I'm not saying that it is something we can do today. I would not be
as bold as to go and join up all the existing coastline into single ways
with many thousand of segments without first ensuring that the tools and
API could handle such a change.
I am suggesting that we should consider if there are methods we can use
to enhance our APIs and tools so that joining up all the coastline might
be possible one day in the future.
As someone else once remarked:
- we should not be changing the data away from reality just to make it
look better in one particular renderer or tool.
> > Feel free to submit a patch for osm2pgsql.c as soon as you have it
> > implemented :-)
> 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 ;-)
I may well do, but as you can probably tell, i'm also busy fixing other
mapnik rendering issues.
I see either of my suggested approaches as probably requiring a new rev
of the API, but I see no reason why we could not run 2 concurrent API
versions to allow tools to migrate to a new API over time. There is an
obvious support cost to maintaining 2 APIs which we would not want to do
indefinitely. Maybe a stable vs unstable API would be appropriate, like
the old Linux 2.4(stable) vs 2.5(development) model.
More information about the dev