<div class="gmail_quote">On Tue, May 6, 2008 at 9:36 AM, Iván Sánchez Ortega <<a href="mailto:ivansanchez@escomposlinux.org">ivansanchez@escomposlinux.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Tue, May 6, 2008 18:18, Karl Newman wrote:<br>
> Well, it's probably too big of a change for the next API change, but it<br>
> would be nice to get a native polygon primitive. I understand it used to<br>
> exist but was removed because nobody was using it. (!) It would be nice to<br>
> have this because it would allow us to deal with polygons in a generic way<br>
> without having to know which tags on a way indicate a polygon.<br>
<br>
</div>I don't think so. A polygon primitive would be, IMHO, a step back in time.<br>
<br>
We already have ways and relationships, which are a very powerful tool.<br>
And you must stop thinking of polygons as areas, and start thinking about<br>
the OSM data being a *big* graph, the loops in the graph being the<br>
polygons.<br>
<br>
Basically, this means that polygons can be defined with the current<br>
primitives, saving at least 50% of the space needed to store them as data<br>
primitives. Think boundaries shared by several polygons, being a graph<br>
edge. The order of the relationship would mark the clockwiseness* of the<br>
polygon.<br>
<br>
* Is that a word?<br>
<br>
(Yes, I know I should make a good, nice proposal about this with lots of<br>
drawings.)<br>
<div class="Ih2E3d"><br>
> I'm thinking specifically of tile cutting where a polygon needs to be<br>
> managed differently than a simple line. Without a specific polygon type,<br>
> any tool dealing with them will have to be updated to track changes in<br>
> polygon tagging.<br>
<br>
</div>If polgons became relationships of graph edges, you could render 'em just<br>
as t@h renders coastline. You know the clockwiseness, so you can fill the<br>
space on one side of the uncompleted polygon.<br>
<br>
Besides that, some cronjob to calculate which polygon is inside which<br>
polygon would be needed. It could be done offline based on the graph<br>
topology, so no prob.<br>
<br>
I do think that relationships (or relations) are the way to go. But OSM<br>
would need some proposals to make this work, and *tools* to manage a<br>
polygon-graph model based on ways+relations.<br>
<br>
<br>
Cheers,<br>
--<br>
Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>><br>
<br>
Un ordenador no es un televisor ni un microondas, es una herramienta<br>
compleja.<br>
</blockquote></div><br>Sorry, but I think graph-edge relationships would be a step backwards for our mappers. It may be nice and technologically advanced, but we already have problems with mappers understanding the clockwise/counterclockwise rules; do you think they're going to understand graph-edge relationships? If you can make the tools such that the underlying data model is transparent to the user/mapper, then great (maybe), otherwise...<br>
<br>Besides, even your method still doesn't tell us how to slice an area into tiles without specifically designating an object (or collection of edges) as a polygon. Just having a closed way is not sufficient (think roundabouts). For a way, you want to break it cleanly at the edge, and create a new way if it re-enters the tiling area. For a polygon, you want to break at the edge and join that edge point along the tiling boundary to the point where it re-enters the tiling area (or to the corner of the tile).<br>
<br>Sincerely,<br><br>Karl<br>