[OSM-dev] 0.6

Karl Newman siliconfiend at gmail.com
Tue May 6 23:55:08 BST 2008

2008/5/6 Iván Sánchez Ortega <ivan at sanchezortega.es>:

> 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?

Look at the original example I posed again (tile cutting). Not all the data
consumers are going to be painting something. In this case, there is
different behavior at a tile boundary depending if a way is a polygon or a
polyline. Absent a semantic interpretation of the tags on the way, it's
impossible to know how to deal with it.

> > 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?!
I was going to put my response inline here but it's big enough (and will
have it's own huge debate, I'm sure) to put into it's own email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080506/0f5f1588/attachment.html>

More information about the dev mailing list