[OSM-dev] 0.6

Iván Sánchez Ortega ivan at sanchezortega.es
Tue May 6 20:59:50 BST 2008

El Martes, 6 de Mayo de 2008, Stefan Keller escribió:
> Iván wrote:
> > [...] OSM data being a *big* graph, the loops in the graph being the
> > polygons.
> That's a tempting concept, and it's possibly true on a conceptual level.
> But there are some theoretic and many practical drawbacks: First, It makes
> parallel editing theoretically and practically much more complicated (who
> own's the common boundary).

The boundary ways and the polygon relation are different data primitives, so 
each of them would be owned by an author. I don't see the problem here.

> In any case, ways would need to be mandatory tagged as "boundary" (if it's 
> part of a polygon).

Nope! By being part of a relation, they are implicitly a polygon boundary.

> What about polygons which belong together (multi-polygons)? (using relations 
> for such a "data type" would be a clumsy solution)?

A (complex) multipolygon would be a relation of relations. It would be a 
inner/outer relationship of graph-loop relationships.

Having worked with the OGC simple features standard, from my point of view, a 
relation of relations is just as complicated as an OGC multipolygon.

Even better, if the OSM tools were semi-smart, they would be able to tell out 
the outer and inner hulls of the polygons based on the clockwiseness. Teh 
resulting data structure would be easier.

> What happens to the adjacent area and it's attributes (key/values) when you 
> delete a common boundary?? 

Becomes broken, renders badly, and makes JOSM's validator become crazy with 

The same would happen if you have two adjacent areas and delete the common 
nodes. I guess the renderers would have to work on a best-effort basis and 
try closing the broken polygons.

One good thing here is that when rendering a big polygon, the same concepts 
currently applied to the coastline could be applied to any polygon. Think big 
forests that spawn over more than one tile, for example.

My hope is that JOSM's validator would take the heat off this concept. It 
already implements a "overlapping ways" detection algorithm: improving it 
would easy the conversion of ways with overlapping sections to relationships.

The only problem I see with this concept is that all renderers (and export 
tools) would have to "unfold" the data to convert the shared ways (edges) 
into polygons. Sounds like an easy recursivity could solve it, but the real 
problem is that someone's gotta code it. :-(

(AFAIK, we now this kind of problems with "areas with holes" - the same 
problem with renderer implementations applies there)

> Then there are practical issues, mostly coming from the encoding: It makes
> validation(!) and rendering much more complicated (how to assemble all
> boundaries (ways) distributed all over the database?).

If you're rendering a small section, having the graph edges instead of the 
full polygon actually makes it easier*. Think coastline.

For assembling the boundaries into polygons: recursivity. Assume the data is 
right, walk through the relationships.

* There would be a borderline case, which would be the renderer receiving just 
one edge, which is in the reverse direction than the whole polygon.

> Just to begin with a 
> fre drawbacks... so it's no surprise, that all de-facto and de-jure
> standards in GIS (sorry to mention this beast) I'm aware of - except
> Interlis 1 which we changed to Version 2 because of this(!) among others -
> are *not* using a graph structure or have abandoned it.

This would be an interesting topic for me to delve into. What were the reasons 
to abandon it?

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

Proudly running Debian Linux with 2.6.24-1-amd64 kernel, KDE 3.5.9, and PHP 
5.2.5-3 generating this signature.
Uptime: 21:37:09 up 6 days, 57 min,  2 users,  load average: 0.24, 0.63, 0.50
-------------- 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/4057156a/attachment.pgp>

More information about the dev mailing list