[OSM-talk] Users, contributors and developers

Lester Caine lester at lsces.co.uk
Thu Apr 26 13:28:22 BST 2007


One of the major problems with the OSM project is that it's actually three 
projects in one, along with sub projects. Something which does not happen in 
many other open source projects.

Ignoring HOW the data is gathered, the raw data is a developing archive that 
can be used in a number of ways, some of us would like to run copies locally 
against which we can develop our own uses, while at the same time expanding 
the archive by uploading new data. Ideally this would be provided by access 
direct to the database, and only be reliant on text tools to access it such as 
via the API. Although there is no reason that a mirror of the data should not 
provide it's own 'API' if required. The DATA is a project in it's own right, 
and some contributors simply use the available tools to expand and refine that 
data, with out regard to how that is achieved. 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.

The current API and interface to the database should perhaps pay more 
attention to cleaning data going into the database, and making the creation of 
mirror sites easier. Personally I don't like MySQL or Ruby, so all of my 
playing is with the weekly dumps on my own hardware, but I would like to see 
an easier way to update each week. 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." This does 
not seem to be acceptable to me. The interface to the data should be generic 
and not restrictive, but I am not sure where this particular 'project' fits 
into the whole. It seems that the current API interface project is now being 
replaced - but not with something that is generally acceptable?

Rendering and map making are in essence a sub set of projects in their own 
right. All use the same base data, but provide a graphic view of that data. 
While the rendering needs to know the range of available data, and is limited 
to only being able to display information stored in the database. The 'schema' 
of information that is displayable comes from the text files of what is 
actually stored. While anarchy does seem to rain over some of the tagging 
details, on the whole things are logical and seem to be working. What would 
make more sense, however, is dropping the full text format of tags, and 
replace them with an approved list of tag numbers. This would much simplify 
the rendering of maps in a selection of languages. 'highway' would return 1 to 
x or free text, and the defined tags would be selected from the correct 
language table. 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?

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?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php




More information about the talk mailing list