Feature Request: API parameters that can take more than one constraint

[riordan]

One of our users has requested that our API uniformly support multiple constraints on parameters (e.g boundary.country=usa,gbr), like we do with source and layer

From the support email:

good morning;

the documentation at https://mapzen.com/documentation/search/search/ describes just one property which permits multiple values

is there any provision for multi-valued constraints for other properties. if i try a naive approach, for example with boundard.country as either “GBR,USA” or with two query arguments, the response indicates an error. does the api provide for this in some way? if so, how does one indicate correlations?

to be clearer about this, in order for it to be effective in a production environment, it will need to support multi-dimensional constraints. in order to accomplish this, your api would have to permit something on the order of the propagated values clause which is described in connection with sparql federation: http://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/#values this likely means, you would have to support “post” in addition to “get” requests.

i have tried to locate an equivalent among the json-based rest api documentation which i could locate in the web, but did not succeed. despite that, i would expect there must be some example which supports something similar.

what are your plans in this direction?

---

the documentation at https://mapzen.com/documentation/search/search/ describes just one property which permits multiple values

is there any provision for multi-valued constraints for other properties. if i try a naive approach, for example with boundard.country as either “GBR,USA” or with two query arguments, the response indicates an error. does the api provide for this in some way? if so, how does one indicate correlations?

[missinglink]

technically this would not be difficult to support and since it's only for /search there would be little performance impact.

:+1: from me in regards to boundary.country

[lisp]

does your "not difficult" estimate extend to combination cases. that is, where more than one dimension is multi-valued? for example, where the criteria are "ymca" in combination with a us location, but "cvjm" for a german location?

[missinglink]

I would say a query as described is a complex query, if you mean:

IF ( ( USA && "ymca" ) OR ( DEU && "cvjm" ) )

that sort of a query is hard to represent in a query-string format and so would require more thought.

if you are talking about this:

IF( "ymca" && ( USA OR DEU ) )

... then I think that can be implemented easily without too much consideration for writing a whole new DSL

there is a tradeoff between having a simple user API and having a fully customisable query language.

personally, I would prefer to have the hosted service as the former and encourage those looking for the latter to run their own version of Pelias which can be customised to suit.

[lisp]

[just a few thoughts]

I would say a query as described is a complex query, if you mean:

IF ( ( USA && "ymca" ) OR ( DEU && "cvjm" ) )

indeed, that is the suggested mode. where access to search service is in-process, this kind of facility in not important, but where the service is remote, we have found it to be of significant benefit to an analytical application. the sparql language, for example, describes, but does not require such a facility for federation (see above), and we are finding that, if we do not support it, remote federation is not feasible in anything other than the simplest situations.

part of the problem is, the sparql http protocol exhibits this deficiency and we have had to extend it in order to facilitate certain applications by allowing a request to specify a simple sparql sub-expression to serve as an initial solution field in the query. (see, eg., https://github.com/dydra/http-api-tests/blob/master/extensions/sparql-protocol/values/inline-query-multiple.sh) in this case, there is no new dsl, as the service already uses sparql and this mechanism serves to augment stored queries.

in the case of a json-based exchange, the analogy would be to accept prototype patterns in request post content in the same form as you supply results. the data-flow changes, but there is no need for a dsl.

customisation would be sub-optimal from two perspectives. on one hand, it undermines interoperability, which limits the value of the service. on the other, it would limit the benefits which one would expect from the collaborative evolution of your mapzen site and datasets.

[riordan]

Thanks @lisp. Unfortunately we're not in a place to fully implement that pattern at this time. Federation in the way you describe is really powerful, but we're not staffed sufficiently to prioritize it now. We'd gladly welcome any code contributions that help us get there though.

[lisp]

i have no expectations. just wanted to make sure the issue was clear.