[OSM-dev] 0.6

[Sebastian Spaeth]

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 
<way>boundary=administrative;admin_level=2</way>

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?

spaetz