[OSM-talk] How to fix wonky coastline?
Artem Pavlenko
artem at pavlenko.uklinux.net
Wed Feb 28 21:25:06 GMT 2007
> > What?? Honestly, are you serious? All we need to do is to use
> > *POLYGONS* ,
> > full stop. What is the problem?
>
> That the polygons are huge (absolutely massive - the whole of Asia for
> example) in relation to a tile.
Correct.
> If you have a 256 pixel tile to consider,
> why would you have to obtain the whole African coastline in order to render
> that small tile (if indeed you are even able to download that much data in
> tiles at home for example).
But you don't need to pull the whole of Asia if you store shoreline as tiled
polygons. Most of the time you just need *one* :
http://media.mapnik.org/osmturk-5.png.
>
> OR alternatively the sea (or land) has to be broken up into very large
> numbers of manageable size polygons, most of which don't contain a
> coastline (e.g. squares; else how do you know that your landlocked town
> shouldn't have a sea-colour background?).
Yes.
> It is just so much simpler for the renderer to make decisions at the same
> kind of scale as what it is trying to render.
Not sure how it is much simpler than just render a polygon.
> Furthermore, the coast is already represented as lots of unconnected ways,
> so it is easier to get from where we are now to where we want to be if we
> stick with that representation.
One way or another we'll have to connect them. Lets have a sound approach from
the beginning and not just hope 'coastline' will solve itself somehow.
>
> > This [point in polygon] will never work reliably.
>
> It is heuristic I agree, but I bet it would deal with 99.99% of cases and
> it will be very obvious indeed when it goes wrong to manually fixup the few
> remaining cases.
Point in polygon can work very reliably, indeed - once you have a clean
polygon.
> I think you are being altogether too dogmatic. I am trying to make some
> suggestions which could improve efficiency, and you are dismissing them out
> of hand.
Not at all. I am as you're trying to improve efficiency and quality of OSM
data.
Cheers,
Artem
>
> David
More information about the talk
mailing list