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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
