[OSM-talk] Users, contributors and developers

[Frederik Ramm]

Hi,

> There is no reason that people
> can't create their own mirrors of that data in what ever format  
> they want and
> that is something personally I am playing with.

It has already been voiced by a number of people that we would like  
some sort of distributed mirroring; in an ideal world, I'd like to  
see slave servers being able to "subscribe" to a subset of data and  
then being fed all alterations, live of course.

I imagine there will be two types of such "mirrors"; one type being a  
special-use mirror which maybe analyses or re-formats incoming data  
for a special purpose, but does not redistribute. This kind of mirror  
could be implemented in any way. The other type would be a  
distribution mirror which would be expected to feed its own set of  
sub mirrors, thus building a tree. Such a mirror would very likely  
use by an large the same software that is used by the master server,  
just because the whole process of distributing changes is quite  
complex and there's no need to implement it multiple times.

> The current 'developments' on the interface
> to the data seem to be heading to a - you will use the Rails Port!  
> and that
> "Nobody should be developing against the current (non-rails) API."

I think there's a misunderstanding here. The API will only change  
marginally from 0.3 to 0.4. The whole point of an API is that it  
doesn't force people to use a special programming language or  
database or whatever.

> This does not seem to be acceptable to me. The interface to the  
> data should be generic
> and not restrictive

It is. The interface, even with the extensions implemented for 0.4  
which is the rails port, leaves a lot to be desired, but it is not  
restrictive I'd say.

> It seems that the current API interface project is now being
> replaced - but not with something that is generally acceptable?

Misunderstanding, probably.

> Free text should not be allowed for well structured keys, any
> extra types should be added to the documentation first before been  
> allowed in
> the map data?

The spirit in this project is to let the community decide. We spent  
about 4 hours one night at Essen talking to Steve about "triple  
tags", i.e. not having key=value but something like  
namespace:key=value. Steve refused to get into details of how what he  
called "the third database column" should be used; we laid out the  
different concepts, outlining that a "subkey" is something completely  
different from a "namespace", and that use of that third column will  
depend very heavily on how it is called. Steve, from experience,  
didn't want to make any rules the community must then follow - or at  
least, not more than absolutely necessary.

There are advantages to both ways of dealing with it. Other projects  
have spent their first years hammering out a list of allowable tags,  
highway types, features and so on, only to find that the list  
wouldn't work for Japan or something like that. We do not have such a  
list; we have utter chaos, and the burden of doing meaningful  
classification has been shifted from those who write the servers and  
those who enter data to those who actually want to do something with  
the data ("hm, gibble=gobble, how should I render that"). There can  
never be a full list of existing tags because the moment you create  
the list it may already be out of date. It may be a programmer's  
nightmare but it helped us to get off the ground quickly. And while  
there are issues (last I counted there were about 1,500 different  
values for the "highway" tag in use in Germany alone), it works  
surprisingly well.

> While in general the wiki has been restructured to help the  
> different types of
> user/contributor/developer, it is still difficult to find some of  
> the key
> stuff. My personal preference is for a 'book' option on the wiki,  
> which would
> catalogue pages into particular areas for easier access. The main  
> problem is
> caused by 'links' that simply do not connect, such as the Key:layer  
> which
> should logically detail how a multi layer interchange should be  
> tagged, but I
> can't find any related info. There is a large amount of data IN the  
> wiki, but
> some more structuring needs to be applied?

I hereby propose that Mr Lester Caine, of Broadway, Worcestershire,  
be made the First OpenStreetMap Wiki Editor, responsible for sorting  
and structuring stuff, and advising contributors on where their  
contributions fit best ;-)

No honestly, we could use someone who does that. If you feel able to  
do it, then to it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'