> That looks awfully similar to relations. It's *is* actually like a relationship - but it's clearly encoded and directly parseably as a primitve geometry type 'area'. > So I have to ask: what is the net gain from using an "area" data primitive? Simpler encoding and clear semantics. > So a renderer has to actually walk through *all* the data to render it *all*? > What's the problem?!
The problem is 1. memory, 2. the fact that there are parts of an area object unnecessaryly distributed over three(!) sections of a file (or three tables) and 3. relying on user tags instead of clear encoding on a system level! Let's lower the barriers primarily for writing OSM reader software and secondary also for OSM writer software if possible. -- S. 2008/5/6 Iván Sánchez Ortega <[EMAIL PROTECTED]>: > El Martes, 6 de Mayo de 2008, Stefan Keller escribió: > > Urging editors and converters to maintain direction constraints breaks > > almost all implementations and makes it harder to implement. > > There are simple ways like the encoding I proposed. > [snip] > <area id="8007396" visible="true" timestamp="2007-09-26T19:07:16+01:00" > user="a_user"> > <wy ref="59907908"/> > <wy ref="59907909"/> > <wy ref="59907910"/> > ... > <tag k="created_by" v="an_application"/> > <tag k="a_tag" v="a_value"/> > </area> > [snip] > > That looks awfully similar to relations. > > I see your point, though: polygons/areas are 2-dimensional entities, > whereas > ways/lines are 1-dimensional entities and, from a topologist point of view > they *have* to be different. > > From a code-monkey point of view, though, it actually makes sense not to > make > a distinction. You start a drawing path, lineTo() the next point, then > apply > the styles and either fill or stroke the drawing path. 99% percent of the > code is shared, so refactorization kicks in, and all of a sudden a line > and > an area are the same thing. > > So I have to ask: what is the net gain from using an "area" data > primitive? > > > > > Think about what reading OSM areas currently means to > > validators/converters/editors/renderers because of the > > node-ways-relationships-and-fancy-tags-stucture: > > First they have to read in all(!) nodes into memory befor he can > assemble > > them to ways. > > Second, they have to check (hopefully closed) way tags in order to find > > out, if there is a tag which claims to be an area tag, which is > > eventually(!?) documented in the wiki. > > Third, they have to read in the whole(!) relationship section in order > to > > find out if there are eventually relationships which refer to areas. > > So a renderer has to actually walk through *all* the data to render it > *all*? > What's the problem?! > > > Cheers, > -- > ---------------------------------- > Iván Sánchez Ortega <[EMAIL PROTECTED]> > > cat knowledge | grep understanding >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
