[OSM-dev] proposal to kill areas

Chris Morley c.morley at gaseq.co.uk
Mon Jul 24 14:17:42 BST 2006

Ben Gimpert wrote:
> On Sun, 23 Jul 06 @01:08am, Andy Robinson wrote:
>>> There is probably room for a physical boundary based definition as well as
>>> a collection of nodes based definition.  But, the physical boundary based
>>> definition is actually just a set of nodes that have a common attribute;
>>> they all belong to the same way element.
>>> Very interesting idea...
>>> Etienne
>> Thanks for summing it up better than I could have ;-)
>> The physical boundary that we can physically map is less of a problem. I
>> already had a "boundary" key in Map Features for that very purpose so it
>> really doesn't need to be more complicated than a way. 
>> The container of nodes would work exactly as you surmise. I just haven't
>> done it yet although I can see that a trial run with post_boxes is a good
>> idea for me too. I've just realised that I have been tagging ways with
>> postal_code data but it would have been better to code the nodes as well. Oh
>> well, more editing. Thank goodness for JOSM :-)
> Possible proof of concept:  The TIGER import has been quite consistent
> with "from_zip" and "to_zip" tags on ways (for US post codes), so taking
> a crack at Andy's "implicit areas" technique is possible right now.

I can see that it is sensible to define the extent of a built-up area by 
the location of the streets that comprise it. A librarian may describe a 
library by specifying the location of every book in it or a forester may 
wish to describe an area of woodland by the location of every tree in it 
- although most people wouldn't want to do either of these. But nobody 
would want to describe an area of grassland by the location of every 
stalk of grass. Tagging is indeed a powerful way of forming collections, 
but is clearly not suited to every situation. The basic structure of 
tagging is already there, allowing innovative applications like those 
discussed above to be developed. But there should be a similar 
capability for areas, even if not everybody wants to use it.

I find it perverse that people should oppose the provision of a basic 2D 
data structure for a 2D mapping project. We need areas. They can be 
provided easily either by a list of nodes or by an adaptation of ways - 
we should really be discussing which.


More information about the dev mailing list