[OSM-dev] Gisify relations

[Wolfgang Schreiter]

Hi Frederik,

the style of your response suggests to me that for some reason you take this 
personally. I realize it is difficult to discuss in a language that is not 
our mother tongue, and I certainly did not intend to attack you in any way. 
I've been following the forums and wiki for quite a while, apart from 
mapping and developing software for osm myself, and I would be more than 
happy to see this become a success. As a professional, however, I cannot 
help thinking about where we are heading, so please bear with me while I 
provide some background on my reasoning.

The success of osm depends on the ability of software to make use of the 
data, on the relative simplicity to produce such software, and on the 
possibility for end-users to understand the provided data and form a mental 
model about it.

Currently, osm provides little structure to facilitate consistent use of the 
data by people who may not be die-hard osm-gurus. It is left to each 
application to interpret the data, including resolving inconsistencies, 
contradictions, and missing definitions. This also gets in the way of the 
osm community itself. New mappers ask for guidance all the time, and 
countless hours of precious mapper and developer time are wasted in debates 
on how to do this or that correctly, how to interpret the data and how to 
weed out the rubbish from the data. Local communities are developing their 
own mapping standards in response, and in the absence of agreements, the 
tools (e.g. JOSM) define the 'standard' for the vast majority of mappers.

What's needed in the first place is a meta-model that can accommodate all 
this while providing some structure as well. I'm not advocating a 100% 
approach, but rather incremental improvements that will keep the model 
evolving while preserving the extensibility and flexibility that have made 
osm so popular.

So, let's start with geometry. Let's face it, applications will need 
geometry functions to process the data, and databases provide them in 
increasing numbers. osm has points and linestrings, and some sort of polygon 
which is not defined clearly. If you've read the spec I mentioned, you will 
know that its geometry model goes way beyond what can be usefully tagged at 
the moment, including a clear polygon definition and collections of 
linestrings and polygons, just to name the most important. JOSM, keepright 
and others have already started recognizing this, and it would indeed be 
wise to support what the industry out there is already doing. And I don't 
care whose standard it is, or which part of it we choose to ignore - we need 
a solid definition of how geometric primitives and tags map onto established 
GIS datatypes, and why ("an area is a closed way with some tag attached" 
simply doesn't cut it).

Or, in case that was still not concrete enough: in Austria alone, there are 
currently on the order of 750 geometries that are perfectly valid in osm but 
not digestible by quite a few GIS-enabled databases, *including our own*. 
Doesn't that strike you as odd? Care to explain that fact before a 
professional audience ("you know, we abhor any sort of standard, and who is 
Mr. Oracle anyway")?

The logical next step would be a definition of how to build and categorize 
tags, including how to define above said geometries. Again, attempts have 
been made, but no agreement has been reached (mostly, it's not so much a 
matter of content - it just takes a common-sense decision and being aware 
that no decision is ever perfect). It's too much for the moment, but the 
question will arise if developers are to code for osm in earnest. (Ask 
anyone who's tried.)

I can live with osm confining itself to be an experimental drawing tool 
database, and will then certainly find matters more worthy of my time. 
However, I would love to see osm realize its potential and grow from 
grass-roots effort to industry-strength (as Wikipedia and others have 
demonstrated). To do so, I'm convinced it must balance formal structure and 
defined meaning with extensibility and flexibility of content to become a 
predictable data provider.

Best regards
Wolfgang

P.S. Looks as if this requires a proposal (and then some), if only to stop 
wasting my time...