So, there is literally no difference in how you would handle this with GraphQL vs a traditional RESTful API. All you have to do is pass query variables in your query... and then pass those variables to whatever model method / service RPC you call to grab location data.

If you are using React, you can learn more about request variables here:

http://dev.apollodata.com/react/queries.html

Variables are also how you submit data in mutations.

I highly recommend Apollo for a client side GraphQL implementation. They are the best

Interesting, I don't think I've ever used OData. It looks like OData is similar to JSONAPI? GraphQL is strictly a specification and query language for making queries against your API in the same way that your backend makes queries against your database. You can grab as much data as you want in a single request, as you can with certain RESTful protocols like JSONAPI. However, with GraphQL, you don't really have to roll your own protocol implementation. You simply define functions that handle certain portions of your operations by making calls to your model layer or service layer. I would choose GraphQL over JSONAPI any day.

They're similar with a few key differences. First, in OData, the URI is still a big part of the API, whereas the URI is unimportant in GraphQL, which allows GraphQL clients to simplify routing logic. Second, GraphQL lets you specify arguments on any field within the selection set. OData's parameters are far less flexible. Finally, and less objectively, I feel OData's query filters on collections is too burdensome and, in practice, ends up tightly coupled to a SQL-like backend.