[OSM-talk] Mapping everything as areas

[Michal Migurski]

On Nov 25, 2009, at 4:40 PM, Roy Wallace wrote:

> On Thu, Nov 26, 2009 at 8:09 AM, Anthony <osm at inbox.org> wrote:
>>
>> Now, how are you going to indicate a direction of travel on an area?
>> I guess you could come up with some way to do it, but you'd basically
>> be defining a way.
>
> Good point. Anyone got ideas on this? Maybe it is indeed necessary to
> map each highway as a way (to indicate a logical path of travel) as
> well as an area (to reflect reality!).


I think it will be necessary to retain both lines and areas, but in  
different data sets. I think this is true for a lot more than just  
highways, actually. It also sidesteps some of the geometric gymnastics  
made necessary by using large-scale geographic data at lower zoom  
levels.

These are two slides from a talk I gave on OpenStreetMap to the North  
American Cartographic Information Society last month:
	http://teczno.com/s/3jb
	http://teczno.com/s/c96

(full talk here: http://teczno.com/s/l05)

The first slide shows now-gone image from the Ordnance Survey website  
illustrating map detail at a number of scales.

This thread is about the scales to the right of the illustration,  
1:10k or so and below. At that scale, roads aren't lines anymore,  
they're areas and should be treated as such. You're no longer routing  
people *along* a road, instead you're moving them through and across  
the road, into buildings, etc. Stefan Knecht's United Maps is one  
company that's thinking about data at this scale. OSM data is not  
suitable for use at 1:10K and below, because it's designed and  
optimized for typical city scales: 1:250K down to 1:25K. That's a  
pretty wide range for a single data set, but it's starting to shear a  
bit.

The second slide is a call for help - in order to be usable at and  
above 1:250K (cities, regions, states), the data will require editing  
at a different scale, one that simplifies river areas to lines, dual  
carriageways into single ways, collections of streets into urban  
polys, shopping areas to points, etc. With the impending release of  
Natural Earth Vector, we're going to have a really good data set at  
the far left end of the scale above 1:10m. That leaves a critical gap  
between 1:10m and 1:250K, quite a wide swath. The use of rasterization  
libraries like Mapnik and Osmarender papers over this gap somewhat by  
doing the expensive rendering process just once on the server, but  
it's slow and redundant.

I've done some recent work with OSM that addresses it as vectors and  
the data is basically useless when you've zoomed out a bit.

My sense is that OSM will need to expand its scale coverage in two  
directions, and possibly develop a concept of trans-scale relations.  
I've seen this in other vector sets before, e.g. ones that have a  
layer for lake shapes vs. lake "centerlines" like Natural Earth  
promises. Potlatch 1.3 makes it possible to edit down into the 1:1K  
scale where it would be appropriate to model highways are areas, but  
the question of travel direction on these highways is irrelevant - if  
you want to route someone, you use the lower zoom of today's existing  
OpenStreetMap, which is created at a scale where roads are ways.

On the left side of the scale, I think it will be necessary to have  
two separate, low-scale OSM data sets that use higher-scale renderings  
as input. These datasets, which could simply be separate instances of  
OSM, would be much smaller and simpler, and optimized for vector  
manipulation of large areas. In "simple OSM", highways would be single  
ways with local features such as bridges omitted, local POIs like  
schools or hospitals would be points, buildings would disappear, etc.  
In an even lower-scale "mini OSM", smaller local roads would simply  
disappear in favor of built-up areas, trunk roads and motorways would  
be a single classification, rivers would be lines, most local POIs  
would be omitted, and so on.

The data set / zoom level breakdown might look like this:

	6 -	Nat. Earth	http://osm.org/go/TZNQp--
	7	mini OSM	http://osm.org/go/TZNQp
	8	mini OSM	http://osm.org/go/TZNQpm-
	9	mini OSM	http://osm.org/go/TZNQp0--
	10	simple OSM	http://osm.org/go/TZNQns
	11	simple OSM	http://osm.org/go/TZNQnsO-
	12	simple OSM	http://osm.org/go/TZNQnp9--
	13	current OSM	http://osm.org/go/TZNQnp9
	14	current OSM	http://osm.org/go/TZNQp1hY-
	15	current OSM	http://osm.org/go/TZNQp1hC--
	16	current OSM	http://osm.org/go/TZNQp1hC
	17	current OSM	http://osm.org/go/TZNQp1hC6-
	18+	maxi OSM	http://osm.org/go/TZNQsgND_--

My sense is that such a project would require only the setup of an  
additional two, lower-capacity OSM servers and probably the creation  
of a new rendering stylesheet. It'd be interesting to tackle feature  
equivalence at different zoom levels, but maybe that's biting off too  
much for a small project.

-mike.	

----------------------------------------------------------------
michal migurski- mike at stamen.com
                  415.558.1610