I already asked the same thing to Mapbox support and it's been a week and no response, so here I am.
Here at my company we are developing a system that uses a delivery service to deliver products to our customers. This delivery service uses Mapbox to get the latitude and longitude of the customer's address so they can tell the exact spot where to deliver the order to their workers.
So we started using mapbox to get these required data but we are facing a problem here.
You see, for addresses here in the city of Natal, in Brazil, everything works fine, not a problem at all. But when there's a delivery to Parnamirim, a nearby city, mapbox service simply can't find the correct address. We filled everything correctly and still the results are not the ones we asked. Can anyone help-me with that?
For example, we want to find the coordinates of the following address: "Rua dos Pinheiros, 10, Encanto Verde. Parnamirim - RN" The zip code is "59149-594".
Street name: Rua dos Pinheiros
Number: 10
Neighborhood: Encanto Verde
City: Parnamirim
State: RN (Rio Grande do Norte)
ZIP Code: 59149-594
Country: Brazil
With this data, we send you the following query: https://api.mapbox.com/geocoding/v5/mapbox.places/rua%20dos%20pinheiros%2010%20encanto%20verde%20Parnamirim%2059149-594%20BR-RN.json (I've hidden the access_token here, but it is present on the URL).
I've tried to add the country=BR&language=BR to the, but still facing the same problem.
If you search for this address on Google, it returns the correct one. But with Mapbox, it simply can't find the correct. This is happening with all addresses from Parnamirim. We don't know about other ones, but this is a big problem for us.
What can we do to fix it? Mapbox doesn't have addresses from Parnamirim in the db? Another crazy thing is that the coordinates are weird. In the first result from the above request, the coordinates takes us to the middle of the sea. Are those in the correct order?
Related
I am working on making a reservation tab as follows:
Date of the pick up: #sys-date
Time of the pick up: #sys-time
Address of the pick up: #sys-location
The problem is that Watson Assistant doesn't recognize the location on live test when customer input detail of their location. It keeps asking me what's the address?
All I get is date of the pick up and time with no pick up address.
The system entity #sys-location in Watson Assistant should be used with caution. It is a BETA feature for some languages and only with this capability:
The #sys-location system entity extracts place names (country, state/province, city, town, etc.) from the user's input. The value of the entity is not a system-standard value of the location.
My suggestion is to ask for the address and capture it as an entire string. Then, try to standardize the input to your local address format, e.g., by using an address verification system.
Another option is to break up the address into parts like city, street, zip code and more. Depending on the country there are different formats and even more than one format to specify it. "What is your city?", "What is your street address?", ...
I am using the REST API of HERE. I am trying to obtain the traffic signs corresponding to a set of LINK_IDS.
I have a list of the links (unique IDs) I am interested in, however I do not know how to obtain the traffic signs which are found in these links. As I understand there should only be 1 traffic sign in each link, at the end of the link.
Can anyone hint what is the way to proceed? I was trying to use Platform Data Extension API to do this, but have not been successful.
The most I have been able to achieve is obtaining all the traffic signs in one tile, by querying the following:
http://pde.cit.api.here.com/1/tile.json?region=EU
&release=LATEST
&layer=TRAFFIC_SIGN_FC1
&level=9
&tilex=537&tiley=399
&app_id={APP_ID}&app_code={APP_CODE}
However, this is not even working for all locations. I tried in different parts of the city of London and the output I obtain is:
{
"Rows":
Array[0][
]
}
In summary, my goal is to obtain the corresponding traffic sign (s) in a link. That is, for link with ID XXXXXXXXX I would like to see which is the traffic sign present in the location marked by this link.
I am trying to obtain the traffic signs corresponding to a set of LINK_IDS
There is no straight solution to this yet. You have to use PDE layer which gets all traffic information for a tile and then extract the link ids of your interest. We have 100% coverage in WEU and NA. For MEA, we have 100% coverage on FC1-FC4 roads and less coverage on FC5 roads(which are destination roads).
I"m looking for way to get list of points of interests like airports, parks, etc. per zip code using Bing maps. Believe me, I search google but it looks like my google is broken since I can't find anything useful. I just need a way to get that info. If there is like a list that would be even better. Any help is appreciated fellows. Is there a simple URL where I can pass in my bing map key, a category and longitude/latitude and get a list of point of interests?
You could use the NAVTEQ point of interest data sources that are in the Bing spatial Data Services here: https://msdn.microsoft.com/en-us/library/hh478189.aspx
You can use the Query API to filter on the PostalCode property: https://msdn.microsoft.com/en-us/library/gg585126.aspx
Here is an example that gets points of interests that are in zip code 98004 and returns the results as XML:
http://spatial.virtualearth.net/REST/v1/data/f22876ec257b474b82fe2ffcb8393150/NavteqNA/NavteqPOIs?&$filter=PostalCode%20eq%20'98004'&$top=250&o=xml&key=YOUR_BING_MAPS_KEY
That said, make sure that your use case does not go against this restriction in the Bing Maps terms of use:
(h)Use Content that consists of points of interest data to generate
sales leads information in the form of ASCII or other text-formatted
lists of category-specific business listings which (i) include
complete mailing address for each business; and (ii) contain a
substantial portion of such listings for a particular country, city,
state or zip code region.
A bit of a newb here, although I have some experience with Bing Maps.
Im trying to use the Locations API to search for locations (primarily) in Canada. My data request is successful and I get back expected data...except for one thing. Canadian Postal codes are traditionally six characters long. However, the API only responds with the first three characters. I realize that only the first 3 characters are needed for geolocation but was wondering if it is possible for Bing to return the whole 6 character value.
My data request looks like this:
http://dev.virtualearth.net/REST/v1/Locations?key=[MYKEY]&q=1440+Law&ul=43.45297157764435%2C-79.70163702964783
I've trimmed some fields for relevancy.
Can Bing's Locations API return a full Canadian Postal code?
The Bing Maps Locations API is designed for geocoding and reverse-geocoding, not for address validation.
As you point out, it's generally unnecessary to consider the full postcode for geocoding - the results can be unambiguously identified using a street address and only the first 3 characters of the postcode. So, although I can't say for certain, I'd say the answer is "no".
When designing an internation registration form how should I be asking for a user's information. Should name be [First, Last] or [Common, Surname] or simply [Name]. Does first and last name make sense for all names?
When asking for state and zipcode what would alternative terminology be, should I even be collecting this information for some countries?
We're recently getting into international users and methods and I'm hoping someone with experience can weigh in on the proper fields and labels that would be present in a solid international registration form.
I would reccomend just a single input for name, not all names are logically separated into just two parts, some people have just one name (such as Teller, and if used for addresses, the name may be a company name). Labeling is complicated since first and last name is not the same as given and family name, if names in your language is normally in which field should the first/family name go and the last/given name go?
For an address input you need:
Name/Company: <text box; no validation or munging>
Address: <Multiline textbox; no validation or munging>
Country: <text box or select-box if you're paranoid>
Making it more detailed and you're creating problems for foreigners.
The only thing your local post service need for a foreign address is the name of the country. The rest is country specific and may include several fields or in some cases something like "behind the church in the woods" etc.
Do not include zip code or anything country specific like that unless the user has chosen a country you have extensive knowledge about. People tend to know how to type their address in a free form text area, but they may actually mess it up if they have to force their address into foreign fields.
The worst you can do is silently discarding invalid fields. That happened to me when registering my address (in Norway) for a magazine subscription from USA. The norwegian addres format is:
<Name or company>
<Street name> <house number>
<post code> <city or suburb>
NORWAY
But when trying to force these fields into the closest equivalent in a very US-centric form they ended up mailing it to:
<my name> Oslo/OSLO//<And a lot of garbage letters and symbols>
/NORWAY
It eventually arrived, but it was a month delayed. It probably helped that I have a unique name, and that we're only about 5 million people in Norway. I doubt it would have arrived if I my name was "John Smith" and lived in New York and some web form had munged it to John Smith NY/New York;/ USA///
Sorry for the long rant ;)
I would suggest just the name, so that user could enter whatever seems right.
As for State, I quite don't understand what you need this information for. But I am not U.S. citizen, so...
Two address lines (without implied format), zip code (terminology is OK, but do not try to validate) and country name should be sufficient. The problem with "States" is, some countries do not use such concepts (either at all, or use different regional split concepts, i.e. in Poland it is voivodship, in England it would be county, etc.). Again, I wouldn't use such details.
How you accept the user data is based on what you want to do with it. Having said that
Name: This is also country specific but based on the suggestions I've got "family name" and "given name" are generic/common across any country. Some names have multiple "family name"'s.
Address: Different countries have different address formats. You can get different format information here
As a non-US resident, who has a very non-standard address (live on a boat, which requires additional address information, and very often does not have a Royal Mail standarised address) I do find that US-centric registration forms are very irritating. As far as name goes, I have found first and last name appropriate. For addresses I would consider either leaving labels off for most lines or labelling them innocuously as "address line 1", etc. In addition make sure that there are a number of such lines; the dialog box is long enough to accept multiple fields; and the dialogs will accept address delimiters such as comma. The only ones I would leave as they often displayed are Town/City and Country. Zipcodes should not be referred to as such - the minimum courtesy I would expect from a registration form is a request for Zip/Post code.
Though not directly related to registration forms, I have previously provided a (very long) answer to a question on validation/normalisation of international data. It is not a simple topic.