[Openstreetmap-dev] OSM - Schema - Phase 1 - Request for Comment

Tom Carden tom at tom-carden.co.uk
Tue Nov 29 11:51:05 GMT 2005


Just a quick comment - I'm not sure what the purpose of this discussion
is, and I don't want to see lots of effort put into specifying YAXF (yet
another XML format) if it could be put to other use.

Rhetorical question overload:

A GPX-alike format was tried and found to be inadequate even with
extensions, so what would the purpose be of trying again to shoe-horn the
GPX schema plus extra bits to fit OSM's needs?
If GPX schema elements are to be used (and we expect people to reuse bits
of a GPX parser, for example), can we just use a gpx namespace?
Likewise, gis schemas for polygons and lines etc all exist.  Has anyone
really evaluated these for OSM recently, and looked to see if we could
also adapt them for communicating recent changes and versioning?
Wouldn't it be better to fit this discussion around the THINGS you
actually want to represent, rather than arbitrary jargon-y suggestions for
elements without any grounding?
Wouldn't it be better to do this with an eye on what the database already
supports, and try and map closely to that for simplicity's sake?

I do feel the need to re-iterate - the biggest problem facing OSM is light
years away from "what should the next XML format look like" questions. 
It's the question of how to get a proper, balanced, wiki-like feedback
mechanism into the mix.  At the moment I can create points and lines with
joyous abandon, and I can delete them even quicker.  But how do I roll
back vandalism?

The moves I see to expand the kinds of data collected by OSM to fit
everyone's needs (OSM, now with free pony!) are really cool, but the
modest aims we set out this summer still aren't really fulfilled.  Put
simply, I could sign up for an account and write a script in an afternoon
that removes *everything* from the current view and renders the site
useless until someone with database admin rights and knowhow restores it. 
That has to change before you start worrying about formats.

</rant>, I think.

Best,

Tom.


> All,
>
> Ok, so some have had a little poke around at this already. Now its time to
> do something so we can put it to bed for a while.
>
> Starting with the data primitives, i.e. the root XML elements - this
> discussion is not about whether XML is right or not.
>
> Here is what I would suggest we limit this first discussion to cover.
> Hopefully it's painless!
>
> In the text below the <comment> tag is simply there for this discussion.
> The
> following are the root elements that would make up an OSM Schema.
>
> 1. <wpt>
> <comment> wpt as per GPX, ie representing "waypoint, point of interest, or
> named feature on a map." The <wpt> element would be used to define all
> POINT
> features in OSM</comment>
>
> 2. <rte>
> <comment> rte as per GPX, not currently being used within OSM but with
> obvious navigational use. Representing a "route - an ordered list of
> waypoints [although deviate by changing <wpt> to <pt> here - see below]
> representing a series of turn points leading to a destination." </comment>
>
> 3. <trk>
> <comment> trk as per GPX, ie representing "a track - an ordered list of
> points describing a path". Applying this only to GPS trails and not, for
> instance, a street. </comment>
>
> 4. <pt>
> <comment> pt as per GPX, ie representing "a geographic point with optional
> elevation and time". This would replace the current OSM "<node>".
> </comment>
>
> 5. <ptseg>
> <comment> ptseg as per GPX, ie representing "an ordered sequence of
> points.
> (for polygons or polylines". We would restrict the use of this to two
> points
> and use it to replace our current line segments. A minimum of three points
> would be required for use as an area designator.</comment>
>
> 6. <way>
> <comment> way would be the first of our two non-GPX global elements and
> covers the unique flexibility we wish for a Street Map in that any number
> and combination of <ptseg>'s can be included to form, for instance, a
> street. The Way defines all LINEAR features in OSM, a typical list of
> linear
> map features (for guidance) will appear in the next comment
> phase</comment>
>
> 7. <area>
> <comment> area would be the second of our two non-GPX global elements and
> covers the unique flexibility we wish for a Street Map in that any number
> and combination of <ptseg> defined Areas's can be included. This allows
> multiple individual areas to be combined in the same was as is possible
> for
> Ways, for example so that a site that is split by another feature can be
> described as a single element. The Area defines all AREA features in OSM.
> </comment>
>
> 8. <bounds>
> <comment> bounds as per GPX, ie representing "Two lat/lon pairs defining
> the
> extent of an element". Essentially to provide a limiting bounding box as
> we
> do now with the "bbox=" attribute</comment>
>
>
> Some of the global elements from GPX have been deliberately left out on
> the
> basis that these are generally likely to be sub elements within each of
> the
> above global element sequences and we can further discuss the sub elements
> and any sequencing issues later.
>
>
> It would help enormously with processing and reaching consensus if you
> could
> add your comments to the numbered list below rather than within the body
> of
> the text above.
>
> 1.
>
> 2.
>
> 3.
>
> 4.
>
> 5.
>
> 6.
>
> 7.
>
> 8.
>
> Anything else?
>
>
> Feel free to respond to either list or myself. I've not set a time limit,
> but will report back when it appears the major points have been aired.
>
> Cheers,
>
> Andy
>
>
> Andy Robinson
> Andy_J_Robinson at blueyonder.co.uk
>
>
>
> _______________________________________________
> Openstreetmap-dev mailing list
> Openstreetmap-dev at vr.ucl.ac.uk
> http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev
>





More information about the dev mailing list