[OSM-dev] 0.6

Karl Newman siliconfiend at gmail.com
Tue May 6 18:11:50 BST 2008


On Tue, May 6, 2008 at 9:36 AM, Iván Sánchez Ortega <
ivansanchez at escomposlinux.org> wrote:

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

Sorry, but I think graph-edge relationships would be a step backwards for
our mappers. It may be nice and technologically advanced, but we already
have problems with mappers understanding the clockwise/counterclockwise
rules; do you think they're going to understand graph-edge relationships? If
you can make the tools such that the underlying data model is transparent to
the user/mapper, then great (maybe), otherwise...

Besides, even your method still doesn't tell us how to slice an area into
tiles without specifically designating an object (or collection of edges) as
a polygon. Just having a closed way is not sufficient (think roundabouts).
For a way, you want to break it cleanly at the edge, and create a new way if
it re-enters the tiling area. For a polygon, you want to break at the edge
and join that edge point along the tiling boundary to the point where it
re-enters the tiling area (or to the corner of the tile).

Sincerely,

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


More information about the dev mailing list