The Mapbox API supports geocoding requests fine, but I always get the results in English. I'd like to be able to get results in a specific language.
For the Mapbox.js API, it's possible to display the map in a different language (by changing style), but I can't find a way to translate geocoding requests correctly.
For example, if I pass in the city 'Gent', I would expect to see that it's in province Oost-Vlaanderen and country België. However, I get 'Gent, Oost-Vlanderen, Belgium'.
This would be done using a request like: https://api.mapbox.com/geocoding/v5/mapbox.places/Gent.json?country=be&access_token=MYACCESSTOKEN
Is there a way to get the correctly translated result? Perhaps using a setting or extra parameter?
The localized names that I see in Streets-v8 (and likely in mapbox.places) are name_en, name_es, name_fr, name_ru, & name_zh.
This looks like you'll need to file a feature request with Mapbox, at least you may be able to have support for name_fr.
I like to use the Mapbox Command Line Interface to see the responses from the Mapbox querys. This particular query gives a response of "place_name": "Gent, Oost-Vlanderen, Belgium",
mapbox-cli> mapbox geocoding 'Gent' --country be
I also tried Ghent in the query, but still received English
The town shows as Ghent in the Mapbox language switch example.
Looks like a solution has been implemented!
Just pass in a language field on the initialization object like so:
var geocoder = new MapboxGeocoder({ language: 'es' }); //change lang to spanish
Got it from these docs: https://github.com/mapbox/mapbox-gl-geocoder/blob/master/API.md#mapboxgeocoder
Related
I would like to know how to obtain all London postal codes that start with "W2", for example, something like this. We are using the geocode api but in the postalCode parameter it asks for the exact postal code. We have also tried to use the autocomplete api but I also do not get a list of all the postal codes, it does a search in different parameters and it is not what we need.
This need arises because we are changing from MapServer to Nokia Here and with MapServer the api geocoding if it returns a list of all the postal codes
We are using something like this https://autocomplete.geocoder.api.here.com/6.2/suggest.json?app_id=xxxxxx&app_code=xxxxxxx&query=W2&country=GBR
We would need to be able to indicate in the query a complete or partial postal code
this example verifies what we need
By the way, we are using a payment license, how can I request this assistance?
You can constraint search result upto maximum 20 using geocoding autocomplete API with the below parameter
maxresults = { Valid range: 1 to 20 }
This constraint is as per API design. For detail information kindly go through the below link.
https://developer.here.com/documentation/geocoder-autocomplete/topics/resource-suggest.html
Is there any way to provide automatic street address suggestion when user tries to enter their address in the input box using so they start getting automatic address suggestions in django.
I was searching autocomplete light but could not find specially anything related to that.
I've implemented this functionality with Google's Place Autocomplete. The sample code in the link is pretty spot on from memory.
https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform
You could use python to make the requests yourself and implement some light javascript to fill your inputs:
This will return you a list of predictions based on the input address you supply. You just need an address and your API key to run the query, but note in my example I'm using the components/types parameters as well.
here's the documentation: https://developers.google.com/maps/documentation/places/web-service/autocomplete
url = f'https://maps.googleapis.com/maps/api/place/autocomplete/json?input=<address>&components=country:us&types=address&key=<your key>'
r = requests.get(url)
predictions = r.json()['predictions']
for p in predictions:
print(p['description'])
print('-----------------------')
Im currently working on a more or less RESTful webservice, a type of content api for my companys articles. We currently have a resource for getting all the content of a specific article
http://api.com/content/articles/{id}
will return a full set of article data of the given article id.
Currently we control alot of the article's business logic becasue we only serve a native-app from the webservice. This means we convert tags, links, images and so on in the body text of the article, into a protocol the native-app can understand. Same with alot of different attributes and data on the article, we will transform and modify its original (web) state into a state that the native-app will understand.
fx. img tags will be converted from a normal <img src="http://source.com"/> into a <img src="inline-image//{imageId}"/> tag, samt goes for anchor tags etc.
Now i have to implement a resource that can return the articles data in a new representation
I'm puzzled over how best to do this.
I could just implement a completely new resource, on a different url like: content/articles/web/{id} and move the old one to content/article/app/{id}
I could also specify in my documentation of the resource, that a client should always specify a specific request header maybe the Accept header for the webservice to determine which representation of the article to return.
I could also just use the original url, and use a url parameter like .../{id}/?version=app or .../{id}/?version=web
What would you guys reckon would be the best option? My personal preference lean towards option 1, simply because i think its easier to understand for clients of the webservice.
Regards, Martin.
EDIT:
I have chosen to go with option 1. Thanks for helping out and giving pros and cons. :)
I would choose #1. If you need to preserve the existing URLS you could add a new one content/articles/{id}/native or content/native-articles/{id}/. Both are REST enough.
Working with paths make content more easily cacheable than both header or param options. Using Content-Type overcomplicates the service especially when both are returning JSON.
Use the HTTP concept of Content Negotiation. Use the Accept header with vendor types.
Get the articles in the native representation:
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.native+json
Get the articles in the original representation:
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.orig+json
Option 1 and Option 3
Both are perfectly good solutions. I like the way Option 1 looks better, but that is just aesthetics. It doesn't really matter. If you choose one of these options, you should have requests to the old URL redirect to the new location using a 301.
Option 2
This could work as well, but only if the two responses have a different Content-Type. From the description, I couldn't really tell if this was the case. I would not define a custom Content-Type in this case just so you could use Content Negotiation. If the media type is not different, I would not use this option.
Perhaps option 2 - with the header being a Content-Type?
That seems to be the way resources are served in differing formats; e.g. XML, JSON, some custom format
I'm trying to get something like the Google analytics dashboard but I have some troubles with the language of the result of my query.
When I get the result of my query, I get all the names in English but the geochart only understands the local names.
So when I get for example "Brittany" as a ga:Region, the geochart will not understand it and so won't show it on the map whereas "Bretagne" will. That's the same for all translations.
Do you have any idea of how I could have either the region in the original language or have the geochart understanding the english name of the region?
The Google Analytics API returns values only in English. Unfortunately you are going to have to translate them yourself.
After reading an article on REST ("Restful Grails"), I have gotten the impression that it is not possible to truly conform to a REST style in a service that demands a lot of parameters. Is this so? All the examples I have seen so far seem to imply that true REST style services are "parameterless". Using parameters would be RPC-ish and not truly RESTful.
To be more specific, say we have a service that returns graph data for stock prices, and this service needs to know the start date, end date, the currency, stock name, and whatever else might be applicable. In any case, at least 4-5 parameters are needed to retrieve the information needed.
I would imagine the URL to be something like this : /stocks/YAHOO?startDate="2008-09-01"&endDate=...
("YAHOO" is here a made-up stock name).
Would this really be REST or is this more RPC-like, what the author of the aforementioned article calls "GETful" (i.e. just low ceremony rpc)?
You can see the querystring as a filter on the resource you are GETing. Here, your resource is the stock prices of yahoo. Doing a GET on that resource give you all the available data, or the most recents. The query string filter the prices you want. Content negociation allow you to change the representation, e.g. a png graph, a csv file, and so on. To add a price, simply POST a representation (e.g. CSV) to the same resource.
The "restfulness" is not realy in the URL itself, since URIs are obscures to client, but in the way you interact with resources themselves identified by their URI
Feel free to use as many parameters as you need to identify the resource you wish to access. REST doesn't care.
Why would you think it is not possible?
Google uses REST for their charts api, and they take alot of params:
http://chart.apis.google.com/chart?cht=bvg&chs=350x300&chd=t:20,35,10&chxr=1,0,40&chds=0,40&chco=FF0000|FFA000|00FF00&chbh=65,0,35&chxt=x,y,x&chxl=0:|High|Medium|Low|2:||Task+Priority||&chxs=2,000000,12&chtt=Tasks+on+my+To+Do+list&chts=000000,20&chg=0,25,5,5