brett at bretth.com
Wed May 7 09:44:48 BST 2008
Sebastian Spaeth wrote:
> Brett Henderson wrote:
>> Being fairly intimate with the issues involved in trying to split files
>> into bboxes and polygons I'd love to see a polygon concept. Currently
>> it is almost impossible to split osm files into tiles suitable for
>> devices such as a garmin. I've created a pgsql schema which will
>> provide the basis for splitting nodes and ways more effectively but
>> polygons are impossible without resorting to complex and constantly
>> changing tag analysis. As for creating too many new osm types, I think
>> the advantages of this outweigh the bad. We already have a node which
>> represents a single point, a way which represents a line, and a polygon
>> type would be a natural progression with another dimension added.
>> Unless we start modelling 3D objects we then have a complete set of
>> primitives for 2-dimensional modelling.
> I tried to resist jumping in to a mostless pointless discussion, but
> this is the first valid argument that I see.
> However, you need a tag analysis anyway. If I understand you correctly
> you would like to split files easily according to
> <polgon>level=country...</polgons> or whatever, right? How is that more
> less complicated than looking for
Actually my problem was much simpler. I was just looking for a way of
taking a big bounding box (ie. a box around Australia) and splitting it
into smaller tiles (let's say 10km square for arguments sake). The
problem you run into is that ways and polygons cross tiles so they have
to be split. The problem in the current model is that you don't know if
a way is a simple line to be cut in half at the tile borders and a
synthetic node inserted or a polygon where the rules for splitting it
are more complicated. If we had a polygon type this problem goes away
and I wouldn't have to look at tags at all, I'd just have to copy tags
across split ways and polygons.
I've effectively given up on solving this tiling problem because it's
very messy, will take a large amount of effort to get right, and I don't
have enough time to get it working properly.
As you point out, extracting data within a polygon itself is a more
complicated problem where the rules for breaking ways and polygons
becomes much trickier. I'm sure it's not impossible but not the problem
I was trying to solve and I doubt if anybody would find it terribly useful.
> I am not against a polygon feature, just trying to understand how it
> solves issues.
> I agree that parsing one polygon is easier than recursively analyzing
> relations and assembling the border from multiple ways, but what if you
> simply required the country border to consist out of one way?
I don't know what the solution for large areas such as countries should
be. Either you just leave them as ways or you break them into smaller
polygons in a similar way to how we currently break ways into manageable
lengths but I suspect that will be subject to much debate.
At the end of the day I haven't contributed huge amounts of mapping
data, but as somebody who has spent far too many hours processing osm
primitives I can see some compelling advantages to true polygon support.
More information about the dev