Iván, You wrote: > 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. That's a tempting concept, and it's possibly true on a conceptual level. But there are some theoretic and many practical drawbacks: First, I makes parallel editing theoretically and practically much more complicated (who own's the common boundary). In any case, ways would need to be mandatory tagged as "boundary" (if it's part of a polygon). What about polygons which belong together (multi-polygons)? (using relations for such a "data type" would be a clumsy solution)? What happens to the adjacent area and it's attributes (key/values) when you delete a common boundary??
Then there are practical issues, mostly coming from the encoding: It makes validation(!) and rendering much more complicated (how to assemble all boundaries (ways) distributed all over the database?). Just to begin with a fre drawbacks... so it's no surprise, that all de-facto and de-jure standards in GIS (sorry to mention this beast) I'm aware of - except Interlis 1 which we changed to Version 2 because of this(!) among others - are *not* using a graph structure or have abandoned it. -- Stefan 2008/5/6 Iván Sánchez Ortega <[EMAIL PROTECTED]>: > > 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. > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
