[OSM-dev] 0.6
Iván Sánchez Ortega
ivan at sanchezortega.es
Tue May 6 22:55:43 BST 2008
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>
More information about the dev
mailing list