[OSM-dev] proposal to kill areas
80n80n at gmail.com
Sat Jul 22 22:39:44 BST 2006
Interesting point. What I think you are saying is that an area could/can be
defined as the boundary of a set of nodes that share a common attribute.
This would work quite nicely for many situations. All the phoneboxes/post
boxes/buildings with an NW1 postcode could be used to define the NW1 postal
area. Nobody actually goes out and traces the boundary (probably, nobody
actually knows the real physical boundary), but each phonebox that is tagged
with an NW1 code helps to define the area.
Similarly there have been discussions in the past about the difficulty of
walking administrative boundaries. If enough nodes within the
administrative unit are tagged as such then the actual line of the boundary
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...
On 7/22/06, Andy Robinson <Andy_J_Robinson at blueyonder.co.uk> wrote:
> I've been really rather taken aback by the variety of argument on this
> matter yet nobody has really come back with a straight forward response to
> valid question.
> For me the feature that I think of as an area I also think of as volume,
> other words a container. The container has sides (edges in 2D) and is the
> receptacle into which I pour all the information both related to the
> container and information residing within in. I think of this like a
> library. The library itself is a structure which has information about
> itself (what time it opens etc). Within it there are shelves containing
> books. While the books themselves may not be properly described by the
> library (I can read them independently outside the library doors) the
> library does know that a particular book exists on its shelves.
> A map is no different in this respect. It contains location information
> within fixed or loose boundaries (areas).
> So my belief is that OSM only needs to find a simple way of defining the
> container, and this might be done by tagging the items belonging to it
> rather than defining a fixed boundary and then all the data being either
> or out (ie no flexibility). A good mapping example is when a new housing
> estate goes up on Greenfield, it's a lot easier to redefine the limits of
> the urban conurbation by its elements than to have to redefine the limits
> the boundary as a separate entity.
> Being able to group and container data should open up a lot more
> possibilities for information stored and used from OSM. It includes time
> dependent data as well. Its one of the aspects of OSM that got me
> in the start. The ability to tag any bit of map data with much more than
> can on a traditional map.
> So to answer Steve's question, I personally don't think we need <areas>.
> since we can effectively create containers with the tagging of data
> (although that may not necessarily be the most efficient way to do it in a
> db sense) then we probably don't need anything in its place either.
> Andy Robinson
> Andy_J_Robinson at blueyonder.co.uk
> >-----Original Message-----
> >From: dev-bounces at openstreetmap.org [mailto:dev-bounces at openstreetmap.org
> >On Behalf Of SteveC
> >Sent: 20 July 2006 15:20
> >To: dev at openstreetmap.org
> >Subject: [OSM-dev] proposal to kill areas
> >There are only 4 areas in OSM and osmarender treats certain tagged ways
> >as an area. I figure it'd make the server simpler and make client area
> >support simpler if 'area=true' on a way made it in to an area.
> >Functionally, if they were working, an area is identical to a way
> >have fun,
> >SteveC steve at asklater.com http://www.asklater.com/steve/
> >dev mailing list
> >dev at openstreetmap.org
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev