[OSM-dev] 0.6

[Iván Sánchez Ortega]

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 <ivan at sanchezortega.es>

cat knowledge | grep understanding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080506/674a12a4/attachment.pgp>