Hi, Stefan Keller wrote: > The XML encoding we are talking about is about data exchange between two > systems. Geospatial data especially has the property to be "write once, > read many times".
But the database would still identify nodes by ID, so if the editor uploads a changed area to the database, it must upload the IDs of the nodes in question; specifying the actual node coordinates is useless at that point. > To be precise, we need a common understanding what is a > valid area/polygon geometry type conceptually (I propose to say, that > non-overlapping polygons is an additional constraint). I could give > precise definitions (in wrods and figures) on that. Then the eoncoding > comes in. Currently we have a soft upper limit on how complex objects we're willing to process. Ways and areas with more than 1.000 points are not liked - they do exist but are usually split up if encountered. We will perhaps require some way to describe an object that is "part of an area outline"; we do this with coastlines currently, they exist as many small ways but together form the continent areas. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
