[OSM-dev] 0.6

Brett Henderson brett at bretth.com
Thu May 8 08:19:41 BST 2008


Martijn van Oosterhout wrote:
> On Wed, May 7, 2008 at 10:44 AM, Brett Henderson <brett at bretth.com> wrote:
>   
>>  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.
>>     
>
> The logic already exists in one place: osm2pgsql. One way to do it
> would be to use osm2pgsql to push it into shapefiles, from there they
> can be easily tiled.
>   
I realise there will always be rules we can apply to determine if a way 
is a way or an area, but from a tools perspective it just means you will 
always have to maintain the list of rules and it will be a never ending 
problem.  An area type solves this nicely.

osm2pgsql is obviously good at what it does, but it requires constant 
maintenance as tags and mapping conventions evolve.  So far I've managed 
to keep osmosis tag agnostic.
> Now, I won't say the logic in osm2pgsql is foolproof right now. I do
> wish people/editors would add an area=yes tag to the non-obvious
> cases. Just because the API doesn't understand the concept, there's no
> reason why editors like JOSM and potlatch can't make the distinction.
>
> Have a nice day,
>   
If we took things to extremes there's no limit to the things we could 
build with conventions around tags, but in this case I think a proper 
data type is warranted and would provide real benefits for everybody.  
There's obviously coding effort required to add a new data type, but 
from an ongoing tooling maintenance perspective, and an end-user 
perspective I think it would actually simplify things to have area support.

Anyway, as I said earlier, just my 2 cents :-)





More information about the dev mailing list