[OSM-talk] Users, contributors and developers

[Andy Robinson]

Lester Caine wrote:
>Sent: 26 April 2007 1:28 PM
>To: OSM
>Subject: [OSM-talk] Users, contributors and developers
>
>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 DATA really is the only project, that's what OSM was set up to do, ie a
means to upload and create streetmap type data. You could argue therefore
that everything else is subsidiary.

>
>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?

The API is simply the method of obtaining the DATA in real time. The API has
its own milestones and currently 0.4 is being prepared. As each milestone is
reached you would naturally expect the amount that you can do through the
interface should increase/improve so I don't see this as replacement. 

>
>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?

OSM was always intended as a free tagging platform where any key/value pairs
are valid. I have yet to be convinced there is sufficient argument for
restricting the use of tags, though I acknowledge that some would like to
have a standardised set of tags so that generic functionality (eg rendering)
can be achieved consistently. Tag numbers are fine if you want to use them,
but they would need to be hidden from the user. The current method of
generic tagging (map features) tries where possible (at least in the English
language) to speak reasonably plain English which helps reduce the barriers
for editors. Of course as the editing tools mature the ability to tag more
consistently and accurately improves.


>
>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?

Well, it is a wiki after all, go to it :-) 

>
>--
>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
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Cheers

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk