[OSM-dev] 0.6

[Iván Sánchez Ortega]

On Tue, May 6, 2008 18:18, Karl Newman wrote:
> Well, it's probably too big of a change for the next API change, but it
> would be nice to get a native polygon primitive. I understand it used to
> exist but was removed because nobody was using it. (!) It would be nice to
> have this because it would allow us to deal with polygons in a generic way
> without having to know which tags on a way indicate a polygon.

I don't think so. A polygon primitive would be, IMHO, a step back in time.

We already have ways and relationships, which are a very powerful tool.
And you must stop thinking of polygons as areas, and start thinking about
the OSM data being a *big* graph, the loops in the graph being the
polygons.

Basically, this means that polygons can be defined with the current
primitives, saving at least 50% of the space needed to store them as data
primitives. Think boundaries shared by several polygons, being a graph
edge. The order of the relationship would mark the clockwiseness* of the
polygon.

* Is that a word?

(Yes, I know I should make a good, nice proposal about this with lots of
drawings.)

> I'm thinking specifically of tile cutting where a polygon needs to be
> managed differently than a simple line. Without a specific polygon type,
> any tool dealing with them will have to be updated to track changes in
> polygon tagging.

If polgons became relationships of graph edges, you could render 'em just
as t at h renders coastline. You know the clockwiseness, so you can fill the
space on one side of the uncompleted polygon.

Besides that, some cronjob to calculate which polygon is inside which
polygon would be needed. It could be done offline based on the graph
topology, so no prob.

I do think that relationships (or relations) are the way to go. But OSM
would need some proposals to make this work, and *tools* to manage a
polygon-graph model based on ways+relations.


Cheers,
-- 
Iván Sánchez Ortega <ivan at sanchezortega.es>

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.