[OSM-dev] 0.6

Stefan Keller sfkeller at gmail.com
Wed May 7 08:51:30 BST 2008


> Extrapolating your reasoning, we should end implementing the 12 entities
> defined in OGC's Simple Features, and every piece of OSM software should
know
I'm proposing three primitive geometry datatypes, namely: point (syn. node),
polyline (syn. linestring, way) and area (syn. surface, polygon), eventually
with parameters. In Switzerland we have used this since about 15 years, so I
can assure you that this works for all real world use cases we mentioned so
far (topology, coordinate transform, etc.) and it's easy to implement (at
least easier as the current area usage in OSM).

You are right, that it would be nice to share common nodes and common
boundaries and that there are arguments for both. But believe me, the
encoding I'm referring to here is preferrable because it is "object
oriented" and more data processing friendly than the topology model,
while it still allows topology and (conceptually) shared boundaries to be
derived from it.
OSM data primitives currently lack a primitive geometry datatype 'area',
which needs a clear semantic definition and a simple encoding.

If we could agree on this we could take the most useful parts out of Simple
Feature and the Interlis spec. I referenced before.

-- Stefan


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

> 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.
>
>
>
>
> Cheers,
> --
> ----------------------------------
> Iván Sánchez Ortega <ivan at sanchezortega.es>
>
> Toma mi consejo, Yo no lo uso de todas formas.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080507/bf82d50b/attachment.html>


More information about the dev mailing list