[Mapcss] MapCSS and Overpass API

Roland Olbricht roland.olbricht at gmx.de
Sat Nov 26 13:37:03 GMT 2011


Dear all,

I want to introduce an additional but more concise query language for Overpass 
API (see http://wiki.openstreetmap.org/wiki/Overpass_API) than the current XML 
query language and I consider using MapCSS for that purpose.

This is a survey on whether this is a good idea or not.

The advantages are a bigger popularity for MapCSS as a lot of people will get 
aware of the existence and purpose of MapCSS that way. Another added benefit 
is that you can debug a MapCSS style by sending it as a query and examining 
the results. And third benefit might be that translating the examples for 
Overpass API give additional, useful examples for MapCSS for beginners.

The benefits for Overpass API are at first a concise query language that makes 
sense in another context and thus reduces learning overhead.

The downsides are that this would require some changes, mostly extensions, to 
MapCSS, which might propagate back on tools supporting MapCSS.

In particular:
- A largely extended format for the selector tests, most of the form 
[keyword:something] like e.g. [around:100], or bounding boxes [s,w,n,e].
- Changing literals to allow all kinds of special characters if they are 
written in quotation marks, e.g. [name="With white space [and brackets]"], 
according to the XML rules.
- Some extensions for the declarations, mostly { xml ...; } to output found 
data as XML.
- Allowing parentheses to enclose groups of selectors combined by "or".
- Slight, backward compatible changes to the descendant operator. In 
particular: Disallow a combination of the "or" grouping without parentheses 
and the descending operator because there is no precedence specified.
- The abbreviation of "relation" to "rel".
- The permission to arbitrarily remove or add white space unless required to 
distinguish two literals.

The options I see would be to
- Extend MapCSS in the way described above.
- Create a second language, working title "MapQL", and keep the largest 
possible common subset with MapCSS.
- Not do this at all and make a deliberate distinct query language.

As a resource, an example about the gain:

<query type="relation">
  <has-kv k="ref" v="CE 61"/>
</query>
<recurse type="relation-way"/>
<recurse type="way-node"/>
<print/>

could be compressed to

/api/interpreter?rel[ref="CE 61"]way node{xml body;}

Best regards,

Roland



More information about the Mapcss mailing list