[OSM-dev] 0.6

Stefan Keller sfkeller at gmail.com
Tue May 6 20:03:51 BST 2008


Iván,

You wrote:
> We already have ways and relationships, which are a very powerful tool.
> And you must stop thinking of polygons as areas, and start thinking about
> the 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, I makes
parallel editing theoretically and practically much more complicated (who
own's the common boundary). In any case, ways would need to be mandatory
tagged as "boundary" (if it's part of a polygon). What about polygons which
belong together (multi-polygons)? (using relations for such a "data type"
would be a clumsy solution)? What happens to the adjacent area and it's
attributes (key/values) when you delete a common boundary??

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

-- Stefan

2008/5/6 Iván Sánchez Ortega <ivansanchez at escomposlinux.org>:

>
> On Tue, May 6, 2008 18:18, Karl Newman wrote:
> > Well, it's probably too big of a change for the next API change, but it
> > would be nice to get a native polygon primitive. I understand it used to
> > exist but was removed because nobody was using it. (!) It would be nice
> to
> > have this because it would allow us to deal with polygons in a generic
> way
> > without having to know which tags on a way indicate a polygon.
>
> I don't think so. A polygon primitive would be, IMHO, a step back in time.
>
> We already have ways and relationships, which are a very powerful tool.
> And you must stop thinking of polygons as areas, and start thinking about
> the OSM data being a *big* graph, the loops in the graph being the
> polygons.
>
> Basically, this means that polygons can be defined with the current
> primitives, saving at least 50% of the space needed to store them as data
> primitives. Think boundaries shared by several polygons, being a graph
> edge. The order of the relationship would mark the clockwiseness* of the
> polygon.
>
> * Is that a word?
>
> (Yes, I know I should make a good, nice proposal about this with lots of
> drawings.)
>
> > I'm thinking specifically of tile cutting where a polygon needs to be
> > managed differently than a simple line. Without a specific polygon type,
> > any tool dealing with them will have to be updated to track changes in
> > polygon tagging.
>
> If polgons became relationships of graph edges, you could render 'em just
> as t at h renders coastline. You know the clockwiseness, so you can fill the
> space on one side of the uncompleted polygon.
>
> Besides that, some cronjob to calculate which polygon is inside which
> polygon would be needed. It could be done offline based on the graph
> topology, so no prob.
>
> I do think that relationships (or relations) are the way to go. But OSM
> would need some proposals to make this work, and *tools* to manage a
> polygon-graph model based on ways+relations.
>
>
> Cheers,
> --
> Iván Sánchez Ortega <ivan at sanchezortega.es>
>
> Un ordenador no es un televisor ni un microondas, es una herramienta
> compleja.
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080506/847116bf/attachment.html>


More information about the dev mailing list