On Tue, May 6, 2008 at 9:36 AM, Iván Sánchez Ortega < [EMAIL PROTECTED]> wrote:
> > 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > > Un ordenador no es un televisor ni un microondas, es una herramienta > compleja. > 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... 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). Sincerely, Karl
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
