[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