[OSM-dev] 0.6

Iván Sánchez Ortega ivan at sanchezortega.es
Tue May 6 23:36:49 BST 2008

El Miércoles, 7 de Mayo de 2008, Stefan Keller escribió:
> > So I have to ask: what is the net gain from using an "area" data
> > primitive?

> Simpler encoding and clear semantics.

Sorry, I don't see how having two identical data primitives with different 
meaning allows for simple encoding. It makes the software worry about more 
tokens to parse and more data structures to worry about.

Extrapolating your reasoning, we should end implementing the 12 entities 
defined in OGC's Simple Features, and every piece of OSM software should know 
about them 12 and implement them. Right know, 3 data primitives are a lot 
easier to understand and implement than 12.

> > So a renderer has to actually walk through *all* the data to render it
> > *all*? What's the problem?!
> The problem is 1. memory,

It's arguable. By using a relational model, you actually save memory if a node 
is shared be several ways. Put in a graph-edge model for areas, the savings 
nearly duplicate.

> 2. the fact that there are parts of an area object unnecessaryly distributed 
> over three(!) sections of a file (or three tables) and 

... but reprojection has to be applied only to nodes, which is a boon for 
software; using cross-linked relational tables it's trivial to fetch a 
spatially-backed instance of a feature. And end-user editors have it *much* 
easier when moving a node that is shared along several ways...

I think this is turning again into a "spatial features vs. graph" discussion 
again. No side will win the argument.

> 3. relying on user tags instead of clear encoding on a system level!

If it's a semantic problem, leave it to tags, not to the system.

Iván Sánchez Ortega <ivan at sanchezortega.es>

Toma mi consejo, Yo no lo uso de todas formas.
-------------- 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/20080507/a40cce17/attachment.pgp>

More information about the dev mailing list